38

When I talk with other software developers, they often say that they write code for something like 8 hours a day. However, I have never once worked on a project where this happens. It's fairly normal for me to spend several days in a row where I don't write a single line of code.

I find that I spend, at most, 15% of my time actually writing code. The rest of the time, I'm researching the problem, investigating the data, discussing a problem with colleagues to figure out the best way to build something, reviewing other people's code, designing the architecture, configuring cloud resources etc etc etc. I find these tasks much more time consuming than writing code.

I'm not saying this is a negative thing. I find this time incredibly productive and valuable.

I'm wondering how common is this in other software development jobs? Am I an outlier here?

Improve this question
7
  • 10
    You have to control for job level and I suppose industry.
    – Michael McFarlane
    Commented Mar 21, 2022 at 16:29
  • 6
    Writing code for 8 hours a day on average? What next, a thousand lines of code a day?
    – Steve
    Commented Mar 21, 2022 at 18:13
  • 41
    My most productive day has been when I wrote negative 2000 lines of code.
    – Pieter B
    Commented Mar 22, 2022 at 7:32
  • 3
    "I'm researching the problem, investigating the data, discussing a problem with colleagues to figure out the best way to build something" I would count that as part of "writing code". You're not a monkey who types code without thinking. Writing code requires taking time to think about the problem, the data, the algorithms, etc. You do that with a pen and paper instead of a keyboard and IDE, but it's still part of the process.
    – Stef
    Commented Mar 22, 2022 at 9:13
  • 18
    your 8h/day peers remind me of the old joke "Weeks of programming can save you hours of planning"
    – Aaron F
    Commented Mar 22, 2022 at 11:17

6 Answers 6

Reset to default
31

Depends on Seniority

I'd say the percentage of time spent literally typing lines of code is inversely proportional to your seniority. Junior engineers get to spend a larger percentage of time writing code because they are not trusted to design/architect it, meet with stakeholders to gather requirements, fight with project/program managers over deadlines and deliverables, give presentations, etc. One answer said "code reviews should take less than an hour". Well, that depends a lot on how many other people on your team are doing them, how quickly they are writing code, and how seriously you take the responsibility yourself.

Depends on Cycle

At the beginning of a new project, there will be more time spent on investigating tools and technologies to be used in the project (libraries, frameworks, 3rd party tools, etc.). At the end there will be more time spent on fixing bugs, deployment, documentation, etc. The middle is likely where most of the coding time is spent. Or, if you're stuck on a maintenance team/project, you might be fixing bugs 100% of the time for weeks or months on end.

Depends on Project

The highest density of code writing probably occurs when making a prototype/proof-of-concept. There, any pretense at maintainability is tossed out the window and you are racing to assemble something held together by duct tape and crazy glue. Then I could easily see someone spend 8+ hours a day writing code, for multiple days in a row. Outside of that, the only kinds of projects where I can see sustained code-writing are things like framework migrations, large refactorings, or other kinds of upgrades which are mostly mechanical and involve a lot of busywork.

On the other end, I would expect to see the least amount of code writing when developing a brand new technology that will require new tools/libraries/frameworks that you/your team have not used yet. Evaluating the alternatives to determine best fit, negotiating requirements/deliverables, and all the other administrative overhead means that you may spend weeks without writing any code at all.

Depends on Scale

If you are working in a startup, I'd expect your proportion of code-writing to be fairly high, especially because of the premium on delivering code vs. maintainability, etc. Running a startup is a lot more like building a prototype (and may literally be that) than maintaining a legacy beast. If you are working in a Fortune 500 company, you could be in almost any kind of team working on almost anything. But the odds are much higher that you are stuck with a legacy codebase and a bunch of technical debt that you are trying to bail out of. You probably spend way more time going to meetings and coordinating with other teams than the startup folks. You probably spend more time shooing away the project and program managers than reviewing code. You probably have to spend a lot more time thinking about the wider impacts of your technology decisions because your service/app might have 100x the usage of a smaller company, which forces you to investigate more tools/services/frameworks than you would in a smaller company. All of these factors reduce the time spent coding.

Conclusion

If you're a junior engineer in a startup/non-technical company, I would be shocked to hear you only writing code 15% of the time. If you're a senior engineer in a large company with a significant tech investment, then 15% coding time sounds about right.

Improve this answer
2
  • 2
    this is a good breakdown. I would love to see a survey that actually quantifies this based on some of these factors. The current top voted answer says it's "not a meaningful question" but certainly a survey can get at least some of the factors
    – Colin D
    Commented Mar 22, 2022 at 15:41
  • 2
    Also depends on the design quality and quality of documentation of the platform and frameworks you're using. Better design and documentation, less time reading blog posts and scratching your head.
    – Tech Inquisitor
    Commented Mar 22, 2022 at 16:38
60

It's not a meaningful question to ask

Over the past two weeks, I had to manually trace through a web-service that we didn't have any debugging setup for. It took me several days to get the compiler to stop screaming errors at me so that I could read the code properly. I spent several days unpicking how exactly it worked and blindly locating the part of the code where the problem was. Then another day was spent reading the code and trying to figure out exactly why it wasn't working as advertised. Then, after nearly a week of not-coding, I had a full understanding and I was able to start writing code.

I wrote a small function-ette which added the necessary functionality.
Perhaps half a dozen lines of not-very-complex code.

I deployed that up to our UAT system and... it didn't work. I then spent another day debugging why it wasn't working and it turned out that we run a windows-service and a more generalised Web-service in parallel.

I had only updated the general one and not the windows service so I published that up too, digging past a bunch of annoying quirks of windows-services (you have to be the only person logged in on the server, and the Services window must be closed when you're changing the files out)

Lo and behold, it worked, once. Before it broke..
Turns out the API is set up for a Test state that locks the system so you can debug our database before manually moving it on to the next step..

So in the past week and a half, I've spent about 10 minutes writing actual code and most of my time figuring out where and how to write the code, and how to deploy the result.

We have a pretty awful system here, but I suspect it's not actually that uncommon.

Improve this answer
7
  • 30
    I think it is a meaningful question to ask. And your answer points out all the other work necessary to build a stable software system
    – cdkMoose
    Commented Mar 21, 2022 at 19:37
  • 15
    It's my experience that the more senior you get, the more your workdays are like this. The senior experience doesn't go towards writing better code. It goes towards all the research, support, troubleshooting, and communication that surrounds the code.
    – Wayne Conrad
    Commented Mar 22, 2022 at 2:34
  • For clarity, the project I'm working on was last touched four years ago by someone who built it almost entirely independently and has since left the company. I'm very very lucky he was a highly skilled developer who knew how to write legible and friendly code in an orderly manner or this would probably have taken longer.
    – Ruadhan2300
    Commented Mar 22, 2022 at 14:26
  • 7
    ...and then you documented all that stuff you went through... right???
    – Tiercelet
    Commented Mar 22, 2022 at 15:12
  • 1
    I think the question is meaningful - what isn't meaningful is putting an exact number on it. "Time spent coding" can vary between almost 100% to, as pointed out, about an minute per day. If (for example) a company has "We expect 7 hours time coding per 8 hour day" as a job requirement, it's a red flag.
    – ArmanX
    Commented Mar 22, 2022 at 19:13
38

If you spend 8 hours a day coding you are coding too much (or you are a typing monkey).

Developers must spend time thinking, specifying, documenting, debugging... these all take time and you can not spend all your time coding.

The exceptions are certain companies where some senior developers are charged with all the research and documenting tasks and the more junior developers just have to type the code given by the seniors. This is what I call a typing monkey.

Improve this answer
1
  • 3
    "type the code given by the seniors"? In what form this code is given? Hand-written? Or do the dictate it?
    – Andrew Savinykh
    Commented Mar 23, 2022 at 0:12
23

It depends on what you mean by coding.

researching the problem, investigating the data, discussing a problem with colleagues to figure out the best way to build something, reviewing other people's code, designing the architecture, configuring cloud resources etc etc etc.

I would consider this as coding, so I would consider you to be coding in the wider sense for the whole day.

In contrast, other people are having meetings, doing requirement analysis, writing bills, calling costumers for new contracts, interviewing new hires, or answering first level support tickets. Such tasks are not coding.

Improve this answer
2
  • This seems to be the most promising route to a real understanding of the matter. For the elder among us, the title "Programming as Theory Building" may still resonate. In that vein every activity that increases the (ideally shared) understanding is "programming". On the other hand writing code is only "programming" if it helps to achieve, capture and share understanding. Mind you that even discarded code experiments can be "programming" if the lesson learnt is captured, e.g. in a ticket. Finally, hitting keys on a keyboard isn't very cool, IDEs are better in creating lots of code quickly.
    – Stephan Herrmann
    Commented Mar 31, 2022 at 11:19
  • It is not a matter of generations. In the past I wrote ticket to provision servers in a data center. Now we are writing IaC for provisioning, testing, configuration. But your point remains valid.
    – usr1234567
    Commented Mar 31, 2022 at 11:23
5

I'm wondering how common is this in other software development jobs? Am I an outlier here?

Spending a fraction of your time writing code is nearly universal. Software Engineering is a problem solving job, and implementation is a fraction of that. Pretty much nobody codes 8 hours a day consistently.

That said, 15% is pretty low for most positions. Spending multiple days in a row not writing code at all is a bit of a warning sign that something has gone wrong.

The other answers (at time of writing) talk about chasing things down and debugging and investigating problems. To me, that indicates a distinct lack of testing foundation (either technique or scaffolding). I've had maybe 3 bugs in my entire 25 year career that were that tough. And even then, I was writing test code to exercise and experiment with the issue.

Yes, collaboration and design take time, but prototyping is still a thing. Small, iterative steps are still very good. Code reviews should be comfortably under an hour (you do have small, frequent commits, yes?). Going multiple days without coding hints at some underlying problem.

Improve this answer
4
  • 6
    If you work on legacy systems it is sadly usual to have no tests, no documentation and, partly because of that, a lots of bugs. And the refactoring of that legacy system can take you day without coding and just thinking "What the heck was the previous coder thinking ?"
    – f222
    Commented Mar 22, 2022 at 7:56
  • 2
    It's not just about untested or legacy code, the amount of time spent debugging depends a lot on what sort of code you work on. I work in HPC and most of my debugging effort is spent on bugs like "app repeatedly crashes two weeks into a simulation on one particular machine of one particular customer", OS/platform bugs and compiler bugs (tracking down a bug in the Linux kernel or GCC takes a couple of days at most because you can just read the code, but bugs in Windows or Intel compilers easily take a week to figure out).
    – TooTea
    Commented Mar 22, 2022 at 8:46
  • Yeah, legacy systems rarely have (good) tests. Which means I have a lot of coding to do…
    – Telastyn
    Commented Mar 22, 2022 at 15:14
  • @TooTea - One place I worked had a system with a bug that took 2 months to track down. An off-by-one indexing error was causing a bad index to get sent over the network to antother machine, that was then using it to index an array (past the end of the array) and send that retrieved value over the network to a third machine that used the garbage as a pointer. When it later de-referenced that "pointer" the computer would slowly go insane.
    – T.E.D.
    Commented Mar 22, 2022 at 23:05
2

I have been in both situations, writing code non-stop and spending no time coding.

In a previous job (small marketing/web agency <30 people) where we have streamlined website production (essentially they were selling websites by the dozen and then the agency supported them through marketing plans), I and almost all of my colleagues in my small department would write code (backend and frontend) for the most part of our workday.

After I moved to bigger and multinational companies, where the projects had teams of 60+ people working on them and some of projects were not directed to external customers, I found out that, unless you were developing something from scratch, most of my time would be dedicated in investigating a task and resolving dependencies than in actual code writing.

So, it depends. on so much factors that there is no solid answer that could cover my personal experiences

Improve this answer

Not the answer you're looking for? Browse other questions tagged .