At the SCNA conference this year, the idea came up several times that a lot of software development, at least at an expert level, is done via “tacit knowledge”. That refers to that part of our understanding that is more automatic than effortful.
An analogy to driving a car is helpful – most of us, when we drive, don’t think out the steps in detail like “ok, I need to get the end of the key in that slot, then push it in until it stops, now turn it until I hear and feel the engine is running, now let go…”, we just get in the car and drive.
It’s not that we don’t know the steps, it’s just that we don’t go through them consciously after a while, we rely on our unconscious understanding instead, which is less effortful than having to think through every step.
The same is true in development, after a while. We don’t think about all the keystrokes we need to make our editors do what we want, we just do them. I’ve often said “my fingers know how to use emacs, my brain is still catching up”.
The same is true for refactoring, for patterns, for language constructs and even design approaches. We can learn these things to the point where we can apply them automatically.
There are many fascinating aspects to this idea, such as how do we learn things so that they’re accessible automatically, but the part of this idea I want to look at today is how to “activate” the automatic learning for a certain “mode” of thinking.
When driving a car, that’s basically what you do when you get in, sit down, and put the key in the ignition. You’re starting up the mode that says “we’re driving now”. You might have a little sequence you go through, adjusting the mirror, maybe the seat, making sure the mat isn’t tangled in the gas pedal. These initial steps are what helps put your mind in the right mode – they are your pre-driving “ritual”.
I realized I have the same kind of ritual for sitting down to do development, and that it’s grown progressively more specific over the years.
Clearing the Space
For me, I sit down at the computer, adjust my chair if needed, and clear my spaces. First, I make sure I don’t have any visual distractions in my field of view to the monitor and to my hands to the keyboard. This usually means shifting aside things such as the phone, any papers I was working with, and other accumulated detritus on my desk.
Then I do the same thing on my computer: I close any apps I might have had open that I’m not going to use for this session, most especially including email and chat. I clear the “virtual space” on my screen, get to the right directory, and fire up a nice blank Emacs.
Setting the Target
The second and step to my ritual is to mentally review where I’m going with this session. Let’s say my goal is to add a new many-to-one object to my persistence layer of an application: I review what I’m trying to accomplish – not how I’m going to do it, that’s design, and that happens as part of the session itself. I just go through in my mind what I want when I’m finished this next session, and make sure it’s clear, as otherwise I sometimes find myself just wandering around in the codebase fiddling with stuff, rather than getting a task done.
Turn the Glass
My final step is to turn over my hourglass. Yes, a physical (quite large) hourglass which sits in a prominent place on my desk, in my line of sight.
This one takes a bit of explanation: Some years ago I started using what’s usually called the Pomodoro technique. This is basically a process where you focus on a task for some specified period of time, usually about 25 minutes, then specifically stop and take a break. There’s more to it than that, but not much more.
My hourglass is my Pomodoro timer. Many people use an actual kitchen timer, which I suspect would work as well, but I find the audible alarm at the end of the timer cycle annoying. I realize the point is that you should break from your task at the end of the timer cycle, but I seldom find a good breaking point lines up exactly with that moment. The same is true for virtual timers, which I’ve also tried extensively – they tend to pop up just in the middle of a line of difficult code, breaking my concentration in a most unpleasant way.
The hourglass is different: It doesn’t make a noise, but it’s position right next to my monitor ensures that I’m at least peripherally aware of how much time I have left, or if the time has run out. When I look away for a moment, and notice the hourglass is run out, I take my break. Much less jarring, I find.
I also have a slightly larger hourglass as I prefer slightly longer sessions, about 40 minutes, and correspondingly longer breaks. This is just the cycle that works for me, your mileage may vary, of course.
So this, I’ve come to realize, is my ritual. It puts my brain in the “we’re about to code (or write)” mode, and tells my brain to engage the appropriate autopilot.
What’s your ritual? Drop me a line or tell me in the comments!