A few years ago, The New Stack and Tidelift surveyed 400 developers, only to find out developers only code 32% of their time. In another field report by ActiveState, 61.5% of devs didn’t even spend 4 hours a day writing code. While the numbers only differ by margins, they pose a challenging question for the global developer community: Where is a developer’s crucial time going? Or to rephrase, Why devs are unable to code as much as they should.

A Day in Life of a Software Developer

While it seems obvious to expect code heavy days from devs, the reality can be pretty intimidating. Devs are hired to write code, however they spend more time maintaining, and testing it. Code management takes the most of a dev’s time with majority hours going in testing, code maintenance, and resolving security issues.

The core areas where most of dev’s coding time goes:

• Meetings and operations
• Administrative tasks
• Broken code reviews
• Environment management
• Lights on support
• Bug hunting
• Waiting for tests and builds to complete

As evident from different surveys, devs spent more than 50% of their week in intangible, non-core, and non-design tasks- either because of high SDLC blockers, or broken developer workflows.

An ideal developer coding time should be somewhere between 40-55% of their week; however, most teams today have been able to just cross the 41% mark, irrespective of company size and product complexity. Let’s see what overtakes most of a developer's coding time, and where developers are blocked in doing what they love most- write programs, solve problems.

Too Many Meetings Slowing Down Devs

While Dave Barry might sound a lot radical in condemning meetings as the main blot on human potential, the idea finds roots in discovering developer distractions. Coding requires deep focus; but with too many meetings scheduled throughout the day, devs find it hard to concentrate, and develop features.

In developer watercooler sessions, meetings are known as ‘planned interruptions’ - originally planned for a few minutes, and end up taking hours. The challenge doesn’t end here. An engineer requires atleast 30 minutes to get back into their ‘flow state’ and focus on writing code again. With meetings slated in different work halves- right from 10 am stand ups to 5pm catchup calls, developers often get frustrated. Imagine three 40-minute meetings spread across the day! Naturally, engineers will find it hard to progress on tasks, as soon as their devices snooze with another meeting notification.

Despite the push for creating real-time project management strategies, coding days are going down. It’s alarming especially when development costs are rising, and low developer productivity is costing $3 trillion to the annual software economy.

So, How to Fix Meeting Hours for Developers?

One way to reduce meeting fragmentation in devs is adopting async culture. Going async doesn’t mean completely abandoning synchronous meetings, but catching up with teammates as and when a need arises. Async meetings eliminate the need of daily standups by giving devs the flexibility to get back at their own pace, and time.

Hatica Check-in enables teams to run async standups hassle-free, so devs don’t have to compromise on their deep work hours. Hatica visualizes all important details including questions, participants, third-party integrations, full-fledged reports, at one place. All you have to do is tap an option and let Hatica do the rest.

For effective 1:1 meetings, Hatica helps engineering managers by improving visibility into developer workflow and ongoing tasks, so meetings become more than just status updates. They serve their purpose of finding blockers, and reduce incidences of unproductive work, so devs can free time to code.

Hatica also supports EMs and team leads in visualizing a whole work day for devs: meeting slots, focus time, and fragmented hours, so they know when to schedule meetings, or catchup adhoc.

Broken Code Review Cycle

In 2022, we talked to 100s of developers to know how they spend their official work hours. And the results were staggering. While we expected them to say- we code most of the time, we knew their answers to be the exact opposite. A lot of developers spent their focus hours ‘waiting’ for code reviews, project requirements, and feedback on next steps.

Code reviews, on paper, might look a simple process: a developer finishes a code piece, submits for review, selects the reviewer, and checks the reviewed code into a common code base. However, the process is one of the most complicated parts of the whole software development process.

Ever thought about what happens when a dev submits code for review and doesn't hear back? An elongated code review cycle means devs cannot work on their code in parallel until they hear from the reviewer. So, either they end up scrolling socials, or switch contexts more frequently. Both are a dent to effective coding hours, and in turn kills developer productivity.

How Can Engineering Teams Achieve Better Review Flows?

With Hatica’s review collaboration dashboard, EMs can visualize their code review backlog, IC involvement, PR collaborations, and code rework. All these indicators along with added insights from cycle time, and dev throughput metrics help in crafting a review cycle for the whole team. So, if Dev A is sitting blocked because their code is stuck for review with Dev B, the managers can proactively diffuse the situation either through reducing B’s workload for a while, or shifting code review to another developer with positive PR trends, and low response time.

Documenting your review progress via dashboard is also a landmark step in officiating code reviews as a ‘primary task,’ rather than putting it on the backburner- source of poor code quality and team frictions.

With enough contextual data in hand, managers can take steps on reducing task sizes, and batches for teams to merge code at a compatible pace.

Boosting Coding Hours Through Work Analytics

Non-core tasks are equally essential for product development, but not at the cost of developer productivity, or cutting down on effective coding hours. Using data-driven engineering analytics is one way to declutter a developer’s sacred workspace, so they can find more ‘focus hours’ to devote on codes, rather than thumping on people, or doing unproductive work.

The idea behind Hatica is to ensure there is nothing holding developers back from performing their core tasks, the work they have an expertise in- writing, reading, and maintaining code. With effective code review practices, review collaboration, and data driven meetings, developers should strive to focus more on coding, and less about external variables. With Hatica, no developer should feel blocked with their workflows- that’s what we strive for.

💡 Engineering managers use Hatica to track time and task distribution of their devs to drive workability, and boost productivity. Learn how we can help you build a data-driven culture for your teams. Request a demo with Hatica today!