Multi-tasking

When I first started coding I often struggled with remaining focused. While writing code, there is a lot of stuff going on in our heads that need to get put down into the computer. It turns out that code is best and the work is fastest if you can basically just type what you ‘see’ during prolonged stretches. Later you keep passing over it, again and again, editing it until it becomes clean and tidy.

As I grew in my abilities, I learned to focus for hours and hours at a time. In the heyday of programming, I had my own office, I could close the door and get emersed in the work. That was easily the best code I have ever written. It was very readable, the mechanics were discussed thoroughly and thought out clearly, the project had good strong conventions that we meticulously followed, and the code was consistent. Reuse was critical to the success of the project, otherwise, we would have ended up with way too much stuff. It was a very ‘technical’ development, a big distributed fault-tolerant cache that had high-performance specifications. Despite the complexity, we only ever had 1 known software bug in production. It was also my favorite job.

As Agile killed the profession, programming moved from being able being about deep focus to often just bouncing around throwing a lot of code fragments everywhere to see if we could get things working. Noisy open office spaces, lots of interruptions, stress, and drama, and maybe about 30% of the time necessary to get barely functional code.

It took some adjustments, but I gradually learned to work in a messy, loud, mutli-tasking environment. Part of the secret was learning to write a lot of stuff down. The core habit is to keep a ‘note’ of what you are going to do before you go and do it. If you are disrupted in the middle of working on something, you make a new note for the next task, jump to the new work and keep going. When you are finished, you go back over your notes and work your way back out of the pit. In rough environments, you might find yourself down 6 or 7 levels, really quickly.

Another great habit is time-boxing. That is, you try to allocate very specific times of the day to do specific work. Mornings are for big email replies, management issues, etc. After lunch, somedays are ‘coding days’, some are ‘meeting days’. Rather obviously, sticking all the meetings back to back helps keep you in ‘talking context’, rather than ‘coding mode’. It’s always been very different, at different companies, but trying to batch similar stuff together helps, thinking about it in terms of ‘focused work’ and ‘unfocused (chatty) work’ helps too.

Another thing to do is keep a separate list of boring tasks. When you are baked, work on stupid, boring, trivial stuff. When you have the energy, do the more cognitively demanding work. It does cause a bit of interference with scheduling though. When you are giving estimates, you have to give them in terms of the good days/hours. So, if most weeks consist of 2-3 days of insanity and drama, your capacity is really only 3-2 days of work, but it’s better to err on the lower side, so you are often down to 2. Thus 10 days of grueling, hard-ass coding are going to span 5 weeks unless you start clocking in overtime. If you keep clocking in overtime, eventually all of the days are ‘unfocused days’ and you’re down to 0, which gets messy with your employer (but at least the boring work is all done, isn’t it).

Sometimes I just cycle. Get four projects going at once, work on each until they hit a significant blocker, then move on to the next one. When doing this, the code itself can’t be rocket science, so it’s usually a little more brute forcey, domain-specific stuff. Then the blockers tend to be poor specifications, external decisions, ambiguities, etc. Most of them involve getting a conversation going with other people about some issue that needs to be addressed right away. So, the flow is to read back the items that need to get done (as per above), then work on them. Either close them off or jot down that you need to punt it into some discussion. When the little bits are all finished, flip over into ‘email mode’ and trigger all of the discussions. That project is now all jammed up, move on to the next project. Keep cycling between all of them, with the same flow.

Sometimes, shifting priorities will pop up that force a different order, but it’s best if you try to spend a bit of time first to close off the thing you are actively working on right now (by either finishing it or at least updating your notes). Working this way, keeps everything moving forward, and you keep a record of where you are and what didn’t get done yet. It doesn’t however produce great quality work.

My personal feeling is that spending the effort to get good or even great code is both faster and produces way better results for the users. We can rush through the work, at times they do only need crappy quality, but doing this all of the time gradually paints the entire effort into a corner. Technical debt is most often exponential, a little of it starts leaking in, and before you know it, getting anything done, at all, is a Herculean effort. Preventing that decline is equally, if not more important than getting out most features, but since that work is basically invisible to management and the users -- until it is too late -- people incorrectly ignore it. Still, the industry turned into this current direction, like a huge ship, so it’s not so easy to set it back on a good course. We have to deal with whatever madness that is paying the bills, so it is best to learn how to spew out lots of code, on many different tasks, all at once, even if you realize that people aren’t really getting what they need.