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?"

Comments

Reading List

[Anonymous Coward]

Add Code Complete to the reading list as well as The Pragmatic Programmer

Re:Reading List

[dutchd00d]

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).

Re:Reading List

[Chatsubo]

I scrolled down just to see if someone suggested Pragmatic Programmer, AC deserves a +1 billion mod. If you read just this one book, and apply it, you'll be head and shoulders above most of the industry in one foul swoop.

Secondly, you already know this answer by the way you phrase your question: Stop doing prints for debugging and use a debugger, that's it's job. You'll remove years of pain and anguish from your working life. Anecdotally: our "debug by print" hire gave up trying to keep up with the "debugger guys" after only a few months and left the company voluntarily, despite our suggestion that his debugging methodology is painfully slow.

Test driven development. Hackers say "but it takes more time to write the tests", I say: "But it saves me a butt-load of time tomorrow, it's a net win that will keep on giving". Moreover, TDD tends to result in cleaner designs anyway. I take this a bit further: If I have to write a new concept into a huge system, be it big or small, the first thing I do is write a smaller test with the new concept, iron out all the bugs and kinks until I understand the problem and solution properly, only then I dig into the "big code". Once again it's about saving myself time and headaches. (and, of course, try to write a module or component I could re-use in a similar situation)

Learn as much as possible about dependencies. Also the difference between library code and application code, and what bits of code go into which of these. (Pragmatic Programmer's "do not repeat yourself")

Basically your thinking has to shift from the short term to the long term: "I have to maintain this, possibly for many years to come, lets save my future self a lot of pain by doing some planning and doing things right the first time" (yet more pragmatic programmer).

Anything you get on this post though, is going to be a bit of a "learn C++ in 21 days" thing. We can tell you all about what we've learned and you can try to assimilate it all, but at the end of the day to get 10 years experience you usually need.... 10 years, but not the kind of 1 year x 10 experience lots of folks have. I found it very hard at first to "catch up" with mountains of information being shoved down my throat all at once, but...

Find a good environment above all else. Work with and for people who are highly experienced, highly critical, and aren't afraid to show it. Work with people who will gladly review all your code and blast it to bits for you. This is emotionally uncomfortable but pushes you up a steep learning curve very quickly. Programming can be a very social and cooperative learning activity in the right environment (look up agile while we're here). I'd say that way you can gain 2 years experience for every 1 on the job, possibly more. The trick is to tell the guys you shouldn't be listening to from the ones you should, and it may take a job-hop or two to find them.

Be a hacker

[cryfreedomlove]

I'm not sure you should try to get out of the 'hacker' mindset. Iterative innovation and continuous integration is much more rewarding than any waterfall approach. Good luck and follow your heart.

Huh?

[Gorobei]

If you can actually design a solution, throw together a suite of unit tests (that ideally show the basic API,) and deploy it to production, you are already ahead of 95% of the "software engineers."

Predictability

[Okind]

Being a software engineer instead of a hacker is all about predictability:

• Predictable planning: have it done when you say it will be.
• Software quality: use Test Driven Design to ensure your code behaves as it should.
• Predictable deployments: practice and simplify deploying your code for systems.
• Document the structure of your code, so the next guy knows what he's looking at.

There's more to each of these items, of course, but it's all about making it simple (KISS) and predictable. This sets a software engineer apart from a mere hacker.

You get a job

[phantomfive]

For experience, there is no substitute for working 8 hours a day, week after week, trying to write programs and make them better. Always be thinking about how you can improve the program you are working on (even if you don't actually have the time to do it), and you will quickly improve.

Even if you are just stuck debugging someone else's code (90% of what I've done over the last year), the process of doing that 1,600 hours a year will really improve your skills.

Hacking and Engineering

[Crash McBang]

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...

Re:srsly

[Anonymous Coward]

>nobody in the 'real world' is any different

And the public wonders why most software is bug-ridden, badly designed shite.

You have to specify SOFTWARE engineer

[Swampash]

So you don't get confused with a real, actual engineer.

Re:Don't worry

[Fujisawa Sensei]

Why is it people seem to think GUIs should be done by junior developers?

The front end code has to be the biggest pain in the ass out there.

Ooops I think I just gave away the secret.

Re:srsly

[turbidostato]

"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:Don't worry

[stjobe]

MCSE: Minsweeper Consultant and Solitaire Expert
At least that's what I was always told.