Where do Software Engineers spend their time?

It all varies from one company to another, but let me break it down for you into different categories. Big companies are all about pushing their software engineers to be super productive.

Think about it this way: a poet wouldn’t call their time chilling by the lake a waste, right? But let’s be real, measuring important stuff is always fair game. You can’t really get better at something if you can’t measure it. So, I’m here to give you a simple framework to understand how software developers spend their time. The exact breakdown might be different for each company, but similar types of companies probably have kinda similar ways of grouping things.

1. Time spent in Design

The journey begins with the problem statement, usually from the Product side, where folks try to understand what are they going to fix. Then, at a high level, how are they going to fix it. It includes understanding of the systems in which a particular issue exists.

For this discuss sake, let’s take a fictitious example of problem statement ‘Merchants want to communicate with Shopper’ on an e-commerce app-site. Engineers would start by understanding what are the existing channels (email, app, site) and what is the desired channel (maybe push notification). Understand how much lift a new channel would carry versus modifying an existing one. Now, based on how much bandwidth you have and how ambitious is the goal, you will end up with what solution you will design.

Now engineers would start creating design documents, adding scope, out of scope based on their understanding. They will get it reviewed, and the reviewers will add more reviewers, or have some questions or stamp it.

2. Time spent in Coding

In an ideal world you would start coding after design, but most of the time there are pauses from legal, or waiting on exact requirements from UX designers.

When engineers are coding, most of the senior engineers, would also have a second thread on next project design, mentoring, supporting previously launched products. These context switches are very costly. Every time one gets out of IDE, for whatever reason, they lose about 15 minutes to 30 minutes just to warm up to the previous level.

Now, this bucket should count only the time you spent when an engineer’s IDE is full screened. Occasional manual reading, documentation reference and stackoverflow check are essential part of this flow.

One of the best ways to get a code review done, is to invite or go to the desk/zoom of the person doing code review and explain to them what are you doing. Engineers getting code-reviews done is part of their coding time.

The test cases you write, and fix the ones you are failing, is also part of this bucket. In good places, we care about customers in production and not test case coverage, so developers should add just enough test cases, to avoid surprises in production.

3. Time spent in debugging/investigating

a. Old bugs: Bugs that come your way from the maintenance pipelines, which include customer tickets, incident tickets, something found by beta testers.

b. Fresh Bugs: The bugs that you found in recently launched products/features or other bugs that are fixed.

Most of the time, more time is spent on

1. Knowing if it is a bug or a feature
2. Expected behavior
3. Getting a repro
4. Getting the right team that should be fixing the bug; compared to fixing the bug.

4. Time spent in Reviews (Code, Design, Requirements)

Reviewing is a crucial part of the software development process. This time is allocated for engineers to assess and provide feedback on various aspects of a project. Code reviews involve going through another developer’s code to identify bugs, suggest improvements, and ensure adherence to coding standards. Design reviews assess the feasibility and efficiency of proposed solutions. Requirements reviews involve scrutinizing project specifications to ensure clarity and completeness. Review time is vital for maintaining code quality and preventing issues down the line.

5. Time spent in SREing

Site Reliability Engineering (SRE) is the practice of ensuring the reliability and performance of software systems. Software engineers allocate time to activities related to monitoring, maintaining, and improving the system’s reliability. This might involve setting up monitoring tools, analyzing system performance metrics, and addressing incidents promptly. SRE tasks contribute to the stability and availability of software products, enhancing the overall user experience.

6. Time spent in meetings that are not core to your sprint tasks/bugs

Not all meetings directly relate to ongoing tasks or bug fixes. Some meetings might focus on team updates, project planning, cross-team coordination, or brainstorming sessions. While these meetings can be valuable, they can also consume a significant amount of time that could otherwise be spent on coding or other development activities. Balancing meeting involvement with focused work time is essential for maintaining productivity.

In summary, software engineers allocate their time across various activities, including design, coding, debugging, reviews, SRE tasks, and meetings. The distribution of time might vary between companies and projects, but these categories provide a framework for understanding how software engineers manage their responsibilities and contribute to successful software development.