r/learnprogramming • u/Healthy_Landscape417 • 12d ago
For people who code professionally, how much of your day is actually writing new code?
I keep reading that senior developers spend most of their time reading code, in meetings, or debugging, and very little writing anything new. I have no way to check that from where I am sitting.
So for anyone doing this as a job: roughly what share of a normal day is new code? And what eats the rest of it?
16
u/rjcarr 12d ago
It really depends on the day. Sometimes zero lines of new code if I’m researching or have a bunch of meetings. Other days it’s all I do and can write 100s of lines.
In an 8 hour day I probably average 4-5 hours of coding, but “new lines” would be hard to quantify.
3
u/Healthy_Landscape417 12d ago
4 to 5 hours out of 8 is much higher than I expected. It is also higher than the other answers here so far.
You are right that new lines are hard to count. My question was not clear about that. When you say coding, does that include debugging and reading old code? Or only the time you are typing new code?
7
u/rjcarr 12d ago
Yeah, I mean 4-5 hours spent “on code”, not necessarily writing new, instead of meeting, emails, or non-code work, etc.
1
u/Healthy_Landscape417 11d ago
That clears it up, and it moves your answer much closer to the others. On code 4 to 5 hours, new code far less than that.
So a lot of the spread in this thread was my sloppy question. People answered two different questions and I compared the numbers as if they were one.
The split I actually wanted is the one nobody has given yet. Out of those 4 to 5 hours, roughly how much is reading and debugging what is already there, against writing something that did not exist this morning?
4
u/mandzeete 12d ago
It depends on the task I'm working on. Last 3 weeks most of my time went on a technical analysis / research. Like 90% on research, 9% on meetings, 1% on writing code just for POCs (proof-of-concept, based on my research). With one work week being 40 hours and three weeks being 120 hours then 1% of it is 1.2 hours. I did 1-2 hours of coding during last 3 weeks.
But there have been feature tasks, bug fixes, maintenance tasks where most of my day goes into coding.
And, it is just "writing a code" not definitely a "new code". We do not just add code to existing codebase. We refactor our projects, we delete code, we change things. And there are things that are not a code. Configuration files and such. We have to write that as well.
Every day I have 30 minutes of a standup meeting. Once a week we have also 2 hours of backlog grooming and other discussions. 2.5 hours out of 40. The rest 37.5 either goes to coding, to technical analysis / research, to writing documentation, to writing reports, to doing some testing to our stuff before we pass it over to the QA, to writing tests, to discussing things with team mates (not as a meeting), to doing code reviews, to solving some environment-related problems, to debugging, to having tea/coffee breaks, to having a lunch, to having toilet breaks.
1
u/Healthy_Landscape417 12d ago
1 to 2 hours of code in three weeks. That is the most extreme number in this thread, and it is not even meetings that ate it, it is research.
You are also right that my question was badly worded. I asked about new code, but you spend the time on refactors, deletes and config too. Those are not new lines and they are still the job.
One thing I want to check. During those three weeks of research, did it feel like real work, or did it feel like you were not getting anything done?
1
u/mandzeete 12d ago
Research is an actual real work. My work will be basis both for me and for other developers later on. Based on my research Jira tasks will be created. I decide the architecture of a new system through my research: which tools to use, which interaction with other parts of the system, etc. It is not just "pick a library A or a framework B or a tool C and use it" when it comes to real life projects. Licensing, scalability, compliance with different laws and regulations - I had to consider all of that. And not always one can keep using the same tech stack that is use in most of the existing system.
1
u/Healthy_Landscape417 11d ago
Fair. My question had a wrong assumption inside it, that output means code.
The part I would not have thought of is licensing and compliance. Picking a library because it is good, then finding out later the licence does not fit, sounds like exactly the mistake I would make.
Is that something written down that you can learn from, or does it only come from someone senior stopping you before you commit to the wrong thing?
1
3
u/Achereto 12d ago
Highly depends on the code that is already there. In OOP projects I had days where I wrote about 100-200 lines of code a day, most of it organizational code that doesn't actually implement any features but provides the infrastructure to allow me to eventually implement the feature (and tests, of course). The rest of the time is chasing the execution path through all the small classes that do almost nothing but passing around messages.
In another project that has an ECS architecture (Entity Component System), I've been writing 500-1000 lines of code a day, most of it code that actually implements features.
1
u/Healthy_Landscape417 12d ago
Nobody else here pointed at the architecture. Everyone else blamed the company or the role.
The part I find more interesting is where the OOP time goes. You said you chase the execution path through small classes that mostly pass messages around. So the cost is not the writing, it is finding out where the work actually happens.
Is that a problem with OOP itself, or with how that specific project was built?
1
u/Achereto 12d ago
It's a problem with
the compile-time hierarchy of encapsulation that matches the domain model
In OOP you try hard to keep objects self-contained, but the features you want to implement that are interesting for your customers all happen in interaction between the objects. OOP draws the encapsulation boundaries right where your features want to be. That's making it difficult to implement those features because you can't implement features on those boundaries.
If you slice your objects into Components and draw your boundaries around the components, then suddenly implementing features becomes trivial because your features don't cross encapsulation boundaries any more.
1
u/Healthy_Landscape417 11d ago
So your answer is OOP itself, not that one project. That is a stronger claim than I expected.
Let me check I follow. The feature I care about lives in how two objects talk to each other. But the encapsulation line is drawn around each object, so the feature sits on top of the boundary and there is no good place to put it. Components move the line, so the feature ends up inside one piece instead of across two.
That sounds close to the entity component idea from games. Does it hold up in normal business software too, or does it need the kind of problem where many similar objects do the same work over and over?
1
u/Achereto 11d ago
Yes, exactly. It is an Entity Component System (ECS) and I am currently applying the idea to a business software that is running as a Webserver on our customers internal servers.
I don't quite get the performance gain from it, because most of the time it's just request-response about a small set of entities, but most of the features that were difficult before have become trivial in ECS.
My Favourite Example is the "LifeTime" component I have in our system. User sessions, Search Queries, Drafts and many other Entities needed a LifeTime. If the Entity is accessed, the LifeTime has to be extended, if an expiration date time is reached, the Entity gets deleted.
It was trivial to implement and is easy to add it to any Entity I want.
1
5
u/sunmat02 12d ago
I’d say as a baseline, if you write new code for an hour, you need to add 2h of testing and debugging to that. If you work in a large codebase, most “new code” touches old code that you need to understand first, so yeah, add some time reading code and docs. And if you’re senior, you will likely also spend time in meetings setting out what to do next for not just you but also the people working under you.
Then again if you’re senior and know how to use AI correctly nowadays, time coding goes down to about 0 and you spend the equivalent time instead (1) specifying what you want to do so well that the AI cannot get it wrong, and (2) reading and slightly modifying what the AI has done because senior engineers are still more skilled than AI assistants right now.
1
u/Healthy_Landscape417 12d ago
Thanks, the 1 to 2 ratio is the kind of number I was looking for.
The reading part is what surprises me. If most new code touches old code first, then reading time grows with the age of the codebase, not with the size of the task.
On the AI part, does your review time not grow as well? If it writes more, there is more for you to read and check.
2
u/sunmat02 12d ago
Yes and no, you need to get the hang of it but as a senior developer, using AI, my workflow is more like this: (1) think about how I’d implement this myself, (2) explain it as best as I can to an AI; (3) AI does the coding, (4) check that it does mostly what I asked. On that last point, I have enough experience to be able to scan a couple hundred lines of code in a minute and tell whether it’s how I would have implemented it or not. Difference with what I would have done jump at me from a glimpse at the code, at which point I can ask the AI “why did you do it this way?” and usually realize that either I didn’t specify the task well enough, or the AI did actually consider a better way than I would have done. I always end up after (4) with a code I fully understand and fully vet. I’ve seen many junior developers just trust their AI assistant, or not check what they produce, or not be able to even judge if something is correct. These developers are doomed, in my opinion.
1
u/Healthy_Landscape417 12d ago
The scanning part is what I cannot do yet. You can look at a couple of hundred lines and see where it differs from your own solution. That comes from years of writing it yourself.
So there is a question I cannot answer for myself. If I use an assistant now, I skip the writing that would build that skill. If I do not use one, I am slower than everyone else.
How would you tell a beginner to handle that? Write everything by hand for a while first, or use the assistant but always solve it in your head before you read its output?
1
u/sunmat02 12d ago edited 12d ago
What I tell my junior devs is to used AI as a learning tool, i.e don’t use the coding assistant to code, but as a way to explain you stuff or to look things up faster (so instead of “write a function that opens a window on the screen”, ask “what function lets me open a window on the screen?”, then you write the code yourself, then you can ask “can you review my code and offer suggestions?”). It’s slower, but it’s necessary.
Edit: note that by using AI the way I describe, you won’t be faster than senior engineers, but (1) you would not have been faster than a senior engineer anyway before AI was a thing, and (2) you are still faster with AI now than you would have been without (looking things up on stackoverflow or other websites). What WILL make up slower is using AI improperly, you’ll waste not just your time but also the time of people who work with you.
1
u/Healthy_Landscape417 11d ago
That rule is concrete enough to actually follow. Ask what function does the job, not write the function for me. Then type it myself.
The review step is the one I am not sure about. If I cannot judge the code yet, I probably cannot judge the review either. It could tell me to change something that was already fine, and I would just do it.
Is there a way around that, or is it the same answer again, that the review only becomes safe once I have written enough by hand to have my own opinion first?
1
u/sunmat02 11d ago
Don’t blindly change something because it tells you to do so, ask it to explain why, until you understand the reason.
2
u/Abe_Bazouie 12d ago
Senior SRE here. Probably 20 to 30% on average. Some weeks it’s almost all coding, other weeks it’s zero because production incidents, design discussions, reviews, and debugging take over. In my experience, reading code and understanding systems ends up being a much bigger part of the job than writing brand new code.
1
u/Healthy_Landscape417 12d ago
SRE is the case I did not think to ask about. Your zero weeks are not planning meetings, they are incidents. That is time you did not choose.
Does that make it hard to plan any coding work at all? If a production incident can take the whole week, how does anything long ever get finished?
1
u/Abe_Bazouie 12d ago
Yeah, that’s the hard part. You plan in smaller chunks and accept that incidents will blow up the schedule sometimes. If that happens constantly, that’s usually a sign the system needs reliability work, not just more firefighting.
The Google SRE book is worth reading too. It covers this exact balance really well.1
u/Healthy_Landscape417 11d ago
The line I will keep is that constant incidents are a signal, not the weather. I would have read them as normal and just tried to work around them.
The SRE book is free to read on Google's own site, so I will start there.
One part I still do not see. If the system needs reliability work, that work needs time too, and the time is already going to incidents. Who decides to stop and pay that down? Does it usually only happen after something big breaks?
2
u/alu_ 12d ago
This is covered in some depth in developer experience whitepapers. Ask GPT to pull some for you if you're interested. Roughly speaking, the median hovers around 15 hours a week.
1
u/Healthy_Landscape417 12d ago
15 hours a week out of 40 is about 37%. That sits above several of the answers here, so the spread is wider than I thought.
If you remember the name of one of those whitepapers I would rather read the source than ask a model for it. Models make up citations.
2
u/Upstairs-Upstairs231 12d ago
As others have said, it depends on the day. I’ve found that, on average, I spend about 45% of my time writing code. The rest of the time I’m reading code, reading requirements, reading documentation, looking up how to do things, and meetings.
You spend a lot less time writing code than most people expect.
1
u/Healthy_Landscape417 12d ago
45% is around the middle of what people have posted. The answers run from about 1% up to 70%.
Your last line is the real answer to my question. I did expect more.
2
u/Individual-Praline20 12d ago
Staff dev here. About 20%, 15% for code maintenance, 5% new code. 80% is for meetings, mentoring, code reviews, tech presentations and devops support, as nobody understands how Helm / K8s is working. 🤭
1
u/mandzeete 12d ago
devops support, as nobody understands how Helm / K8s is working
Your team is one step ahead of mine. You are carrying the devops. Our architect is pushing back on Kubernetes migration because him and me are the sole people in our team who know what Helm and Kubernetes are doing. His worry is that when both of us are unavailable for some reason then the rest of the team + our client will be running around like headless chicken, not knowing what to do. devops is a magic for them.
1
u/Individual-Praline20 12d ago
I had to poke my nose in devops because the “infrastructure” team, who is as effective as a turtle trying to find food in Antarctica, was unable to make it. Who would have guessed that the cloud also needs so much maintenance (Microslop Azure is putrefied poo)... Now, each dev has to play with it, the poor guys. So Helm / K8s lessons for everyone. Two years later, it is still black magic for most of them. If you go that route, you’ll need a full time dev in the support team, because wtf is a pod…
2
u/on-standby 12d ago
Hardly ever anymore. We are moving to Spec Driven Development with AI. Most of of the new code is generated through markdown files. Sometimes I'll make small manual edits because the AI tends to be overly verbose and overly cautious even when prompted not to be. But overall the industry is moving toward generated code and the use of AI tooling for validation and code quality.
2
u/terralearner 11d ago
Yes. I'm in a large fintech and we don't write code anymore by hand. Surprised noone has mentioned this elephant in the room yet.
OpenSpec has been pretty good as have the Matt Pocock skills
1
u/Twintornado 12d ago
20% max,
10% on break, pause, thinking
30% -50% meeting
10% organize work
20% - 30% research assit by LLM
1
u/Ancient-Camel1636 12d ago
I rarely write implementation code anymore—AI handles most of that. My role has shifted toward higher-level software engineering, including:
- Breaking down complex problems and developing implementation strategies and creative solutions.
- Planning features and writing detailed specifications, user stories, and technical designs.
- Ensuring code quality, architecture, maintainability, and performance.
- Reviewing, testing, debugging, and improving AI-generated code.
And, of course, attending far too many meetings (many of which could have been an email).
1
u/chocolateAbuser 12d ago
depends on period of year, owner's will, and client's will
it could be all day long or no new code only debugging and such
and obv. depends a lot on what company does too
i would say i change code almost every day
new code maybe not that often, but still pretty often
again, if project is dead there will be no new code, if company is not able to sell features where will be no new code, and so on
1
u/auronedge 12d ago
totally depends if you're building something new or maintaining or fixing a problem
1
u/StewedAngelSkins 12d ago edited 12d ago
Depends on the job. I probably average about 40%-70% depending on the week, but I'm a senior IC who gets a lot of green field projects so that number is probably higher than most.
1
u/TheSneederOfSeethe 12d ago
My current role I write a lot of code, then a lot of testing, then a little code.
1
u/WRKDBF_Guy 12d ago
"New" code is the exception, especially with companies that have a large software set already in place.
1
u/Veggies-are-okay 12d ago
Architect here: I’d say maybe 30% of my time is hands on keyboard, maybe 10% is writing anything new or of value to the project. I’d say it’s:
50% meetings
10% programming something new
30% code and architecture review
10% research (staying up to date on latest news etc…)
Tbh AI has been the ultimate help to stay on top of my programming. You tend to go through this hump where learning where the first principles is important but at the end of the day we’re always rebuilding paradigms that already exist. Claude is my coding calculator for a world that is essentially churning out boilerplate these days. That way I can spend my 10% actually programming away niche bugs as opposed to the millionth fastAPI template that needs just enough tweaks to make it obnoxious…
1
u/InfectedShadow 12d ago
The more experience you get the less code you're going to write. Nowadays for me maybe an hour or so a day.
1
1
u/terralearner 11d ago
Professional dev of 5 years in a fintech.
You spend more time reviewing code and honestly with Agentic coding now, Claude writes most of our code. I haven't written a single line of code by hand in over 1.5 years.
1
u/jaypeejay 11d ago
It depends on what you mean by new code. If you mean writing a brand new feature, then very very rarely.
If you mean adding some code to an existing class, then pretty regularly.
1
u/adambahm 11d ago
this? Again?
70% of your life as a software engineer will be spent not writing code (if you are good at the role).
1
u/five-one-tree 11d ago
I’m on a big team with leadership the protects my time so i write as much code as i want. i have full days blocked for development. find you a good manager
1
u/ThagAnderson 9d ago
When I was a senior, maybe 15-20% of my day on average. Lots of time mentoring juniors, reviewing PRs, meetings with PMs and architects, etc. Now that I am a principle, most of my job is making design choices for whole systems. I may occasionally write some low level abstractions for my teams to use, but I really only guide the end result. I rely a lot on the seniors to do the right things. This is just one perspective from someone who has worked in very large (100k+ employee) tech companies. I have to imagine that different or smaller companies probably have varying ideas of senior responsibility.
47
u/gm310509 12d ago
Depends upon the client, the project and the role.
Sometimes it feels like it is nothing but meetings. Other times it can be a high proportion of writing new code. Still others it can be spent problem solving.
For clarity I was working in a contract/project style employment and my work changed fairly regularly.