Ask Slashdot: Transitioning From 'Hacker' To 'Engineer'? 446
antifoidulus writes "I'm about to get my masters in Computer Science and start out (again) in the 'real world.' I already have a job lined up, but there is one thing that is really nagging me. Since my academic work has focused almost solely on computer science and not software engineering per se, I'm really still a 'hacker,' meaning I take a problem, sketch together a rough solution using the appropriate CS algorithms, and then code something up (using a lot of prints to debug). I do some basic testing and then go with it. Obviously, something like that works quite well in the academic environment, but not in the 'real world.' Even at my previous job, which was sort of a jack-of-all-trades (sysadmin, security, support, and programming), the testing procedures were not particularly rigorous, and as a result I don't think I'm really mature as an 'engineer.' So my question to the community is: how do you make the transition from hacker (in the positive sense) to a real engineer. Obviously the 'Mythical Man Month' is on the reading list, but would you recommend anything else? How do you get out of the 'hacker' mindset?"
Don't worry (Score:3, Interesting)
Get a mentor (Score:5, Interesting)
Find someone in your new office to show you the ropes. Every major piece of software tends to have its own issues. For server software you might be looking at analyzing piles of log output. For gaming it might be real time perf metrics. Chances are, the biggest thing to get comfortable with is your debugging->fixing->building->testing->checkin cycle. Make sure you figure out how to get the road blocks out of your way. If you're working on something painful where there's a ton of time wasted rebuilding to try out your ideas, maybe there's a better way to build/patch in a more granular way. Your peers will also be interested in any process improvements. If you can optimize and speed up a process that makes you more effective, share it with the team. People really respect and appreciate anyone who can make their life easier.
And *really* spend some serious time trying to learn your software's object model, lifecycles, and data structures. When you start there will be an overwhelming amount of information. You need to accept that. But once you've got a bit of a foothold, CONTINUE learning. You want to be an expert. It takes discipline to get a broad and deep enough understanding to truly be efficient and effective. Be interested in the work of your closest peers. Chances are, what they have learned over the years can be incredibly helpful to enhancing your efficiency. At the end of the day, you'll be primarily judged on reliability and throughput. Whatever you can do to meet your goals, the better! And never be afraid to get help. It doesn't matter if someone helps you finish something. All your manager cares about is that the task is done. If they assign it to you, you are responsible for driving that task to completion. If you don't have an a clear idea of how to do something, that's your cue to immediately find someone to brainstorm with.
And career-wise, it's easier to advance in the earlier years. So when optimizing towards success and a happy retirement, a lot of it comes down to how quickly you can advance in your early years. Down the road, it's as much time as ability. To start with, it's all work ethic. Put in that extra 10% to be the hardest worker and you'll be getting promotions year after year. Work through those lower levels as fast as you can so you can enjoy the rest.
Good luck :)
Hacking and Engineering (Score:5, Interesting)
Engineering a house:
1. Gather requirements
2. Write a spec
3. Design house to spec
4. Build house to design
Hacking a house:
1. Nail boards together
2. Step back
3. Is it a house yet?
4. No, go to 1
Both methods work, but I'd prefer the former to the latter...
Learn to read code (Score:4, Interesting)
Welcome to the farse of "Software Engineering", the sooner you realise that the way things happen in the real world is just (as you say) hacking stuff together and debugging it the better. The only added fun that you will have no idea what 70% of your codebase does and neither does anyone else.
While Software Engineering never provided any credible way of _building_ the systems, what it used to do is provide ways where you could find out exactly what you need before you start building it. These days we have Agile instead, so we don't do that, we just pick an idea at random and hope to god it's either right or we can change it.
My advice: Learn to read code. Learn to find out what the system actually does, not what the comments says it does. Learn to read it then work out how to slowly change it into what you need. It's the difference between the respected senior guy who fixes the problems and the detested junior guy who creates them. I work with a commercial 3D game engine and the fact I know every line of it is worth far more to anyone than how many lines I can myself write in a day.
Have one such case right now (Score:5, Interesting)
I have a hotshot hacker working for me right now who thinks he knows everything, but he is just a stupid little hacker who thinks his dick grows every time he uses vi. Don't be like that.
You are already on the right path: You recognized in yourself that you need to grow professionally and that you need to get away from the little dark screen and see how it fits into the world.
Three points:
* See the first for the trees
* Have the balls to say "I don't know"
* Education, education, education
Here is the most important thing to remember: A hacker sees his own little thing that he hacks on. An engineer see how that thing fits into the world and people who uses it. See the forest that your little tree grows in.
All companies and industries have standards, habits and a culture that it uses and the people are almost always NOT used to or interested in the little details that fascinate a hacker.The people out there will not change their entire culture to fit your hacking needs. The job of any technology and the engineers that build it is to facilitate the and simplify the lives of other people.
Professionality means that you take responsibility for your work. That includes taking responsibility for the interface to the users.
Read this:
The Clean Coder: A Code of Conduct for Professional Programmers (http://my.safaribooksonline.com/book/programming/9780132542913)
Number two: You cannot know everything. Accept it.
There is nothing wrong with expanding your horizons and going past your field, but when you are in a terrain where you are uncomfortable make sure your peers know it and make sure you have a mentor and listen to him. Or delegate to an expert. People will have a much higher esteem for you professionally if you have the balls to say "I don't know" instead of lying. It can be hard sometimes, but it beats being known as an arrogant little know-it-all.
Point number three: Education, education, education. Always assume you know nothing. Read up about your industry outside of the computer part. Computers are just a tool to make the gears turn. You will be a much better engineer if you know what the gears look like.
Good luck. You already took the first step and you will make it.
Re:srsly (Score:5, Interesting)
"with proprietary closed source software [...] compared to the FOSS model"
I think you are mistaking possibilities with realities. Yes, open source has the *potential* to more eyeballs but then, all so much FOSS projects have are the two eyeballs from its only developer. Yes, FOSS has the potential to get rid of absurd timelines but then you see so many projects that deliver on a deadline, ready or not ready, or answer you about a bug report with a variant of "I don't have time to deal with old bugs, I prefer to expend my time on more bug-ridden features". Yes FOSS is not necesarily driven by maximizing profit, but they aren't necesarily driven by its quality (i.e.: they can be driven by it fun factor).
"because there is no profit"
Who told you that? That's obviouosly false. They can and certainly are for profit in a lot of situations, it's only that their revenue stream is not on selling use licenses but in the development fact itself (features on demand; I worked for a company like that -the problem is when this becomes a freemium model where known to be necessary features are not developed unless something pay for them) or in installation and support (and then it can be possible that never good install procedures or documentation will ever be produce).
"I wouldn't call it "hacking" though. I think its actually called "extreme programming" or "agile software development". "
But then antifoidulus is right: hacking something together and pushing it into production is, well, hacking and certainly has nothing to do per se with extreme or agile programming. Your approach can lead to a good solution (if the problem realm is not so difficult and you are good at it) as well as to a fast pile of shit that only worses as time and feature crap goes by. As such is the opposite to engineering, which is about insure the results.
Re:Reading List (Score:5, Interesting)
Add Code Complete to the reading list as well as The Pragmatic Programmer
Replace Code Complete with "The Practice of Programming" by Kernighan and Pike (yes, that Kernighan. Yes, that Pike) and you've got something. You can keep Code Complete for when you can't sleep (IMHO, YMMV).
MSCE et al (Score:4, Interesting)
I'm not an engineer. I used to be an engineer. I've worked in power stations, oil refineries, offices etc and helped educate engineering students at a university and been a member of IEAust and ASTM. However, due to a lack of jobs a bit over a decade ago and a career change now that I run the computer systems for a company and write a bit of code every now and again I'm not an engineer anymore. You can call yourself whatever you like and are perfectly justifed to use the title given to you but don't expect everyone to take it seriously, especially since professional engineers have a code of ethics that you do not have to stick to.
Re:GOF Design Patterns (Score:2, Interesting)
Sure, this way you'll know exactly how you should not program!
Re:srsly (Score:4, Interesting)
I'm a software developer by trade, and I'm also old enough to be of the generation where one has pride in one's work but, in my experience, many places where I've worked don't seem to share that same pride in a job well done. Most care far more about getting something, no matter how "bug-ridden" or "badly designed" out of the door so they can bill the customer.
I always remember this quotation from the great Niklaus Wirth [wikipedia.org]:
In a well known interview with Dr. Carlo Pescio, published in Software Development, June 1997, Pescio asks Wirth:
You probably know about the 'good enough software' concept popularized by Yourdon. In many senses, it's just a rationalization of what's happening in the software world: the first company hitting the market with a feature-rich product is more likely to win the battle than the careful, quality-seeking company. Do you think there is anything developers and software organizations can do about that? I guess many developers would be happy to be given more time to develop better software, but at the same time they are rushed in the name of corporate survival. 'Educating the users' seems more a wild dream than a possibility.
to which Wirth replies:
'Good enough software' is rarely good enough. It is a sad manifestation of the spirit of modern times, in which an individual's pride in his/her work has become rare. The idea that one might derive satisfaction from his or her successful work, because that work is ingenious, beautiful, or just pleasing, has become ridiculed. Nothing but economic success and monetary reward is acceptable. Hence our occupations have become mere jobs. But quality of work can be expected only through personal satisfaction, dedication and enjoyment. In our profession, precision and perfection are not a dispensable luxury, but a simple necessity.
Re:Reading List (Score:5, Interesting)
Debuggers work fine if you can run your code repeatedly. However, if you have a massive existing workflow that you're also supporting the tools for, then you want as extensive logging as is possible. This is also "debug by print". The big difference though, is that I can let it run all the time, and when something goes wrong, I can then pull up the log, and figure out what went wrong without having to start up a debugger, or redo the process at all... which is very important for intermittent bugs.
All that said, while I tend to eschew debuggers, and use "debug by print", both do not accurately describe the way I debug. I white-box debug code. That is I read the code and understand how it works. Sometimes, I need to know which path was taken or not, and I add debug printing lines. Why do I do things like that? Because I tend to work with virtualization and emulation, where in for example, I had a bug with an emulator that only manifest its behavior a second after the bad opcode was executed. With a ~4 MHz processor being emulated, that means that about 1 million opcodes had executed (~4 cycles per opcode) prior to the the behavior manifesting itself. The behavior also only demonstrated itself at least about 4 million opcodes in. It's a needle in a haystack to find the correct point at which to break the debugger, and intractable to step through the debugger.
Using a debugger is simply not always the best choice. It is commonly the best choice, but it certainly is not an omni-tool.
Re: Engineering (Score:5, Interesting)
Yep, with most of the big engineering firms I've worked for, it's maybe 5% hacking and 95% documentation and packaging. If you can enjoy doing mostly the latter (finishing the last 10% of a project that ends up taking 90% of the time), then you should be able to get along fine. If you spend all of your time doing the former, then you will quickly become reviled by your co-workers :-P
Here's the junk that seemed important to engineering companies:
So, in summary, if you can find your way around some sort of toolchain that involves doxygen, mercurial, make/ant, cobbler, jenkins, and redmine, to the point that you can hand a junior engineering a piece of paper (oops, I meant email a link to a desktop instruction) such that the junior engineer can build their own working copy of the product by themselves with nothing but cold iron and a revision tag, then you're doing well.
But really, the real trick is to figure out how to get everyone on the project team to use the same toolchain :-P