How to feed a developer
Posted on: 15 July 2012
I'm a web developer by trade; concerning myself more with how stuff works, rather than how it looks. It's somewhat of a cliche, but, as with a lot of people, I don't feel I chose my career, it sort of chose me. I simply did what I found interesting. I liked computers, so I did 3 years at University studying them; got myself an internship, followed by a job, and since then haven't really looked back since.
It's interesting when you step back and look at the job and try to figure out what makes you tick. What is it about your job that keeps you stimulated and coming back for more. For me, I hadn't really thought about it a whole lot. That is, until I stumbled across an article online entitled "The care and feeding of software engineers (or, why engineers are grumpy)".
This is an insightful opinion of a front-end consultant responding to an article accusing software engineers of saying "no" too much. He begins explaining the stereotype of an engineer, that we can be "arrogant, disagreeable and moody", and I agree with that. I've found myself to be at least 2/3 of those things sometimes on a daily basis. The article is quite in depth, but the take-home point, at least for me, is that, all developers want to do is create something and get it out there for people to use. When this process is hindered, we're infinitely less efficient.
We are creators. We enjoy buildings things for people to use. Whilst the complications and politics of our daily jobs often cloud this, when all is said and done, this is what makes developers tick.
The stereotype is, software engineers are good at programming, we just like to code all day long, and when we get interrupted we get angry. Whilst this simplistic view isn't untrue, it's often a lot more complex than this. As the writer makes plainly clear, we're "Creators, not builders". When we're told to code something that's been speced out and signed off, we're not creating, we're building. We are ideas people, we have an opinion about everything, and when we're thrown into a project with all these decisions made (often wrongly) we're already disheartened.
As the author points out, "engineers are highly logical"; sure, our code is the moneymaker, but if we're part of the creative process from the start of a project, it's that much easier when it comes to building the product. And more often than not you get a better-built product with less bugs at the end of it.
In conclusion, the article is a must-read for developers and project managers. The former for that "yes! Someone understands me" feeling, and for the latter, to help understand and get the best out of your developers.