Drag Reduction

Ever so long ago, I explained my opinion of blogs.  At the risk of pretentiousness (not that it would be the first time), I’ll quote myself:

I mean, realistically, what are the chances that you’re actually going to miss that one-in-a-million blog posting anyway?  As soon as it happens, all of your friends with too much time on their hands are going to send you a link to it anyway.

Prophecy, that was.  Here’s that one-in-a-million post now, and, sure enough, one of my friends with too much time on his hands sent it to me.  Well, to be fair, he sent me a link to another blog post, which wasn’t quite as interesting (although it had its high points).  But primarily that post was notable for providing a link to this post: Thrust, Drag and the 10x Effect.

Now, I encourage you to read that full article, especially if you are, like me, a programmer (or, really, any job which requires sustained creativity).  But, in case you decide not to, I’ll give you a brief summary:

We all have different tasks that we do as part of work, or even as part of life.  Some of these tasks are productive, get-shit-done sort of tasks.  If you are a working programmer, that means essentially coding new programs.  If you are an architect, it means drawing up blueprints, I suppose; if we’re talking about home improvement projects you do on the weekend, it likely means interior decorating, landscaping design, creative carpentry, etc.  But many of the tasks we have to do are just administrative, have-to-do-it-whether-we-like-it-or-not tasks.  For programmers, that’s answering emails, going to meetings, filling out corporate forms and surveys and annual goals for career development, etc ad infinitum.  I’m sure architects have similar jobs.  For our putative home decorating weekend warrior, it’s fixing the toilet, weeding the garden, and traipsing through Home Depot looking for the right size screws.  The article refers to the first type of tasks as “thrust tasks” and the second type as “drag tasks.”

Thrust tasks tend to be long tasks (although interesting), and drag tasks tend to be quick (although often mind-numbingly boring).  Because of that, our natural job queue prioritization wants us to do the quick tasks first.  The quick ones can be knocked out more easily, giving a greater sense of accomplishment—more things checked off your todo list.  We also have a natural desire to get the boring stuff out of the way so we can concentrate on the good stuff.

But it turns out there’s a problem with this approach: the drag tasks eat up all our time and the thrust tasks are always relegated to the back of the queue.  Either they never get done at all, or they get done in dribs and drabs, with the leftover time after all the drag tasks are completed.

And the long/short dichotomy isn’t the only thing that distinguishes thrust tasks and drag tasks.  It turns out that you can get better—more efficient, more productive—at drag tasks ... but only up to a point.  Let’s face it: answering your email or weeding your garden is repetitive, and yet each email or weed is a little bit different.  Just different enough that you’re never going to but so good at it.  While the thrust tasks are the things you can not only get better at, but they actually deepen your experience and improve your overall performance in your chosen field.

More importantly, the longer you spend on your thrust tasks, the more productive you become.  And not just in the linear, spend-twice-as-long, get-twice-as-much-done sense.  The author suggests that spending twice as long produces 4 times the results.  This is of course unproven (and probably unproveable), but every programmer knows that long, uninterrupted stretches spent on coding tasks do indeed return results far beyond the simple accumulation of extra time spent.  You start to build a rhythm, and, when you really hit your stride, your productivity is blinding.  And that in turn means that when you only attack your thrust tasks a little bit at a time, in the leftover slots after your drag tasks are done, you’re achieving your lowest possible efficiency.

So that’s the “thrust” and the “drag” from the title of the blog post; what’s this about “10x”?  Well, the article refers to a popular concept in software development (which is supported by many studies): a good programmer is an order of magnitude (i.e. ten times) more productive than a bad programmer.  In fact, some people say that a good programmer is 10x more productive than an average programmer, who is in turn 10x more productive than the bad programmer.  Less academic support for that, but it’s one of those things that many of in the software biz feel to be true—there’s a certain amount of “truthiness” there, as Stephen Colbert would say.

Of course, that would mean that if you’re currently an average programmer, and you want to be a good programmer, you’ve got to improve your productivity tenfold.  That’s a tall order.  How can you go about doing it?  Take a page out of physics: increase your thrust, and reduce your drag.  Arrange your schedule to allow for significant chunks of time for your thrust tasks, even if that means putting off your drag tasks occasionally.

So that’s what the article says in general.  What did I get out of it for myself, in particular?

Well, a couple of things.  First of all, it identfied and delineated for me a problem that I’ve had off and on for years, and am actually undergoing currently in my present job.  When I move from one big task to another (thrust tasks, we’re talking about), it takes me a while—sometimes months—to “get into” the new project.  At the beginning of the endeavor, I generally fill up my time with drag tasks, leaving little time left over for concentrated, extended effort on the actual project work.  Gradually, either my interest peaks or my survival instinct kicks in if the project starts to fall behind schedule, and I dive deep into the work—all the drag tasks just fall by the wayside, I ignore my emails, skip meetings, drive my bosses crazy by procrastinating endlessly on paperwork, but I don’t care, because the work has siezed me by the throat, and it’s all I can think about, and I stay up late working until I can’t keep my eyes open any more, and then I eventually complete the job in a final exhausting flurry of activity, and then I start doing nothing but all those drag tasks I was avoiding all that time, and the whole cycle starts all over again.  I see now what my problem is.  I’m not giving my thrust tasks enough time and attention to reach critical mass fast enough, so I end up with too little work up front and too much work on the back end.  Instead of trying to do all my outstanding drag tasks every day, I’d be far better off saving them all up for certain days: allot one or two days a week to be nothing but drag tasks so that there’s plenty of time left over for uninterrupted stretches on the thrust tasks.  This would lead to greater efficiency overall.

The second thing is that I’m approaching my one day a week working from home all wrong.  See, we have a policy at my workplace that everyone gets to work from home one day a week (well, after they’ve had a brief breaking-in period where we get to know them and trust them).  This is a pretty great privilege for a corporate environment (meaning large public corporation, which happens to be the type I work for), and it’s a privilege that every general manager we’ve ever had was desperate to take away from us.  If you’re lucky enough to work in a smaller corporation, or one of the few tech-liberal giants (I think Google probably qualifies), you might not see where I’m coming from, but I’ll bet if you work in a more traditional business environment, even a tech-heavy one, you know exactly what I mean.  People who understand programmers and how to manage them (remember that I ran my own small company for many years, so I include myself in that group) understand that treating them like adults is not only a good way to get them to be productive, it’s the only way to get them to be productive.  Treat them like children and they will not only act like children, they’ll work hard to actively undermine you and screw you sideways.  And telling people that you don’t trust them to do what they’re supposed to do when you’re not looking at them is definitely treating them like children.  Now, don’t get me wrong: I’m sure there are categories of employees where that’s appropriate, and that’s why your basic average corporate middle manager has that attitude.  But for programmers at least (and I bet many other types of folks), this is a recipe for disaster.  So we very luckily have a have a head-of-tech (what would be our CTO if we were an independent company instead of a little piece of a larger giant) who understands this and protects our privileges very jealously.  Which is awesome.

Of course, we all have to do our part as well.  To help our CTO out in his never-ending war to keep management from fiddling with our work environment, we all have to make sure we don’t abuse our privileges.  Thus, when I work from home, I actually end up answering my email even more than I would if I was in the office: essentially, I’m so desperate to prove that I’m just as responsive when I’m at home that I end up being even more responsive when I’m at home.  The least little task that comes up, I immediately jump on it and complete it to prove that I couldn’t possibly be doing a better job if I were onsite.  But see what I’m doing: I’m using up all my work-from-home time—quite possibly the best chance I have at long, uninterrupted stretches of concentration—on drag tasks.  I’m screwing myself, and my company, by sacrificing productivity for the perception of responsiveness.  Not that perception isn’t important, of course, but, hey: there are limits.

So, handily, I see several opportunities for improvement here, all thanks to this blog post I just happened to stumble across.  And after 25 years at the professional programming game.  Just goes to show you you’re never to old to learn a new trick or two.  Of course, learning it and putting it into practice are two different things, so we’ll see how successful I am at that, but I’m pretty excited to try out my newfound principles.  I think I was already a pretty good programmer, but I’m also pretty sure I could be great.  Just gotta increase my thrust a bit.  And now I think I know how.