How much time is left for coding? or How does a software engineer spend time at work?

The success of a software company depends on many factors. A key one among them is the productivity of the software engineers at the company doing product development. This is especially true for startups.

The productivity in turn depends on many factors. The most basic one among them seems to be the time a software engineer can spend on coding. Have you ever wondered how much time is actually spent on coding?

In this article, I will use as an example of a typical software engineer ("the software engineer") working in a high-tech company in California (CA), USA and derive the time allocated to each task that the software engineer needs to perform. Coding is one of these tasks. I have validated these estimates in multiple Silicon Valley companies that I worked at.

First, let us remember some basics: A year has 52 weeks. Each week has 5 work days, yielding 260 workdays in a year. In California (CA), about 27 days or 5 weeks are spent as the off days (sick, vacation, holiday, etc.). This leaves about 233 work days or 47 weeks in a year. Each day has 8 hours of work on average, leading to 40 hours per week of work.

Next, let us pay our attention to the following key table. At a high level, this table is basically a list of relevant tasks and their time estimates for the software engineer.

This table has 15 rows and 13 columns. Let us examine them in detail before delving into the data.

The rows 1-3 (colored green) are for the "recharging" tasks such as sick days, vacation time, and official holidays honored by the company. These time estimates may change slightly from state to state or company to company in the USA. Note that software engineers in Europe usually get significantly more vacation days.

The rows 4-7 (colored blue) are for the "communication" tasks such as the company all hands, team all hands, one-on-ones with the manager, and any demos performed in "product days" or the like. These tasks are usually short but fairly regular.

The remaining rows 8-15 (colored beige) are for the "prod(uct) dev(elopment)". Column 2 lists the nature of each task within this category. They include planning meetings, design and code reviews, bug fixing, production issue fixing, etc. Of course the key task here is on the last row, coding.

Column 3 shows the average frequency or duration estimates for each task. Columns 4 and 5 map these estimates to hours per week and days per year.

The list of tasks and their frequency or duration estimates may vary for different companies but from experience I will be surprised if the changes are big enough to drastically impact the main point of this article.

Columns 6-9 start from the basics, 2080 work hours in a year, 260 work days in a year, 52 weeks in a year, and 100% allocation, and go down the rows, reducing these values as each task consumes time. In the end, the time left for coding is 41% of the total work time available! In other words, a typical software engineer spends less than half of his or her time on coding!

I wonder whether or not you find this figure of 41% surprising at all? In the companies that I worked for, this percentage got close to 50% but it was difficult to get better than that.

If you present this percentage to an executive or a business leader, s/he may think that close to half the time is wasted! In that case, it is important to correct that wrong assessment and emphasize that the (typical) software engineer actually spends 94% of his or her non-vacation time on product development, and that those non-coding tasks are also essential for product development.

However, let us ponder a bit to figure out how we can allocate more time to coding. This seems possible in three ways:

1. Eliminate some of the non-coding tasks;
2. Reduce the frequency of the non-coding tasks; or
3. Reduce the duration of the non-coding tasks.

Exploring these ways in detail are out of scope of this article; instead let me simply grab your attention to the top two most time consuming tasks. They are code reviews and bug/issue fixing. Note that both are intimately tied to software / product quality.

Code reviews should not be eliminated but they may be sped up by using better tools, sharing the load by multiple engineers, better software architecture, training, and the like. Similarly, bugs in software are unavoidable but their number, frequency of occurrence, and resolution time may be minimized by multiple means such as better tooling, better testing, better code reviews, due diligence after postmortems, etc. Again think about other ways of improving both. Note that these two tasks also have a dependence on each other.

What is the point of this table? Regardless of what rows or columns you will have in your version, I think a table like this helps avoid wishful thinking; it provides a tool to plan better and deliver on time. It is also a tool to identify what tasks kill the most time so that you can focus on optimizing them.

At a high-level, we can also use the data in this table as a back-of-the-envelope estimator. For example, "wasting" or non-productive use of a whole work day, say, by running a meeting or an activity, eats away about 1% of the coding time! If you make such an activity regular, say, once a month, which does not look much in isolation, you just take away more than 10% of the coding time! Now these are estimates for a single engineer; imagine you included N software engineers in your activity.

Another good use of the time estimate for coding is in getting better estimates for project delivery times. One way to get accurate estimates from software engineers is to ask them to focus only on the level of effort (LOE) estimates, assuming they will spend 100% of their time on coding. The reason for this is that a table like the above can be used to get accurate estimates on the time taken by other tasks over many projects, engineers, teams, months, or even years. In a way the only task that largely remains project dependent is coding. Since we know the percentage of time left for coding, we can easily derive a factor to multiply the LOEs to arrive at the total project time. For the 41% coding time, the factor is about 2.4, i.e., each LOE estimate needs to be multiplied by 2.4 to arrive at a more realistic time estimate for the project at hand. This factor can easily be adjusted for each engineer or team using historical data. If you want to be more aggressive, the multiplication factor is at least 2. Of course, if you are using the agile methodology so much that your customers do not care about any project delivery dates beyond the next sprint, that is cool too; just ignore this paragraph.

Finally, what is the point of this article? As in the name of a British radio show on BBC that I like, "Thinking Allowed." I will also add "Writing Allowed" as I believe writing helps thinking. All in all, I suggest, using a tool like the one I described above, you put down what takes time away from coding or other productive activities and see how you can eliminate or improve them. Also, if a new non-coding activity is proposed, see its impact before signing up for it. If it has to happen, see what other tasks you can eliminate to open up time for it. Remember that it is key to protect the time allocated to coding at all costs.

Note (Jan 1, 2024): I had to revise this article as it seems LinkedIn lost the original formatting.

Disclaimer: This article presents the opinions of the author. It does not necessarily reflect the views of the author's employer(s).