Three Years — Part 2: Productivity
Working in enterprise software engineering for the last three years, I’ve started to recognize a few patterns in the projects, systems, and teams I’ve worked with. This second post in a series (see Part 1: Names and Types) touches on a non-technical but crucial topic: staying productive as a software developer.
Eliminate Unnecessary Distractions
There’s a lot of recent research that suggests that programmers who are routinely interrupted are less productive than those who have blocks of uninterrupted working time. Mental context that takes significant effort to build up when writing code is lost in a flash when focus is broken, perhaps with a peer’s question or automatic notification.
I do my best engineer on days where I have four to five, thirty minute segments of uninterrupted time, taking frequent, short breaks in between, like a loose Pomodoro.
After a week or so of this, your mind starts to fall into a cadence, which allows you to always work on the most important task.
One thing I like to do is turn off notifications for communication media that wants immediate attention such as email pop-ups and noises , SMS, calls, IRC, Facebook messenger, OCS, etc, unless the communication is critical to reaching your goal. Instead, take a break after focusing to answer all of them at once.
Always know what to do next
Always have a “priority stacked” list of things to do — anything from a well-groomed project backlog to Post-Its or scraps in Apple Notes.
After about a month of ‘rigorously’ using To-Do lists to manage work, however, you might find yourself looking at 200-item To-Do list with items ranging from things that “would be nice some day” to “do or die” tasks to “when pigs fly”. To avoid falling into this trap, there are a few axioms to live by:
Very few things are actually worth doing
Ver few ideas are worth your time to pursue
Very few things need to be done by you personally
Regularly prune To-Do lists — more than 50 actionable items is too many
The Eisenhower Box is, in my mind, a great tool to help keep your to-do list small. The general idea is this: Do items that cannot be done by someone else, delete items that don’t add value, and delegate the rest. Even as an individual contributor or engineer, there are often tasks that can be accomplished just fine by someone else that free up your time to accomplish work best done by you.
Gard Your Time
Guard your time fiercely. Be generous with it, but be intentional about it.
— David Duchemin
The axiom of “there is no such thing as a stupid question” is true — I’ve found that putting myself out there to ask questions is a real boon to my performance as an engineer. However, going along with avoiding distractions, there’s a related note on how to promote the same focus in others that you depend on when talking in person.
Unless the answer to a question is urgent and critical to completing your work, consider whether or not a person is focusing on something before interrupting. Would your ability to continue work be the same if your question were answered over email in a few hours? Might someone else in a group chat know? These are my default options when approaching others for help.
Don’t Chase, Take Notes
While working on a task and “in the weeds” of implementation, anything that isn’t directly related to achieving your goal should be noted down and punted. In practice, this means my Apple Notes is a bulleted, madman’s broken-english stream of consciousness. For example, during a task to write more integration tests for an existing system:
Where does GanttChartDecorator get its data?
How does call fail if bad network?
What happens if gantDec null?
Are we logging ql metrics here?
These questions types of questions are usually important enough to want answering, but probably not right now. Jot it down in detail (hyperlinks and code snippets are best for finding your place later) and move on. Then, at the end of your task or focus block, revisit the notes you’ve taken and shuffle any follow-ups into your To-Do list if necessary. This allows you to focus on your work while pointing out possible future work and keeping breadcrumbs to how to get back the context you had when you originally considered the question.
It’s also important to note that converting notes into tasks and deciding what to do next should be done at the end of a focus block, when context is still fresh. My favorite tools for this are Vitamin-R 2, OmniFocus, which work well enough together, and the standard Notes app for Mac.