Okay, so here’s what I think a lot of people might think developers do: Write code.
If you know a bit more about the job, you might also know that we write some documentation, test a bit and fix them bugs.
But there’s quite a lot more that makes up the day-to-day life of a developer which most people not acquainted with the pitfalls of this lovely job might not know about. So, here’s just a selection of stuff I find myself confronted with regularly.
What Developers Do
It takes hours. It’s not particularly fun either. But we do it. We install stuff. And then we update it. And then we install some more. And then we restart. And then two hours have gone down the drain because we had to install stuff and couldn’t really work on anything else in a concentrated productive way. But there’s no way around it and when that stupid Service Pack for Visual Studio is released we cannot really refrain from installing it, even though we know that it takes two hours and we need to close Visual Studio, so we cannot really do any coding in the meantime. Yes, it sucks and yes, we sometimes don’t realize what we’ve just started, until it’s too late, but it happens. It’s not an excuse for slacking time, it’s a fact of life.
Developers stare a lot. We stare at screens. We stare out of the window. We stare at the ceilings. We stare at the door. Don’t assume that we’re not working. Chances are we’re thinking. No, really.
The fact is that if developing software was just as easy as typing commands, you wouldn’t need specialized people to do it. Unfortunately (or for developers: fortunately) it’s not that easy and there are these times of the day where we just stumbled upon a problem that we have to really think about before it’s actually worth typing one more line of code.
Don’t mistake staring for doing nothing. And for developers, if you work somewhere where staring is commonly misunderstood for doing nothing, get the hell out! Anyone working with software developers needs to understand that part of our job is to think about what we’re doing. And while it’s nice to quickly draw something up on the whiteboard or have a lively discussion with another developer, some problems will only be solved by staring.
Marvel is pretty similar to staring as it involves the former, but for another reason. Plus, staring usually involves some kind of vacant expression while marvelling involves a kind of irritated, slightly crazy grin or something similar.
The best kind of marveling I know is when you fix a bug and realize that the code should never have worked in the first place. This isn’t as absurd or uncommon as it sounds. It has happened often enough to me. There are other kinds of marveling: incredibly good code, incredibly stupid code, a bug that just shouldn’t happen,… you name it.
Marveling might not be as critical to our job than staring, but it’s usually more fun.
Be Annoyed/Irritated/Totally Surprised
This might be the other side of marvelling. Where marvelling revels in the joys of an obscure bug, being annoyed or irritated just hates the bug for existing in the first place.
There are other reasons to be annoyed though, and bad code or stupid bugs are just a small part. There’s crashing IDEs for example, or slow data connections. There’s the one configuration setting you always, always forget to change and spending an hour to debug until you realize it’s THAT THING AGAIN.
Being annoyed is the part of the developer’s life where we start to rant. It might even be that the time we need to vent off and be done exceeds the actual time we spend being annoyed, but so be it. We’re just people, too. (Maybe a bit geekier.)
You can try and stop us and maybe even be successful, but you’ll take half of the fun out of our job.
On the plus side, developers tend to play around with stuff that might actually prove to be useful to their work, so unless you have serious doubts that they’re just goofing off getting nothing done, just let us play. We’re just trying out a little tool or playing around with some cool new technology anyway.
Fuck Things Up
We do that, too. Sorry.*
*One of the worst things I have had the pleasure to experience first hand (though I didn’t do it) was when a fellow developer accidentally overwrote one of our development web servers. And no, of course, there was no backup. On the other hand: there’s nothing like the sight of a developer with panic written all over his face. We recovered after the initial shock, and then at least you have a story to tell.