The guy that thought of the pet rock made a million dollars. I want to make a million dollars too. I’ve been racking my brain for the last few years to think of a brilliantly marketable yet simple idea that will help me to achieve that goal. I think I finally have it. Read the rest of this entry »
My wife accuses me of being “up in my head” when I get home from work, an accusation to which I plead guilty.
Programmers are obligated by definition of their work requirements to spend spend quite a bit of time “up in our heads,” which is part of what makes programming so fun. We build constructs in our minds and then through application of knowledge make those constructs reality.
This requires us to do a generous amount of juggling with our short term (and in some cases, long term) memory. Like the machines with which we work, we have a finite amount of memory and a finite amount of power with which we can concentrate upon something. We do our best work when we can devote our full mental resources to the task at hand.
It’s a given that at the beginning and end of every working session that we’re going to have to build up or tear down the mental “scaffolding” that we’ve constructed in our minds as we’ve worked. All of those little details floating around…what the values of this variable should be when this particular operation is performed, the nasty guts of the algorithm we were trying to hash out, where we were going with that abstracted base class and its decendants…all of that mental data is discarded. The next time we start working, we’ve got to re-remember all of those details, and that takes a good amount of time and energy.
The difficulty is that in a working environment most people (especially non-programmers) don’t really “get” what we do, and therefore they certainly don’t “get” the level of importance that our concentration plays in the success and efficiency of our work.
So when someone walks into my office and demands my attention, I’m forced to do a quick cost/benefit analysis (which itself distracts me from what I’m doing). If it’s the CEO, mental scaffolding be damned, I’ll do what I can for him at that moment. But if it’s, say, the administrative assistant to the sales manager, there’s a high likelihood that they’re not going to get my full attention at the moment, because it just costs too much. Joel Sposky posits that interrupting a programmer results in fifteen minutes of lost productivity, and I agree…it’s at least 15 minutes. The cost is even greater if I’m really having a better than normal day and am producing some better-than-average code.
I have to admit that there are times that I get interrupted that I nod my head and say “uh-huh, yeah” when in fact I’m going everything I can to not pay attention. What I’m really doing is desperately trying to keep the juggling act I’ve got going upstairs in motion so that when the distraction departs I can return to work without losing my momentum. This rarely works though, and I end up having to shut down construction, turn to the person, admit I wasn’t listening and tell them to take it from the top.
The trouble is this: how do we communicate this issue to non-programmers without coming across as group of prima donnas? Programmers aren’t known for their suave social skills as it is; placing a restriction on conversation doesn’t help the issue. Telling someone that what you’re working on is important doesn’t seem to work because everybody thinks that what they’re working on is the most important thing going at the moment.
I’ve started to go with the construction site metaphor, explaining to people about the mental scaffolding and how much time it really costs if I have to devote myself to a non-critical query. Sometimes people get it, and sometimes I just get a blank look.
There is an inverse relationship between those whose look back at me blankly and their access to the software development area.
