The term 'Engineer' is so widely abused in many parts of the world (such as the UK, where I live) that I may be msinterpreting your use, apologies if I am.
I believe there's a fundamental reason there's distance between the two. I'm on to my second degree in Engineering at the moment but I remember back in my undergraduate days.
One thing you realise quickly when you're learning alongside mechanical, civil and electrical engineers is that if you get it wrong, people die. You can't afford to do quick solutions and fix it later. You have to get it right first time or lives could be at stake.
You could kill several people with any one of the dozen or so robots we have downstairs and poorly written software. When you realise that, it changes the way you program.
I think that the definition still works - you just need to go farther down the scale towards pure engineering, and you start running into things like anti-lock-brake sensor programming, bridge design, refinery design, etc. The constraint "no failure whatsoever" is a pretty hard constraint, and while it may limit a lot of options and take more time and care, it would let you pursue perfection and responsibility to a degree not possible with regular business apps.
Yeah, I had a boss who liked to bitch about how NASA can do all this great stuff that works the very first time. I told him we could too if we had millions of dollars, and accepted the fact that it would take a long time to deliver even relatively simple components. And of course nothing would touch the running system without weeks of QA.
Hacker: beta is out the door in a month, features get tacked on every 2 days in the middle of the night, million users in a year, $100M exit in 18 months, anyone who sees the code would cry.
Engineer: can't release the beta because no proper QA cycle, no features can be released until the beta code base has been refactored with proper unit tests, less than 2000 private beta users after a year, $10M series B round after 18 months to keep the company afloat, everyone cries when they see their hacker competitors' new automobiles
Mixing metaphors from the post a little bit, but yes, in the startup world, if you take time to engineer before you have a proven product, you'll get squashed. On the other hand, with a proven and successful product, if it's poorly engineered, it will be too expensive to scale or modify. Different situations, different priorities.
hacking: 0 < version <= 1.0
engineering: version > 1.0
In other words, as soon as the product is "established" as a pile of hacks, all hackers should be taken off the project (temporarily) and a complete white-room rewrite should be done by a team of engineers, with one of the criteria being "to closely match the original product as possible while creating room for future expansion."
Then, the hackers (now known as "R&D") can have at the new codebase, but in a distributed SCM way--a hacker can only work on their branch, and any approved branch must be white-room redeveloped by an engineer before being put into the clean code-base.
...or, "What I Would Do If I Ran Some Sort of Military Project With Unlimited Funding and No Time Constraints"
"a complete white-room rewrite should be done by a team of engineers"
NO! NO! NO!
Never allow your engineers or anyone else to do a full rewrite of anything that currently works and serves the needs of your users. While they're busy rewriting (and it will take SOME TIME) you're not pushing out new features and your competitors are (remember Lotus 1-2-3?). And if you are pushing new features while your engineers are doing a rewrite they will NEVER catch up.
The solution: Make sure your application has tests from the start (and don't allow any excuses for not writing tests) and you can slowly refactor and rewrite small parts of your app, one bit at a time.
There are some exceptions to this, some companies have managed to successfully rewrite their software from scratch. But consider that a statistical anomaly and don't try to replicate it (and chances are it was rewritten by a team of super hackers, not a bunch of engineers trying to find the most perfect, scalable solution).
<quote>
hacking: 0 < version <= 1.0
engineering: version > 1.0
</quote>
nicely put! in the early stages it helps to "hack" at the early versions,people with inter-disciplinary skillsets.
i also think,guess its easier "to manage" engineers. that said - i think its easier for a hacker to manage /steer a bunch of engineers, than for an engineer to lead a bunch of hackers.
at the end of the day, i think a hacker something creates out of nothing. an engineer thereafter tries to keep it afloat without screwing around.
True, for any given project you need some of both. The whole post made so much sense when I was dealing in the abstract, but when I got to the end and had to tie it to development, I realized I had painted myself into a corner. I'll go back and clarify.
Thanks!
EDIT: I expanded the last paragraph to clarify that point. I think it makes more sense now.
Can we all stop pretending software development is engineering? For chrissakes.
We don't build bridges, we make valuable things people will give us money for. We solve problems. We respond to rapidly changing, conflicting requirements.
How many suspension bridge projects have turned into skyscraper construction projects over the course of two months? Now, how many web startups have radically changed their idea? Flickr started as an online game, you know.
I'm extremely suspicious of anyone who calls themselves a "software engineer."
I tried to convey the idea that it was a continuum between hacking and engineering. "Software engineering" is a lot closer to hacking than it is to hard engineering like chemical, aeronautical, or civil. It doesn't have the extreme safety requirements of building a bridge or a rocket booster, but it does have constraints on development cost, time, and performance that you can blissfully ignore in exploratory hacking.
With all due respect, your assertion that software engineering lacks extreme safety requirements is false. Like any engineering discipline, software engineering is applied to both safety critical and non-safety critical domains.
When I was in school this article[0] was required reading. Your life and safety depend on software engineers every time you dial 911, ride an airplane, etc. Not everyone is writing Facebook applications :)
It's hard to make definitive statements about field as huge as "software" or "engineering". Yes, there are areas of software with high requirements for safety (avionics), performance (air traffic control), etc, just like there are areas of engineering that don't have them (improving the manufacturing process to make toothbrushes cheaper). I'm using it in the statistical general sense, sort of like "Men are taller than women." More software gets written for business apps than anything else, and the strict safety requirements aren't there.
Note that this doesn’t mean that an engineer is any less creative than a hacker. On the contrary, the constraints provided by the engineering problem can provoke more creative and original thinking than that of the original invention.
I find it interesting that you talk about how engineers can be creative, but then end the piece with an comment that engineering "feeds my family", as if it were an otherwise shameful thing to be doing.
Maybe I'm reading too much into it. In any case, sometimes I'm a hacker, sometimes I'm an engineer...but I get really annoyed when people think I should act a certain way because of my current job title.
Yeah, the job title things was just an excuse to introduce the continuum - I purposely picked engineer instead of software engineer in the rest of the post so I could talk about in terms of actions instead of titles.
About the "feed my family" - when you're on a forum like this one where so many of the people are young single guys sacrificing all to follow the billionaire/world domination dream, it's not sexy to say you make decent money fixing bugs for an app that helps gazillion dollar companies make more money. I get to do some cool stuff (that I probably wouldn't be doing in my own projects) and facing different constraints, and I do it while doing a good job providing for my wife and kids. No shame in it at all, it's just atypical for Hacker News.
I understand. I'm not sure why that caught my eye, but if I had to guess, it's because it was the one bit of wishy-washy-ness in otherwise solid writing.
I was right there with you on the Ikea metaphor, and thought you were doing a great job of defending the creativity of the lowly engineer, but then you seemed to go apologetic at the end. I hope you don't think I'm arrogant, if I suggest that you cut that bit out. ;-)
"Right now I'm a software engineer (really, it says it on my business card!) and it has been good to me. I get unusual technical challenges that I wouldn't have come across in my own projects, and unlike the "friend's couch and ramen" startup life, I can feeds myself and my family and live comfortably."
When I talked this idea out in my head, it was originally "Scientist vs Engineer", but I changed it to Hacker for the article because of the kind of people that read my blog.
It wouldn't surprise me to learn that the kind of people who used to go into physics now hack. After all, I have a phd in physics, and I find hacking to be really fun...
This comment is very, very interesting... I keep reading about physics people who now are running 2.0 companies and that kind of stuff. But my question for you is: don't you miss science when working on a 2.0 environment? Or how do you correlate one subject with the other?
Yes, I miss practicing science a lot. It was a blast to do (I did theoretical work, which included a lot of computer modeling). But really, being a scientist is a frame of mind. Being a practicing scientist is a different story.
My immediate thought was hacker is an artist to the engineer's pragmatist... getting something to work is more important than its beauty, elegance or how few LOC are used, rather than something that is ..err.. hacked together(!?)
I believe there's a fundamental reason there's distance between the two. I'm on to my second degree in Engineering at the moment but I remember back in my undergraduate days.
One thing you realise quickly when you're learning alongside mechanical, civil and electrical engineers is that if you get it wrong, people die. You can't afford to do quick solutions and fix it later. You have to get it right first time or lives could be at stake.
You could kill several people with any one of the dozen or so robots we have downstairs and poorly written software. When you realise that, it changes the way you program.