Today, I'm going to tell you how getting a mouse with extra buttons will make you richer. No joke, and no Nigerian scam.


We've all been there: you're supposed to be someplace, and it's a couple of minutes before you need to leave, so you plop down and fire up Minesweeper (or whatever your crack-equivalent-of-choice may be). You burn a little bit of time, but not quite enough - just one more game. Then you've gone about a minute past the time you were supposed to leave... but eh, who cares; traffic is light this time of day, and you can make up a couple of minutes, no sweat. Just one more game.

Soon, you're counting on hitting all green lights on the way. Just one more game. There's never any cops on that one road - you can really book it there and make up a couple extra minutes. Just one more game. You can acheive feats of physically impossible speed, you got bit by that spider this morning, and you're pretty sure it was radioactive. Just one more game. You haven't tested your power of teleportation just yet, but you can just sense that it works. Just one more game. Rewinding time? No problem! You just need a time machine... and once you've got a time machine, you can rewind as far as you like, so it doesn't matter how long it takes to actually get that time machine. Just one more game.

An hour later, you realize that where you were supposed to be is called "work." Oh, yeah... work. Didn't your boss say something about being late all the time? Something like "you had better haul your dumb ass in by 9:00 AM sharp every day for the rest of this month, or you're fired!" Hey, the phone's ringing. What a coincidence, boss! I was just thinking about you! What? Fired? Oh, shit.


Oh well... at least now you have time to play Minesweeper, right?


It's quite common to look at a task and judge its significance by the amount of time it takes. For the most part, this is a reasonable thing to do - in general, more difficult or complicated things take a longer amount of time. Building a house in Age of Empires takes less time than building a house of cards; building a house of cards takes less time than building a real house; building a real house takes less time than building a skyscraper; and so on.

However, this assumption can also be extremely dangerous. If all of human activity was fully independent, and divided up into discrete little blocks that could be shuffled at will, it wouldn't be a problem. We could look at a list of tasks, figure out how much time they each take individually, sum up the numbers, and have a complete estimate for how long a project will take.

Of course, if we try to do stuff like that in real life, we're in for a world of hurt.


The fact is, the impact a task will have on your flow of activity is virtually impossible to correlate to the amount of time it takes, when that time is relatively short (arbitrarily, I'll say less than a day). There are a couple of factors that come into play here.

Getting Started
This is a big one when it comes to programming in particular. Every practiced programmer knows about The Zone - that mental mode you have to be in to really get anything done. Different people take varying amounts of time to get into The Zone, and any number of factors can affect how long it takes - but it always takes some time. Therefore, if you're going to do some easy programming task, you can't just estimate how long it would take you to finish: you have to include the time it takes to get started.

Getting started is a difficult thing, especially when you face a large block of tasks. A commonly cited motivational technique is to force yourself to start one simple, small task; you'll spend a fair amount of effort getting started, but once you have started, moving on to other tasks is vastly easier. This leads directly into the second thing that affects our work times:

Momentum
The human brain obeys the laws of inertia. If you're stagnant and not doing anything, it's far more likely that you'll continue not-doing-things rather than starting on something. The good news is, once you're moving, it's much easier to continue on with other things. In fact, it can become so easy to continue that we drop into The Zone one morning and suddenly realize it's dark outside and we're really darn hungry.


These are very important factors to consider when thinking about time management on small scales. To an extent, they also factor in to large scales as well, but that's really a whole separate area of exploration. What I'm interested in today is how time management goes wrong on the small scale, and the consequences.

Work flow can be disrupted by many things. In general, though, these all fall under two simple categories: something happens that is not what we expected, or we don't fully plan on the consequences of something that we do expect. Any time this occurs, the result is jarring, and can have dramatic effects on work flow - not just for the rest of the day, but sometimes for days afterwards as well.


Disruption at the hands of The Unexpected
Your compiler crashes. Your wife/girlfriend/mom/alien guardian walks into the room and tells you it's time for dinner. You find a really cool Flash game and play it for four hours without realizing. Any number of things can occur that we don't originally plan on dealing with, and when they do, they really screw up the plans that we did have.

The most obvious danger here is the loss of momentum. When we're interrupted by something, it takes our attention away from what we were doing, and usually incurs the cost of Getting Started again. However, the obvious problem is not the most insidious or dangerous one - the real problem comes from the buildup of frustration

Over time, little things add up. One too many crashes can push a perfectly sane and rational adult over the brink into utter depravity and rage. This is a nasty problem, because frustration is a threshold function. Up until a certain point, we may not even know that we're frustrated - the focus on the work can be so intense that we never even realize just how stressed we are.

For instance, just yesterday I was working on a project close to deadline. In fact, it was slightly overdue, because of some unexpected bugs I had introduced in my sleep-deprived stupor a couple of nights earlier. It wasn't a particularly important deadline to hit dead-on, so I wasn't worried about it, but I definitely wanted to get things done and make up for the time I'd lost on my dumb mistakes. Then, out of the blue, my Internet connection dropped. When one is working on a codebase that lives on another continent, losing Internet connectivity is a huge problem.

That much was frustrating, but still I had no idea just how close to "totally pissed" I was. The last straw was when the VPN connection locked up and died, taking the source control software with it - and, by extension, locking up Visual Studio and losing a few minutes worth of unsaved work.

Long story short, some things were said which would make our seafaring friends blush, and there are a couple of objects lying around which weren't broken a few days ago. I went from being relaxed, in The Zone, and working smoothly, to utterly irate, and incapable of focusing on anything. I lost almost two hours trying to recover from that blow before I realized that I really didn't need to have the VPN up to work on the code, and that the work I'd thought I'd lost was just a single debug logging statement that I had been about to remove anyways.


Misjudging Consequences
Clearly, The Unexpected can do some major damage. As if that enemy weren't scary enough, there's an even more hardcore boss-monster lurking in the shadows. Many people understand the dangers of interruption and frustration; but what you don't hear about nearly as often is death by slow stuff.

I've noticed an interesting trend among highly experienced and highly productive programmers: there is a sort of threshold point involved. On the one side of this line, a programmer may be quite skilled and productive, but they just seem to peak out - they appear to have reached the limits of their potential. Those limits are impressive, to be sure, but they're not biblical. These people are often team leads and senior programmers on teams where political dysfunction hasn't put morons in those positions.

On the other side of that line, there's these sort of amazing uber-hackers, who could crank out a running Doom clone in their sleep while in the hospital with 5 broken bones and a lung infection. They're the wizards, the superstars, the Free Electrons. They do magic, they singlehandedly save entire projects, and nobody quite figures out how they pull it off.

The difference is an important matter of mental perspective. This perspective is by no means the sole trick to becoming a legendary hacker - but it's an important part, and it's a trait that all the best hackers absolutely have to show. The telltale sign is an obsessive, unyielding, and non-negotiable demand for high-performance tools and hardware.


These guys demand the fastest, the best, the most efficient. Most of them have hotkey sequences and macros that do little tasks most of us don't even realize need to be done. These are the people who are hardcore devotees of Emacs, who write shell scripts to automate every little two-second job they've ever needed to do, and who seem to be pathologically mental about shaving milliseconds off of things.


The obvious question from us Common Citizens is why? Say you have some task that takes, on average, three seconds, like reversing all the letters in a highlighted block of text. Suppose we write a macro to automate that task, and it takes 15 minutes to write, and now any time we need to reverse some text, it takes only one second. The anal-retentive manager-types among us have already whipped out the calculator and determined that we have to run this script 450 times before it pays off.

OK, that one seems a tad far-fetched, but in certain scenarios it may be useful. But let's look at another nasty one, this time from my own experience: compiling a program and building an installation package. This task only takes, say, 8 minutes, and the vast majority of that time is spent waiting for the computer to do things - compile code, compress files, and so on. The main bit of human-interactivity is clicking a couple of buttons half way through the process. Automating the task could potentially reduce the wait time to 7 minutes and 50 seconds - but automating it will take two days of scripting, or, say, 15 hours. That means, if we think of time as little blocks that we can shuffle around at will, it will take 5400 runs of the packager for the time investment to "pay off."

The anal-retentive manager types are not happy. This frivolous automation is a waste, and since we'll never ship 5400 versions of the software, you'd damn well better not burn up valuable company time writing an automated system!


On paper, this looks pretty good. We can walk away from the situation smugly knowing we just saved some money for the company (because time is money!) and, if we got to yell at a programmer, we can feel extra-manly today.

In reality, that's a very, very stupid mistake. And that's the truth that ultra-productive hackers have realized: that time management is not a zero-sum game. There are effects far more complex and intricate than can possibly be handled by an Excel spreadsheet.


The emotional benefit of shaving milliseconds
Extremely productive people don't shave time off of their tasks to literally create a net time savings; in fact, in most cases, the cost of speeding up the task may never be recouped directly. That's a bit of a weird thing to handle, especially for anal-retentive manager types - it just doesn't make sense. If you're losing net time by doing all this millisecond-juggling, how can you be so much more productive than anyone else? (Read: how can you possibly be making me look so bad when you obviously suck at managing your time?)

The secret lies in the hidden emotional side. As with frustrations caused by unexpected disruptions, we usually don't even notice that this is going on. It's an extremely subtle effect, and unless you are specifically looking for it, it's remarkably easy to miss entirely. But hidden in that subtle little tangle of nanosecond cause-and-effect is an extremely powerful bit of truth.


Shaving milliseconds off of a task is not important because it actually makes the task faster. It's important because it makes the task feel faster. Every time we do something that takes time, a tiny little fraction of our brains steps aside and wonders, "can I possibly do this any faster?" Waiting for a program to compile, waiting for a program to start and get to a point where we can run a test suite, waiting for the results to print out on the dot-matrix printer so we can read the logs over a cup of coffee and slice of pie... even something as subtle as waiting to move the mouse across the screen to click an often-used button. All of these things add up, and every time we do them, that little doubt-circuit gets a little more sick of waiting.

If you can do a little bit of work to satisfy your subconscious mind that Task Q is running as fast and efficiently as it can possibly be, you will never again have those little doubts. The net result is that work feels less like work - it's smoother, more reliable, and more enjoyable. The less energy it feels like your work takes, the more you'll be able to do - the more momentum you will be able to exploit before running out of steam. It's entirely a mental game, but the stakes are high, and the pot is rich.


At this point, you're probably really tired of waiting for me to get to the point - how do multi-button mice make you rich? (You've probably even skimmed the top half of this entry just to try and find the Juicy Tidbits - quit being lazy and start from the top, you slacker! It's worth it - you'll see as soon as you read it.)

Here's the clincher: switching your hands between the keyboard and mouse is one of those little things that takes time. It's not much time, to be sure - in fact, I doubt anyone could make a case that it consumes a significant amount of time over the course of a programmer's career. But as we've already seen, the numbers can mislead us - not because numbers are dirty little treacherous bastards (although they are), but because the numbers don't capture the whole story. And the whole story is that the feeling of slowness is far more important than real passage of time.


I originally bought a Razer Diamondback Plasma mouse for my gaming machine. Recently, for no real good reason, I decided to try hooking it up to my development box. Since it was all set up, I figured I'd try an experiment, and map the extra 4 buttons it makes available. Two I have linked to Forward/Back in my web browser, and two are linked to Copy and Paste.

In the week since I've set this up, I've noticed a tremendous increase in how productive I feel - I'm running sessions a lot longer than I ever used to, and feeling less drained afterwards. I suppose it might be the illegal drugs I'm sampling on the side, but I suspect credit is due to the mouse buttons. They've saved me the trouble of moving my hands around more than I need to, and as a result my perception of my work experience has improved dramatically.

I've since bought a second Diamondback to permanently replace the old Logitech cheap-ass mouse I was using before.


So what's the moral of the story? No, it's not a concealed advertisement for Razer mice. (Although... if anyone from Razer is reading, feel free to drop me an email and we can talk about endorsement deals...) The moral of the story is that time management on a small scale is a tricky beast. Shaving down milliseconds is an important investment, even though it may not seem like it if we insist on treating time management as a zero-sum affair.

In the spirit of improving all you anal-retentive manager types (bonus question: how many times have I overused that phrase lately?), here's your action point for the day: go out and buy all of your programmers the fastest machines you can afford. Yes, the difference between 2.0GHz and 2.2GHz processors matters. Yes, I know the benchmarks say the price-to-performance ratio isn't worth it. To hell with the benchmarks. This is millisecond-shaving, and having the absolute top-end hardware will make your programmers that much less likely to subconsciously suspect that they are wasting time waiting for their computer to finish things.

Hardware isn't all, though - buy the latest and best tools. When applicable, consider buying a support license/contract and hiring someone to help streamline your installed tools. Divert a programmer or two specifically to go around the team and look for tasks that can be automated. Encourage everyone to set up hotkeys, macros, and other time-savers.

And put away that damn Excel sheet - you're not going to save time on paper. But I've got a nice shiny new mouse that says you'll become more productive as a whole.