The Distracted Developer: Tactics and Workarounds for a Fast Paced Scene

I recently realized that I inadvertently tune out about half of all verbal instructions. Often I can “squint my ears” and pick up the gist of things by the context and fake it. If I actually start solving a problem, I literally tune everything out. (I noticed this last thing back in high school when I tried listening to music while studying: every once in a while I’d come out to the “zone” and realize that most of the album had gone by and I missed my favorite songs!) Another thing that happens is, if I don’t take care of an issue right away, I’m liable to put it off indefinitely. If I get overwhelmed, I have a hard time picking out what to work on and when.

Being a developer, my knee-jerk response to a problem is to solve it with code. This drove me to using source control for *everything*. And instead of cluttering my code files with large swaths of commented-out code, I cleaned that junk out and checked it back in. If I really need to see that stuff, I can dig through the repository– otherwise, there’s just one last distraction to burn up my productivity as I page through source code. (And who wants to stop in the commented sections every time you do a search?) Yeah, my desk may get a little messy occasionally, but I’ll use every tool and abstraction I can find to keep the code base clean and succinct.

And what do I do with that twenty minutes between meetings? Just blow it surfing reddit? Another trick I learned was to leverage that time with test-first development. Nobody wants to start working on something, leave their IDE open, and then come back and try to figure out what they were doing before. But twenty minutes is plenty of time to sketch out a few tests. And when I come back from the meeting, my brain will have kept working. I can come back and tune up existing tests, fix the glaring syntax issues that weren’t obvious at first, and write the tests that really needed to get written. And if I have my tests already set up and I’ve got maybe an hour between meetings? Well, the tests make it easy to pick something I can finish and check in before the meeting starts. And if I get a six hour block to just focus on my code? (Yes! Yes!) With tests in place, I can go heads down and not have to fret near as much about “the big picture”.

(Essentially, unit tests are a means of sketching requirements and design concepts during a time in which it would otherwise be impossible to think. Someone that doesn’t like to be organized or plan things out too much will do that stuff by default if they adopt a tests-first approach to coding.)

But then there’s the problem of coding something up and then endlessly having to iterate on it. Oh the pain! Yes there’s the hacker approach to eliminating the pain: create a custom scripting language for the problem space and build a GUI that can interpret the script and build itself accordingly. Bam! No more lame design meetings about what color to make the button on form number forty-seven. Next there’s the deployment issue. You’ve got to figure out how to compile and deploy the project with a single command or mouse-click. You will already be in pain if you have to fix something– no need to make it worse!

But there you are… you have the ultimate hacker tool set, yet you’re still miserable. Development is still painful and the gears are still grinding, as it were. What to do!?

You have to get out of your “dungeon” and go talk to people. If you’re a developer in a typical IT setting, your work impacts everyone in the company. You have a good excuse to strike up a conversation with just about everyone. Don’t expect people to open up right away. It may take five minutes for them to start talking about work, ten to start telling you about their problems, and 15 for them to actually tell you what they really think the solution is, but hang in there for it. Also there are the issues that people will tell you informally in the hall or on the floor that they’ll never mention to a manager or bring up in a meeting. Some of this stuff is critical to producing high quality solutions that solve the ‘real’ problems.

So back to me, Mr. Distracted…. I was the guy that got up to go get a drink a water all the time back in high school. At work… instead of going to the Coke machine for the nth time… I can take initiative on go on little “requirements gathering” missions and get something useful done in what would otherwise be a pointless excursion. As a bonus… if I can get the information I need on my own, that’s less meetings to go to and fewer middle managers that I have to work through!

And that guy who couldn’t keep up with his assignments in school? You know… me? Well, I’ve survived by touching base with people frequently. People don’t have to see the guy who can’t pay attention to verbal instructions as long as they see the guy that always strives to clarify the issue and pin it down. People don’t have to see the guy that keeps lousy notes as long as they see the guy that takes the time to personally review solutions one-on-one instead. And that guy who doesn’t do so well planning a schedule? People tend not to notice him as long as they see the fellow who often comes around asking the question “is there anything I can do to make your job easier” and “is there anything that we’ve discussed in the past month that hasn’t gotten done due to the recent overload?”

And yeah, I am the kind of guy that will lock his keys in the car. I’m also the kind of guy that keeps a spare set of keys in my wallet. Yeah… I am the kind of guy that is practically unable to match socks when they come out of the drier. But I’m also the kind of guy that takes a second to safety pin his socks together before he throws them in the dirty clothes hamper. If anything related to my general nerdiness and cloddishness becomes an issue, I’m humble enough to recognize that it’s my problem and creative enough to come up with a workaround to deal with it.

6 Responses to “The Distracted Developer: Tactics and Workarounds for a Fast Paced Scene”

  1. adnan. Says:

    If you buy all black socks of the same brand, you don’t have to worry about matching them. That’s how I do it.

    Who says socks have to match anyway? Who says shoes have to match? (there’s a great product idea!)

  2. Shae Erisson Says:

    Truly, I buy a yearly batch of Nike sport socks, and I only have two flavors at once, long and short. That way I have a pretty good chance of grabbing any two socks and having a matched pair.

  3. Mark Miller Says:

    The first paragraph matches me almost to a tee. When I was a kid I used to zone out everything except what I was intently working on. Since I became an adult I can space out from time to time (like I also used to do), which has the same result. People can be talking to me and I won’t hear a word they say, but I don’t zone everything else out when I’m studying anymore. In fact I’m pretty distractable when doing this, which is the reason I like a lot of uninterrupted time.

    Sometimes I have an annoying habit of “parsing” what someone else is telling me. If I’m listening to someone talk, and they’re droning on and on, I may only listen to part of what they’re saying, especially if the TV is on, or if my mind happens to latch onto some thought that’s really interesting to me, or if I’m stressed out; in other words, if I’m distracted. I’ll try to multitask, but I’ll only listen for words that catch my attention, and then I’ll try to make sense out of what I absorbed later. What’s annoying to others is I have this tendency to fill in the gaps in my understanding with meaning that is advantageous to me, not to the other person. For example, I’ll kind of do what they asked me to do, but I’ll do it in a way that’s easier for me, not realizing that I missed part of the objective of the task. I think this happens because I tend to latch onto the first concept I hear that has strong resonance with me, and then I extrapolate from there, totally missing the bigger picture. I don’t even realize I’m doing it until it’s pointed out to me.

    I haven’t tried TDD. I’m more of an experimenter. I’ll plan a little, but if I can, I like to just “grow parts” of programs, starting a thread of thought, and see where it leads. I think it’s the writer in me. I think TDD is a good idea though. I’ve heard it described as “writing the spec. in code” (ie. code talking about code), which is more precise than writing it in English. I imagine creating “mocks” (mock-ups–code imitating a real system) is a good idea for system design as well in some circumstances.

  4. Chris H Says:

    Really, I think that everyone has to devise solutions/life-style to suit their own personal mental quirks. So I don’t think you’re so unusual in that respect. It’s really more a question of whether the solutions you require are ones that tend to be common in society (so you can easily copy them), or whether they are rare (so that you have to devise them from scratch, which is a lot lot harder).

    Personally speaking, I could not function without an electronic organiser (aka PDA), to remind me of both big & small things, to have to do lists (& even databases!) to keep track of things, etc. I have tried using paper organisers, but it simply doesn’t work.

  5. name Says:

    Your wayyy too critical and negative with yourself. You just think of a way that works for you and it’s ok! There’s NOTHING wrong with it, and there’s NOTHING bad with it. There’s bad sides to the super uptight always keep a schedule, take way too many useless notes, type A(nxiety) personality.

  6. checksinthemail Says:

    I hear everything conversational and process it. If it gets really bad I’ll start talking my variables and programming out loud so I can ‘think’ over the noisy din.

    Music that I’ve heard dozens of times is the only thing that goes by unnoticed.

    So my favorite anti-distraction tactic: good earplugs (oh and turn IM and Email off)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: