BY MATTHEW THROWER, APPLICATIONS DEVELOPER.
No-one likes developers, except for other developers. They sit in corners, looking untidy, and spend their days under headphones, not talking. The work they do is esoteric and bizarre and no-one else understands it. Yet without them, a lot of businesses would be unable to function. There's never been a better recipe for a more annoying class of employee.
No doubt you've wondered what it is that they do, bathed in the quiet neon glow of monitors and whispering to each other in corridors. Here are seven answers that you'll probably rather not know about. Don't say you weren't warned.
1. Pleasuring Themselves
Developers love computers, at least they do when they're not cursing loudly and threatening to throw theirs out of the window. And they also love to learn. So they spend a significant amount of their days not writing code, but learning about it instead. This sounds self-indulgent and wasteful, but before you ban their internet access, think about it. There are almost no jobs that change as rapidly as development. And given how much is riding on efficient and secure development in the business world, you cannot let your developers fall behind the curve. Allow them their little pleasures: it'll pay off handsomely.
When they're not reading about development, developers like to spend their time reading themselves. They go back to their favourite blocks of code and re-read them endlessly. Sometimes they change a character or two and sit back with a self-satisfied sigh. If you ask what the hell they're doing, they'll call it "refactoring" instead of admitting they're just glorying in past triumphs. But refactoring is actually important. It's not hard to write code that works. It is hard to write code that works efficiently and that other developers can read and maintain with ease. That's what refactoring aims to do by revisiting code to make it better.
3. Abusing Other Staff
Ever noticed that a favourite topic of conversation among developers is how bad other developers are? They'll pull up samples of other people's work and sit, sniggering over them. Sometimes they'll even show the offending code to the offender and bask in the glow of self-righteous indignation. In any other department, that would be the first steps on the road to HR discipline, but developers seem to enjoy this kind of abuse. That's because taking criticism from your colleagues is a fantastic way to learn, grow and improve your code. Some places, including here at Response One, call it code review and make it part of a formal process. But the developers know it's just an excuse to snark at each other, really.
For people who preach about the power of digital data, developers sure accumulate a lot of paper. You can often barely see their desks underneath all the post-its, sheafs, books and pads that litter them. Worse, they cover most of this paper in diagrams using arcane gibberish instead of proper words. The trouble here is that the only really good way of representing computer code is computer code. Trying to explain it in proper words is awkward and verbose. Yet it's a necessary evil when it comes to pre-planning projects and communicating with other departments. Live with it. You'll be thankful the first time a developer leaves without having written down the names of all the build servers first.
5. Acting Crazy
It's bad enough that your developers seems to talk to each other in a language no-one else understands. What's worse is that when they do talk to other people, they're often loud, sweary and objectionable. Especially when someone interrupts them. They'll tell you development is a science well, surely, science should be orderly, logical and quiet? The truth - which few developers will ever admit - is that development is almost all barely controlled chaos. The human brain is not logical at the best of times, and trying to juggle tens of thousands of lines of code in your brain at once isn't the best of times.
Especially when someone interrupts you.
One thing developers never seem to come with is a positive attitude. Education, motivation and dandruff, sure, you'll get that in spades, but not a can-do approach to work. Give them a problem and they'll suck their teeth and whistle like a builder before telling you it's impossible. Add a time deadline to the problem and they'll laugh at you like you're the crazy one, not them. The fact of the matter is that most programming problems are solvable, but they're often harder than they sound. Computers are stupid and useless to a degree that it's hard to understand if you're not a developer. They're even more stupid and useless than developers. So when one says "no" to you, they probably don't really mean "no". But they do mean that what you're asking for is going to take a lot longer and cost a lot more than you might realise.
7. Writing Blogs instead of Code
You got me. No excuses for this one: better get back to work.