A while ago I wrote about programming being the ideal job. I must now retract that statement and revise the vocabulary. This article over at Hacknot talks about the differences between a programmer and a developer. I went on about a design compared to a developer, but based on this article (which I think hits the bullseye) I must revise it and change developer to “programmer.”
Anyway, reading through the Hacknot article was actually pretty funny because I’ve spent years talking to people (mostly the wife) about what I do and how it compares to other nerds I interact with. I have somewhat felt like the odd man out at work because I can hit multiple needs within a single job. Granted, most of the world doesn’t work like this, which is why this article is so great. Someone actually gets it and managed to put it down in words…and far better words than what I can write.
You obviously need “programmers” but since I am a “developer” I find some of what programmers focus on kind of silly given the task – that is, making software that people use. And I will make my points using what the article says about “developers.”
[Developers] focus more on delivering value than delivering program text…
This is a big one. Afterall, if you’re making software for people, don’t you want to give people value? If you don’t, they won’t like your product very much and won’t continue to use or just won’t buy it to start with.
[Developers] make an effort get inside the heads of their user base – to see the software as the users will see it.
This goes in hand with the value statement. In order to provide true value in any product, you need to know what your customer’s problem is. You can’t just throw a net and devlier top quality value to everyone. Granted most software tries to do this and does so fairly well (Google).
It is characteristic of the programmer mentality that every problem they encounter is perceived as an opportunity to write more code.
Although I can now dub myself a “devleoper,” I get caught in this trap often. I find a problem and start looking for how to solve with slick code and cool classes. The problem is this approach assumes you think the problem is a complicated one and requires more code. Just the other day an application I made stopped working for the customers and I started to freak looking at code and objects…turns out the network cable was unplugged. A simple problem with a simple solution, but I jumped the gun and assumed the worst. Bad developer, bad.
Developers don’t consider users beneath them, but recognize and respect that they just serve the organization in a different capacity.
This one is HUGE and by far the one I get into it the most with other nerds. Nine out of 10 nerds I interact with talk about customers like they are merely monkeys banging on keyboards. Now, I have been known to bash the occasional fool, but for the most part I do respect my customers because they know more about their problem than I do. If I don’t respect them I don’t get the information I need to make a quality product that delivers the value they want and need.
Those are honestly just a few of the points in the article that hit home and made be either roll my eyes or throw my hands in the air and scream “Yes! That’s it!”
If you are a person that plays with computers in a one-on-one fashion on a regular basis you should check out the article. You may find you’ll feel better about where you stand in the Nerd Army. But be prepared to defend your side – it’s rough out there.