In my book, The Productive Programmer, I talk about the mechanics of developer productivity. This topic grew from a conversation I was having with my friend David Bock. We were talking about what would make a good book topic, and it turns out that both of us had independently come to the same conclusion while working with younger developers: the art of the command line is disappearing. Graphical environments were created to make it easier for novices to use computers, but it has the side effect of lowering the productivity of power users because we have to slog through the same affordances. He and I started writing The Productive Programmer (he later dropped out because of other commitments) as a giant recipe book of command line tricks. Subsequently, we started gathering command line tricks from friends and colleagues. But then a funny thing happened: I realised that it would be the dullest book ever written.
The problem with a book solely about command line tricks is the context: the only way that a particular recipe will help you is when you have the exact same problem. But when I started looking at the massive pile of recipes I realised they belong in groups. The natural activity of categorising them led me to a deeper organisational principle. By this time, I had been thinking about developer productivity for about a year, and I started noticing patterns in the things that make developers more productive. To that end, I eventually settled on four productivity principles, the underlying reasons that particular things make developers more productive.
The four principles: acceleration, focus, automation and canonicality. Acceleration is all about speeding up your interaction with your computer. Focus concerns how to deflect distractions, both environmental and on your computer. Automation provides lots of ways to automate common seemingly un-automatable things. And canonicality covers applications of the Don’t Repeat Yourself principle, originally espoused in The Pragmatic Programmer book by Andy Hunt and Dave Thomas. This article highlights a few examples of these principles in action, and how they make you more productive as a programmer.
Acceleration
Acceleration deals with speeding up your interaction with your computer, and mouse avoidance is one of the easiest ways. Have you ever written an application for heads-down data entry personnel? They hate the mouse. Why? Because they have realised that anything that takes their hands off the keyboard slows them down. I have news for you: as a developer, you are really just a specialised data-entry worker. The big difference? The information falls out of your head onto the screen rather than coming from a purchase order or fax.When coding, always prefer the keyboard to the mouse.
This suggests that you should learn every keyboard shortcut possible in your development environment. Of course, it’s easy for me to say that, but much harder to do. Have you ever looked at the list of keyboard shortcuts in Visual Studio? It’s incredibly long, and most of the keystrokes are ones you already know. Here are a few tricks to permanently learn keyboard shortcuts:
- When you see something on a menu that has a shortcut, dismiss the menu and use the shortcut. This teaches you shortcuts in context.
- Have a pair programmer pester you about it. One of my colleagues makes pairing tough: every time you use the mouse to do something better done from the keyboard, he forces you to undo it, then redo it with the keyboard shortcut 3 times in a row. He’s very annoying, but very effective because you learn the shortcuts fast.
- Repeat the shortcut quietly to yourself any time you use a shortcut. This sounds crazy, but repeating it pushes it into multiple parts of your brain, making it easier to retrieve later.
- Create a cheat sheet of the cool shortcuts that you never knew were there. This requires going through the giant list in the help system one more time, pulling out the really cool ones. You don’t have to remember the shortcut itself, you just have to remember that a shortcut exists for some behaviour that you want. Then, you can use your cheat sheet to find it.
- Put your mouse on the “wrong” side. If you normally mouse right-handed, put it on the left. This does two things: one, it feels so awkward that you’ll be more prone to use the keyboard and, two, it’ll teach you to be able to mouse with both hands.
You should also consider acquiring one of the two Visual Studio add-ons: ReSharper (my favourite) or CodeRush, both of which add tons of useful keyboard magic.
Focus
Focus refers to two issues: quieting your physical environment and eliminating distractions from your computer. I’ll write about the latter here, and talk about rooted views. A rooted view is a specialised Windows Explorer view that eliminates the distractions of the too-large filesystem. All developer hierarchies have gotten too deep. What worked well for 20 MB hard drives fails with 500 GB hard drives.
A rooted view allows you to set a new root folder in explorer. You create a rooted view by creating a shortcut to explorer using these command line switches:
explorer /e,/root,c:\work\citThis creates the rooted view shown in Figure 1.
Figure 1: A rooted view
Even though the address bar shows that this is quite a deep path, explorer treats it like it’s the root of the filesystem. Eliminating the distraction of files you don’t care about when working on a project allows you to focus just on this project.
Automation
Automation has obvious applications for software development, but I find that developers don’t automate enough. Computers are designed to perform simple, repetitive tasks over and over really fast. Yet an odd thing is happening: people are performing simple, repetitive tasks by hand on computers. I tend to try to watch my work habits and notice when I’m doing something for the third or fourth time, and try to automate it away.
Here’s an example. I was working on a project that required updating several spreadsheets on a regular basis. I wanted to open Excel with multiple worksheets, but doing it by hand was cumbersome (and Excel doesn’t allow you to pass multiple files on a command line). So, I took a few minutes to write the following little Ruby script:
#!/usr/bin/env ruby require 'Win32API' require 'win32ole' class DailyLogs private @@Home_Dir = "c:\MyDocuments\Documents\" def doc_list docs = Array.new docs << "Sisyphus Project Planner.xls" docs << "TimeLog.xls" docs << "NFR.xls" end def open_daily_logs excel = WIN32OLE.new( "excel.application") workbooks = excel.WorkBooks excel.Visible = true doc_list.each do |f| begin workbooks.Open(@@Home_Dir + f, true) rescue puts "Cannot open workbook:", @@Home_Dir + f end end excel.Windows.Arrange(7) end def self.daily_logs DailyLogs.new.open_daily_logs end end DailyLogs.daily_logs
This little script opens the defined status spreadsheets, opens them in Excel, and cascades with windows. Automating common office application functionality is easy in lots of scripting languages.
Canonicality
In The Pragmatic Programmer, Andy Hunt and Dave Thomas wrote perhaps the three most important words in software development: Don’t Repeat Yourself. This goes far beyond just avoiding copy and paste coding. By elucidating the DRY principle, they threw down the gauntlet of duplication wherever it rears its head.
On one of my projects, we had a problem passing information around. Developers were scattered around the world in Bangalore, New York, and Chicago. We were sharing a single source control repository (in Chicago) and keeping track of important decisions on a wiki (we were using the open source Instiki). At the end of every day, each developer was responsible for updating the wiki to indicate what he or she had done that day. You can guess how well that worked considering the inevitable mad rush to leave the office and catch trains that occurred at the end of the day. We tried nagging the developers, which only irritated everyone. Then we realised that we were actually violating the canonicality principle because we were asking the developers to document stuff they had already documented, in their comments when posting to version control. All the developers were good about writing descriptive comments.
We decided to leverage that existing resource, and to that end, we created SVN2Wiki, a little C# utility designed as a Subversion plug-in. When Subversion performs operations, you can write programs that it will run for you. SVN2Wiki sits and waits for Subversion to call it when someone checks in code. It then harvests the comments added by that developer pair and posts them to the wiki. After posting the comments automatically, we realised that our wiki supported RSS feeds. That meant that all the developers (and, it turned out, the manager) could subscribe to the wiki feeds to find out what had happened in the code base since the last time they looked.
Duplication lurks everywhere on projects and it sometimes takes some clever tricks to get rid of it. However, it always saves you time in the end, eliminating the chasing of things that have managed to get out of sync.
Summary
Modern office environments are tough on developer productivity. You have to be diligent with both your tools and environments to reclaim time lost to meetings, intrusive tools that try to do too much for you, and seemingly minor distractions on projects that end up eating valuable time. Being a productive programmer means you have to invest a little time each day to become more productive. However, when you start doing that, you buy time to hone your skills. And time is the one resource that every project could use a little more of.
Comments