Slashdot Mirror
Ask Slashdot: Transitioning From 'Hacker' To 'Engineer'?
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?"
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...
To put a witty saying into 120 characters, jst rmv ll th vwls.
"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.
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).