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?"
srsly (Score:0, Insightful)
the heck are you talking about? nobody in the 'real world' is any different. hacker? give me a break dude.
Be a hacker (Score:5, Insightful)
Huh? (Score:5, Insightful)
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."
What do you think "engineering" is? (Score:5, Insightful)
An "engineer" is somebody who takes the time to understand a problem, and creates something to solve that.
Having done software from scales ranging from "quick shopping cart application" to enterprise scale organizational relationship management software, the only real difference between the two is that with the latter, you create a large number of smaller projects roughly the size of the aforementioned shopping cart application, except that the "users" are often other pieces of the same system. In larger systems, you'll be talking with other developers who have built or manage the pieces your parts will communicate with. You'll read more documentation, and it will be generally of higher quality than the shopping cart scripts.
Don't *ever* lose the "hacker" mentality - exactly what you described is what software engineering is. The toughest part IMHO is getting to an understanding of what the end user actually needs. That's far and away harder than all the other stuff, which boils down to implementation details once you understand the algorithms.
Hacker vs engineer (Score:4, Insightful)
Predictability (Score:5, Insightful)
Being a software engineer instead of a hacker is all about predictability:
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 (Score:5, Insightful)
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.
Difference is level of detail and corner cases (Score:5, Insightful)
I think the main difference between "hacker" and "engineer" is the level of detail and concerns on corner cases that you want your code to be able to handle and/or tolerate. Having worked as an engineer for some years, basically I boil down the job to three things -- 1) good clear communication of what the problem to solve actually is, 2) solving the problem such that the solution "meets spec", 3) trying to make sure that the solution continues to work within tolerance in any typical adverse conditions the solution needs to handle. Occasionally you may need to do some kind of formal verification that the solution will be wtihin tolerance in typical adverse conditions. With programming this verification might involve a test suite, code review, fuzzy input testing, memory leak testing, security audit, etc.
But in your particular situation it sounds like you're going to learn what you need on your own on the job one way or the other, so for now I'd say just relax and figure out what you need when you get there. i.e. I think you might be over-thinking this right now. ;-)
Maintainability (Score:5, Insightful)
Agile vs. Waterfall (Score:4, Insightful)
Your contrast is not really hacker vs. engineer, but agile vs. waterfall.
If you think building software is like building a building (spec it out in detail before you start, write tons of documentation, resist any change orders)--that's "waterfall" methodology, what you are referring to as "engineering."
If you want to start with a software sketch, show the sketch to your customer, and then incrementally improve it until the shape develops into something really useful and valuable--that's "agile" methodology, what you are referring to as "hacking."
Both are totally legitimate forms of software engineering. But waterfall-style "engineering" is cumbersome, slow, extremely expensive, and tedious. If you love programming, pick a small company with an agile mentality. I've done both styles, and I don't ever want to work in a large software shop again!
Re:Try to get a real engineer as mentor (Score:5, Insightful)
Meh.
Which came first, the engineer or the engineering degree?
Engineer (Score:4, Insightful)
The biggest problem most techs face is their own arrogance. Your desire to mature as an engineer sets you apart from many of your peers.
Perhaps on a more practical note, I'd suggest that you plan to spend six months to a year working in a beauracracy nightmare shop (eg a bank).
If and when you come out of the end of that experience, you will be much better positioned to apply the theoretical knowledge, and you will also be sufficiently jaded with process overkill.
However, my strongest suggestion would be to keep doing what you're doing. Allow a little time each week to continue developing your expertise. That habit distinguishes the masters from the journeymen.
Re:srsly (Score:5, Insightful)
>nobody in the 'real world' is any different
And the public wonders why most software is bug-ridden, badly designed shite.
Re:Huh? (Score:4, Insightful)
It's great to end up somewhere that wants you to lead the way forward, but even then you have to develop the social skill of bringing people along with you by earning their respect and trust. Most people want to see you "do it their way" first in order to prove yourself.
Re:Don't worry (Score:5, Insightful)
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 (Score:1, Insightful)
only a problem for software you pay good money for
with proprietary closed source software, users pay to become beta testers because not only are there less eyes on the source compared to the FOSS model, but closed source projects are run on unrealistic timelines and budgets. software companies make software to maximize profit, not to produce bug-free product. they do enough debugging to minimize complaints to a point where they can maintain their reputability, but no more. once the release date is reached, the product moves from development to sales, and the development team moves onto the next product.
FOSS is often a step behind, but that is because there is no such pressure to achieve marketing deadlines or breakeven, because there is no profit, but this also means that the programmers are free to take as long as they like to debug the software to their own satisfaction, and like any art or skill, programmers can be their own worst critics, particularly if they are developing software they wish to use themselves
I don't think I've ever come across an actual bug in a FOSS application because I stick with Debian Stable mostly (sometimes Testing), but even if a program misbehaved, I would be disappointed but given I paid nothing for it, I can't really complain that much. On the other hand, if I pay for a Windows game (Sim City 4 for example) and it crashes regularly on a newish machine and web searches don't reveal an answer (and the vendor's website is a useless piece of shit), I'm going to be pissed off for wasting my money.
In response to the OP, I don't have a CS degree but I develop software in my job (engineering), as well as at home. I must admit I've never debugged on paper before (is that what you meant by "prints"?). I usually just get a feature to a stage where I think it should work, and then I compile/test the crap out of it, finding/fixing bugs as I go. Its much more fun and practical than looking for bugs that might not exist on paper. Maybe its just because I'm not that old, but I couldn't even imagine debugging on paper.
I wouldn't call it "hacking" though. I think its actually called "extreme programming" or "agile software development".
http://en.wikipedia.org/wiki/Extreme_programming [wikipedia.org]
Re:What do you think "engineering" is? (Score:3, Insightful)
I'd upvote this more if I could. As someone who both codes for a living and hires engineers to do the same, what you are describing is exactly what I look for in an engineer. You can become familiar with more tools and methods, but at the end of the day, you [just] need to be able to solve problems well. The only additional challenge in the "real world" is breaking down larger problems, and solving them in "better" ways (ie: fits better with the rest of the system, is maintainable, is flexible, etc.).
Re:development styles (Score:5, Insightful)
You know, things have changed in East Europe during last decades. Electricity 0.14 EUR/kWh here vs. 0.15$/kWh in USA. Gas 1.4 EUR/l vs 1$/l in USA (caused mostly by taxes but that doesn't matter). Chicken meat 2 EUR/kg vs 2$/kg in USA. House property 1300EUR/m2 in Slovakia [globalpropertyguide.com] vs 200$/m2 in USA [globalpropertyguide.com].
Perhaps I've picked wrong sources or wrong goods. I challenge you to provide your numbers and I'll tell you the prices here (where the average income is less than 800EUR/month). I'm damn sure, that cost of living here is NOT a fraction of cost of living in US.
Re:Reading List (Score:5, Insightful)
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.
Re:What is an "Engineer" in the real world? (Score:2, Insightful)
engineers make shit happen, like blowing up a castle by building siege engines. scientists try to explain why it would work afterwards.