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.