There seems to be a lot of (sometimes conflicting) stereotypes about software developers. They don’t like to talk to people, instead preferring to hide away someplace with no windows, lit only by computer displays. They don’t care about their appearance and seldom shower. When they do talk, computers are the only thing they know anything about. They have atrocious senses of humor. They like to create listings of how things are defined, especially themselves and the things they work with.
Personally, I try to shy away from this sort of thinking. I mean, the logical extreme is to become that guy posting on Slashdot about having Asperger syndrome in a bragging tone, which is, well, not that attractive prospect. (Note to the bored: I didn’t dig too hard trying to find some example comments, but I’m sure they’re not too hard to find. http://ask.slashdot.org/article.pl?sid=03/06/20/1237229&mode=nested&tid=134 should be a good start.)
However, there is a grain of truth in a lot of these sentiments about the techies. I mean, I’m not too antisocial, and I hated working in a windowless room a couple of years ago when that was what I was doing, but I do kind of hate thinking about my appearance (I shower regularly though!!) Especially though, it’s pretty understandable that software guys talk a lot about software. It’s not only what we work on, it’s what we work in, since for most software projects software is used to
- manage source code
- generate source code
- communicate about source code
- compile the source code to the finished product
- test the source code
and so on.
The thing is, a lot of the stuff that we work with requires a good deal of familiarity with a wide range of technical concepts. It does take someone who really loves to work on code to be good at working on code; and it does take a special kind of person to love working on code. Because honestly, tweaking a few lines of a text file, then hitting [Run] and hoping everything works so you can tweak some more lines that will probably break everything is a pretty painful experience. It’s one of those things that I love to have done and don’t especially love doing. So I (and I presume most software guys) end up spending a lot of time thinking about techniques, practices, tools, policies, and other ways of improving that experience. It doesn’t always leave time for other stuff.
Disclaimer: The Open Planning Project is full of developers who write novels and raise children and cook experimental dishes in their spare time. I’m not saying it can’t happen, just that it’s no big surprise when it doesn’t.
Recently I’ve been hearing a lot about the concept of ‘flow’ when working on software. That is, the idea of there being some special mental state that a developer needs to be in to be at his/her most effective. I’ve seen it referenced in software team management books, heard it mentioned around the office, read about it on the interwebs. It’s supposed to be this delicate balance of lots of details in a developer’s head at once, where disrupting him in the middle of things sets him back to square one, wasting the dozens of minutes that it will take for him to resume ‘flow.’
I can’t really speak about anyone who’s not me, but I don’t feel like this is the way I work on things. In general I take a lot longer than 20 minutes to get an idea of how things fit together (for example, I’ve been working on GeoServer for about 10 months now and I’m still picking things up) and a lot longer than 1 second to lose track of it all. In fact, one way that I approach tough problems (ie, those that my initial ‘bang my head against it for a couple of hours’ approach fails to resolve) is to just go work on something else and come back a (subway ride, weekend, couple of hours later) and find that I’ve come up with a decent solution subconsciously in the mean time.
I think this concept of ‘flow’ feels like a good way to promote antisocialism in development teams, deemphasizing communication between developers to promote a team of cowboys working on code that requires a lot of headspace to work on. It feels to me like it would be a lot better to keep communication frequent (keep the bus factor high, that kind of thing) and if it makes simple code a necessity in order to get stuff done, all the better.
So. What can be done to avoid needing flow? I find that it’s easier to slip in and out of development when I have a specific behavior I’m looking for, basically a test-driven development model. Another thing that makes it easier to keep my place is a graphical debugger, which lowers the amount of headspace I have to devote to modelling the software behavior. Finally, decent documentation (even if it has to be in the form of bugging another developer in an IRC channel) reduces that same headspace requirement by helping me to figure out expected or intended behavior more directly.
Maybe I’d think differently if I worked in an interpreted language; I have little built-in interruptions all day long when I restart GeoServer to try out changes I’ve made. But I am definitely wary of anything that discourages communication between developers.