I keep hearing that experienced developers spend more time reading existing code, debugging, researching, reviewing changes, and attending meetings than writing brand-new code. For people who develop software professionally, what percentage of a typical day or week is actually spent writing code? What usually takes up the remaining time?
5 Answers
For an individual contributor, roughly 40–50% of the week might be hands-on coding in a fairly productive role, though the number swings from zero on research or meeting-heavy days to nearly the whole day on an implementation task. Even then, “coding” usually includes reading the existing code, writing tests, debugging, refactoring, and changing configuration—not just adding new lines.
The existing architecture has a huge effect. In some object-oriented systems, a developer may write only a couple hundred lines while spending hours tracing execution through layers of small classes, then adding tests and infrastructure. Other designs make feature work more direct, so several hundred lines may implement real behavior in a day. Lines of code are a poor measure of output.
I agree that the architecture changes the ratio. The difficult part is often locating where behavior belongs and understanding the assumptions in old code, not physically typing the implementation.
Operations-focused roles can be even less predictable. A senior reliability engineer might average 20–30% coding, but an incident can consume an entire week with no new features written. More experienced developers also tend to spend less time typing because they are defining designs, reviewing work, coordinating decisions, and checking generated or contributed code. The important measure is solving useful problems, not maximizing new lines.
It varies enormously by role, project, and even the stage of the project. On a greenfield feature, coding might take most of the day. During maintenance or planning work, it could be close to zero. Research, requirements discussions, debugging, testing, documentation, reviews, and helping teammates can easily take more time than typing code.
That makes sense. I hadn’t considered how much the project stage and clarity of the requirements could change the number. Someone can spend weeks asking questions before writing anything if the requirements are unclear.
Senior and staff engineers often spend closer to 10–25% of their time writing new implementation code. The rest can go to design work, architecture discussions, code reviews, mentoring, planning, incident response, documentation, and supporting other engineers. In one research-heavy project, a developer might spend 90% of several weeks investigating options and only a few hours making proof-of-concept code.
The research example is useful because it shows that low coding time does not necessarily mean low productivity. Understanding the problem can be the work, especially when the implementation depends on decisions that have not been made yet.
That is higher than some of the estimates I expected, but the broader definition of coding explains it. Counting only brand-new feature code would produce a much smaller percentage.