It’s a common misconception among the general public that software engineers sit at their desks all day, pounding out code while drinking coffee. For quite a while, this is what I thought as well. When I took my first introduction to programming class at the University of Washington however, my professor asked the class this question, on the first day:

How many lines of code do you think the average programmer writes per hour?

Sixty? Thirty? A hundred and twenty? Almost the entire class, including me, laughably overestimated the number. My professor then revealed the answer, according to a recent study. The average programmer writes one line of code per hour. One.

Sitting in my seat, I thought two things. First of all, are software engineers really that inefficient? I estimated that it takes perhaps 5 minutes at most to come up with one line of code. Where then, do the other 55 minutes get spent? Secondly, a one-line-per-hour average must mean that there are software developers out there who can’t even write one line of code in 60 minutes. Surely they were hired by mistake!

It wasn’t until I started taking a few jobs related to my area of study, that I experienced all the other roles that software engineers had to fill between writing code. After finishing those jobs, I couldn’t imagine a software engineer who just wrote code all day. One line of code in sixty minutes seemed increasingly more reasonable. In my experience, here are the ten most common tasks for software engineers that don’t involve writing code.

10. Meetings

At my work, a lot of people have their work calendars open on their screen. When I take an occasional glance at these screens, I see meetings, meetings, and more meetings, from top to bottom. Sometimes, it’s hard to make out the white spaces in the calendar when they’re actually free to code.

I use the word “meetings” very loosely, referring to any span of time where two or more people are actively engaged in a conversation. Meetings can take place in person, or over the web. In a typical day, I may have meetings with zero or more of these people: designers, developers, managers, co-workers, human resources, company executives, and/or clients. Each meeting can last as little as five minutes, or go for more than an hour. Not to be neglected is the time spent transitioning back to work, which doesn’t happen instantaneously (read on for more about this.

I do not count emails or instant messaging as “meetings”, as they often serve to replace the purpose of meetings. Read on to #6 to find out more!

9. Code reviews

As software engineers, we’re all critics of each other’s code. We take time to scrutinize and provide feedback on code written by our co-workers. It’s the equivalent of a peer reviewer putting down red ink on a rough draft of an essay. The role of a code reviewer is not one that requires writing code so much as offering suggestions for improvement. Code review helps ensure consistency and quality across the entire project, and can even catch bugs that may fly under the radar otherwise. Personally, I like to give very detailed code reviews. In the past, I have spent close to a half-hour on a single code review, but otherwise I typically spend 5 to 15 minutes per review. The amount of code changed, my familiarity with the codebase, and even the coding style of the developer all influence how long a single code review takes.

8. Investigating bugs

In life one can only be certain of three things: death, taxes, and bugs in a software project. And when there are bugs, someone has to fix them. The process of fixing a bug is called debugging, and it takes two distinct phases. The first phase involves investigating the cause of the bug, the second modifying the existing buggy code to squash the bug. Investigating the bug can take anywhere between a few minutes to a few days. During the investigation, little to no useful code is written. The engineer may write some code to probe for the root cause, but this code is often discarded once the source of the bug is found.

7. Setting up your machine

Peek into any software developer’s computer, and you will find a potpourri of specialized tools, arcane commands, complex software, and various nuts and bolts that make their work possible. Very few of these things are preinstalled, and the installation process isn’t always as easy as clicking a few buttons. I have had to use certain command-line tools that take half an hour to download and install. To complicate matters further, some software installations require additional troubleshooting during or after installation. I had a friend in particular who spent an entire day trying to install a graphics library for Ruby, to no avail. The eventual solution was to switch operating systems — installing Windows and uninstalling Linux — which took another half-day.

6. Emails and IM

As software engineers, we use every medium of communication available to us. On an average day, I receive between ten and twenty emails, and have to keep up with a constant stream of instant messages. The time spent writing and replying to emails varies vastly, from a five second canned response to an hour-long, twice proofread report. Instant messaging is exactly the opposite. While each IM on its own takes a negligible amount of time to write, the time adds up when sending hundreds of messages per day.

5. Project management

Go to any major airport in the world, and you’ll see some form of a flight departure board, constantly updating passengers on flight boarding times, gate numbers, and arrival delays, should we occur. In the software engineering world, we use project management tools such as JIRA, which are our equivalent of a departures board. These tools allow everyone on the team to update others, and to be updated. It is every engineer’s responsibility to keep the board up to date. Found a bug? Report it. Finished a feature? Update the board. Need to delegate a task to another engineer? You know the drill. Updating a project’s status can involve gathering screenshots, writing a detailed report, and compiling documents for other engineers to download. The time spent on these tasks is not to be underestimated!

4. Reading documentation

No software engineer starts a job with perfect knowledge of everything they need to know, already in their head. There are simply too many new and existing technologies of varying popularity. Besides, most companies develop and maintain frameworks and tools only known to employees within the company. The key to understanding the potpourri of technologies being used is to read the instruction manual. We call it documentation. Documentation answers questions such as: how do I make the code do what I want? What style guidelines should I follow? How can I fix the code if something goes wrong?

Reading documentation is more challenging than reading a novel. Often, I have to jump around different sections of the documentation, gathering the necessary information that I need to complete the task at hand. Furthermore, navigating unfamiliar documentation can present a challenge in itself. For a new programming language or framework, I estimate that for every minute of writing code, I spend three more looking at the docs. And that’s a conservative estimate.

3. Writing documentation

For all the wonderful documentation that we have to work with, it didn’t come out of the sky. Most likely, another engineer spent time writing it. Writing documentation is like summarizing a newspaper article. The summary covers all of the main points, while keeping low-level details to a minimum. Documentation is most often written as comments in the code, which have no effect when the code is run. So why bother with lines of “code” that don’t do anything? As a software engineer, the code that I write is never for my own sake. Someone else will inevitably have to work with what I write, whether it’s a week from now or a year from today. Thus, it is important to write documentation that clearly and concisely conveys the relevant information.

2. Brainstorming

In every job I’ve had, I’ve kept a notepad and a pen at my desk at all times. I use it every day, sketching diagrams, taking notes, and even writing down short snippets of code by hand. It helps bridge the gap between what I conceive in my head and what code I need to type. As a visual learner, I write down my thoughts very frequently, scribbling through several pages a day. Other engineers I know like to think in their head. If you see a developer staring at the ceiling, don’t interrupt. They may be deep in thought.

1. Switching between tasks

Humans can’t multitask, although many of us think we can — and we try to nonetheless. What is often described as multitasking is simply a very fast switching between different tasks. But switches don’t happen instantly. For every switch there is an associated time penalty that involves storing away context related to the old task, and loading up context for the new task. Developers are rarely responsible for one and only one task; in fact, all of the above tasks are fair game on any given day. If I have six tasks to do in a day, and it takes my brain ten minutes to adjust tasks and reach peak productivity, then one hour of my time is already lost to task switching. That’s more than 10% of an eight-hour workday. And that’s assuming I only have to switch in and out of each task once.

Joel Spolsky illustrates this principle very well in Human Task Switches Considered Harmful, and it’s worth a read.

Bonus: Removing code

When existing code becomes obsolete, unnecessary, or replaced by newer code, we remove it! I consider this part of writing code, but if you define “removing 1 line of code” as “writing -1 lines of code”, this may explain how Fred Brooks in his Mythical Man-Month came up with “10 lines of code per day”*. Perhaps software engineers write 110 lines a day, then end up deleting 100 lines of code.

• Probably not the case, but a side thought I had.