Recently, I recalled attending a get-together with my friend Dan, who is a longtime programmer and researcher. This particular gathering was a mix of people and not just your typical computer types and researchers, which made for some very entertaining conversations.
“Hi, how have you been?” asked a non-computer (NCT) type partygoer.
“Not great. My Sun died last week,” replied a computer type (CT).
“Oh – I’m so sorry!” the NCT was horrified.
“It’s ok. I’m getting another one and naming it Bullwinkle,” the CT said excitedly.
The NCT, unaware that there was a Sun/son homophone in play, stood there aghast that someone could possibly be so cheerful about the death of a child and would consider naming one Bullwinkle. Dan, unlike this particular NCT, was much better at bridging the gap between computer types and non-computer types.
In a separate conversation, he was explaining to someone else what he thought separated programmers from non-programmers and or what made some programmers way better than others. Rather than launching into a technical discussion, Dan described it in terms of memory and recall. Programmers have the ability to hold a great deal of information about a problem in their head at one time and better programmers are able to hold even more. Before, this was extremely important when you were working on a terminal based system as the cost of looking up the arguments to a function meant pausing your editor (or firing up a shell in Emacs) and pulling up the man page, or digging out the physical manual because you couldn’t remember if the arguments to strcpy are ordered like an assignment statement or from/to. In this case, the true cost is the interruption of flow in your work. This particular example is nearly obsolete as tooltips and web-based documentation have reduced the time of interruption to close to zero. The problem, however, still exists in a macro sense. One must know and understand how to properly use a suite of calls rather than a single call.
Chris Parnin has a fabulous chunk of research which shows the cost of interruptions and techniques to mitigate the costs.
I agree with Dan about memory, but I think there is another element at play and that is the speed of bringing information into your head. For example, the PDF specification is 748 pages long. At any one time, I have around 1/4 of that in my head (much to my dismay). If I need to bring in more, it will take some time and there will be a cost of something else being replaced. So it is not just the amount of information you can keep in your head, it is also the time to bring in new information or to refresh old information. I frequently have this conversation around our office:
“Hey Steve, you wrote a chunk of code in DotImage to do x,” said one my colleagues.
“I did?” I asked. “Probably, I write a lot of code.”
Inevitably, the next step is to look at the code and verify that, yes, I wrote it and then what it does and how it does it. The quicker I can do that, the more productive I will be.
As we know, there is no silver bullet to order of magnitude improvement of productivity in software engineering, but if we act on improving our ability to organize, recall and learn we can make improvements that will help.
To this end, I suggest that you exercise and encourage your engineers to exercise as well, especially while at work. To a time-based tracking system, this would seem ludicrous. Isn’t this just time lost? Not at all. Many programmers continue to think about problems long after walking away from a computer and sometimes the act of doing something different helps unlock the answer you were looking for. Research indicates that exercise improves concentration and memory.
Here are some tips on how to make exercising fun and easy:
- Arrange daily walks amongst your staff, even if it’s just to pick up lunch.
- Don’t let weather prevent exercising. Have extra umbrellas on hand.
- Subsidize gym or pool memberships.
- Provide incentives for completing the Couch-to-5K program, like a pair of running shoes.
- Have a shower installed so employees can conveniently work out before work or during lunch.
- Recognize people for meeting their exercise goals.
It is easy to find excuses to not exercise, so as an engineer, or as an engineering manager, you should strive to remove as many obstacles as possible.
About the AuthorFollow on Twitter More Content by Steve Hawley