Hacker or Developer?
Jay Fields has a post up today where he makes a distinction between Developers and Hackers.
Time after time I see requirements gathered and presented in a way that is totally disconnected from the business problem that’s being addressed. There are two ways to handle the situation.
- Write the best code you can.
- Talk to the business.
Hackers generally go for the first choice, which doesn’t guarantee failure. In fact, a good hacker can still deliver code quickly enough that the business will be happy. Often, he gets it right on the 2nd or 3rd try.
But, a developer can deliver what the business is looking for the first time. A(n often) quick conversation with the business ensures that the developer knows what to work on and how it will benefit the business. This dialog often leads to a superior solution implementation where the business gets what it wants and the developer is able to do it in the most efficient way (e.g. I don’t need a beautiful website, I need a command line application).
It’s essentially the same distinction I tried to make a while ago, although I used the term Programmer instead of Hacker. Maybe if I’d used the term Hacker as well, I might have avoided some of the heat I took for those definitions 🙂
Interestingly Jay too suggests — although he doesn’t say it outright — a definition where human interaction and taking the Customer’s view is what distinguishes a developer, rather than coding skills.
Cheers!
For terminology I like using ‘programmer’ for the people that are ‘just’ coding, and ‘developer’ for the others that are working the full spectrum from analysis, design, implementation and deployment. It takes a huge number of diverse skills to be able to bring a big product or system together.
For a while the term ‘business analysis’ was popular, defined as someone dedicated towards grabbing the business requirements. It died out because they tended towards hiring people without programming backgrounds. That didn’t work because they may get access to the one side, business, but they don’t understand how to turn that into the other, code. If as an analyst, you don’t know what you are looking for, you’ll waste a lot of time.
Paul.
Hi Paul,
I like your definitions.
There are several terminologies with loose or changing definitions out there: software engineers, interaction engineers, implementation engineers, developers, programmers, various types of analysts, hackers, hci experts, you name it.
But then again, it doesn’t really matter what we choose to call ourselves. It’s what we do that matters, and I think Jeff’s blog post highlights that in a nice way.
I think the distinction between those that do (1) and those that do (2) basically comes down to professionalism, which is something that is often in short supply in our industry – or should that be profession?
Alastair Revell
Managing Consultant
Revell Research Systems