Earmuffs, and micro-techniques.

I need a mix of conversation and silence. Since my early hardware design days, when I shared an office with my boss, I have always bought a pair of earmuffs from the local gun shop to wear at work. With these on my head, I can happily sit in a crowded room or a shared office, tune out the conversation and go into a quiet space where I can think through issues. I take the earmuffs off, and can answer or ask questions.

Whenever my current earmuffs get stepped on, broken, or lost, I run out and buy a new pair. They add a lot to both my peace of mind and my productivity.

Micro-techniques are the tiny things that speed up everyday actions. What is the fastest way to tie shoelaces, copy columns in a spreadsheet, copy a method from one class to another, tell if a schedule is out of whack? How does one place CRC cards on a table for easiest manipulation? I collect these all the time, and notice super-productive people do the same. Kent Beck added a button on his Smalltalk debugger window: Add Method. When he was in the debugger with a NotUnderstood error, rather than exit to an edit window to create the method, he would just push the Add Method button. That saved perhaps 45 seconds of clicking and typing. The big savings wasn't in the 45 seconds, but the fact that he didn't have to break his flow of thoughts or actions. Boom, the method was there and he could add to it.

Pile up a few saved thought interruptions here and 45 seconds there, and in a 30 minute period, a micro-technique savvy person will do much much more than someone else. It often makes the difference between managing to accomplish a task or not within the allotted number of minutes. For example, I was helping a project manager who was not very familiar with spreadsheets. Since I knew the tool and shortcuts, I was able to set up a good project template in a few minutes, where she would never have set it up at all, since it would have taken a significant chunk out of her day.

I consider the languages APL, LISP, Simula and Smalltalk top-level languages, because not only does it take little energy to get a lot done, more importantly, one can build up a repertoire of expression so that things get shorter and easier with time. I excluded Prolog from that list because, although it starts off with a high level of capability, that level of expression does not grow. A year after starting with Prolog I was still writing at the same level of expression as when I started. That doesn't happen with the other languages. Smalltalk is the one I'm most familiar with, so Smalltalk is still my currently favorite language. I'm sure there are other languages out there with similar characteristics, that I haven't learned.

Rexx is another language that is very quick, easy and expressive, for procedural programs. The object-oriented versions of Rexx have not been as handy.

Nothing beats canned routines and code generators The GUI painter systems are the most amazing code generators I know - they allow one to "splash" code all over the place, to get a lot of specification from very little action. I have occasionally seen programmers do something similar with databases: data models driving both GUI and database layout. Unfortunately, these seem not to generalize well. Spreadsheets also do a lot of computation based on very little user effort.

I don't "see" any productivity jump in the future. That's the depressing part. What I hope is that people will find more specific areas where canned routines and code generators can be applied, to generate remote function generation and accessing, better drag-and-drop database manipulators, even mini-languages that generate test scenarios to drive applications. Whether this will happen depends on individuals finding the right inventions.

Most programmers are interrupted too much. They have 3-8 projects they are supposed to work on, and "spin" as they shift from one project to another. They then have to report status on each project, and don't have time to make progress between reports.

In the most productive groups I have seen, programmers work on 1 - 1.3 projects at a time. They sit where they can get both quiet time and can ask and answer questions as they need. They work on relatively small assignments and get to complete them before they move on.

To date, I think it's more noise than signal. I look forward to being proven wrong :-)

Programming is a skill-based profession. Most programmers learn to type, learn syntax, and then think they're set for life. Good programmers are continually boosting their skill set, learning not just the latest technology, but also better work habits, better thinking patterns, and better techniques. Learn and practice any of the following:

• how to "derive" programs to get rid of boundary errors (the Gries book, The Science of Programming, is good),
• how to write effective unit tests (download JUnit and start with the tutorial),
• how to do "responsibility-based" design, with *and* without CRC cards,
• how to write a *short* and still effective use case,
• how to write a mini-language to generate test cases,
• how to auto-test your application,
• how to deliver system increments monthly,
• how to tell a manager what you've done and what you will do.
• And any of a dozen other things that will make you more effective.