Is this metric meaningful on its own? The article insinuates that developers aren't productive, but if I spend a few hours thinking, planning, designing the system etc. and "only" spend an hour putting all that work into code, I'd still think that's more productive than spending many hours a day writing code that will eventually be scrapped.
Sometimes I'm at my most productive when I remove code.
But more seriously, a lot of time is eaten up by meetings, coordinating what we're going to code, thinking or discussing how we're going to code it, testing the result, reproducing bugs found, etc.
But it seems this survey also doesn't consider reading code to be coding, which makes me wonder: if having the IDE open and focusing on the code in it is not enough, and they're only interested in the actual typing, how do they count the time around the typing? If I start writing `if (` and think a moment about the condition I'm going to put in there, does that thinking not count as coding? Because if that's the case, 52 minutes sounds high.
Coding is not just typing code. Thinking is the more important part of it.
Yeah, this totally feels like an overzealous manager definition of coding - i.e. you're only working when you're hammering the keyboard - whereas 90% of the actual software development cycle is done while typing nothing (or at least no code) on the keyboard.
agree; notion of "code time" is almost equivalent to that other shitty metric the industry (used to?) use to evaluate dev productivity -- lines of code. It's usually meaningless, and promotes "garbage-in, garbage-out", leading to a decline in code quality. There's also the reality that engineers of differing seniority spend varying amounts of time writing code, and that the time spent thinking/reading typically adds more value (ex., less code-review churn, etc.).
It's like telling a minister that he only works for 1 hour a week because that is the only time that he is speaking in church. No thought given to the amount of time that is taken to write the speech or other church duties.
* I made this comment to my uncle whom is a minister when I was a child *
In the eyes of a PM, it is a useful metric. Because they think more code = more work. And in a way they're right, every solution will involve some amount of code (unless it's some menial task like changing a config file). So perhaps in their ideal world, devs spend less time thinking and more time coding (suboptimal) solutions to ship stuff faster.
Where in the article it insinuates that developers aren't productive? Quote from the article:
> Our takeaway: Our findings suggest that developers frequently face constraints at work that prevent them from finding uninterrupted time to code.
While the title on HN is "Report: The median developer codes 52 minutes per day", actual title on report page is "Global Code Time Report".
I think the report addresses the thinking-planning-designing parts of your comment believing these things are "issues" and need to be offloaded to someone else so that the "coders" could code. Which is a narrow way to look at things, for sure.
Nobody is saying this is a metric that should be pushed up as far as possible. But it adds some data to the discussion of how we should organize ourselves as software developers.
The 'optimal' amount of coding per working day probably depends a lot on the circumstances, but I'd hope it to be substantially higher than 1 hour in most cases.
if I spend a few hours thinking, planning, designing the system etc. and "only" spend an hour putting all that work into code, I'd still think that's more productive
The biggest boost to my productivity was when the company gave me an iPad and an Apple Pencil to sketch out flows and logic and design iterations, then AirDrop them into the computer to turn them into code.
I found it meaninful because it made me feel better about my own ratio of "working time":"coding time". I'd always read comments of people who advised spending time understanding a problem, but I haven't seen it presented as a simple %.
AFAICT the article is based on data collected from their suite of IDE plugins that a.o. track coding time. Based on some statistics from those, they make very broad and presumptuous conclusions on how developers are distracted from coding and what can be done about it.
First off, who says their users are professional developers? Working full time? Always using the same tooling? Spend time on pair programming? Etc
Then, why make the assumption that developers must be distracted? Who even says more time spent coding == more productive developers? IME the refinement of work prior to implementatuon, e g. outlining the general structure and defining data structure & algo's takes most time and prevents a lot of (coding) rework. It also reduces how much you then actually need to spend time on the implementation.
Also not sure about the seniority of the users too. Junior developers always tend to take longer time to solve a problem than the senior. Does that mean they're better?
> Code time is defined as time spent actively writing or editing code in an editor or IDE, which we use as an indicator of the amount of focused, uninterrupted time that developers have available to code during the workday.
Sounds like “I need to hear more tappy-tappy; that way I know the developers are working.”
If your organization has devolved to the point where your best measure of focused time is less than one hour per day, you’re screwed. Instead, I think this is a case of “this was easy for us to measure; now, what can we conclude from this measurement?”
Time spent at the keyboard is definitely not the mark of an effective coder. Code is just the implementation of a design. For any nontrivial module, the design should take up the majority of your time. If you're designing as you're writing code, you're probably doing it wrong.
My platonic ideal of a developer is this older, hacker-type guy, whom I’ve witnessed spending days mulling a problem without writing any code. Then one morning, he simply transferred the implementation from mind to code, completely self-documenting, with all edge cases covered.
He said something like “from my point of view, this code is perfectly written”, and it actually didn’t sound arrogant, partly because it was true.
I still have to think with my fingertips (i.e. write code before I know the solution), but his is the kind of approach I strive for.
There is no problem with thinking with code by trying things out. We left the punched tape and printed result listing era, we can write and tests partial solutions to the problems we try to solve almost for free, and that's a good thing. Don't beat yourself up for doing that :).
Also, there are some limits to what one can entirely store and efficiently think about in their mind.
Of course, it doesn't mean that one should always start writing code straight away without actually thinking first, or without using pen and paper to lay down some facts and think about edge cases if necessary, for example.
That’s true. Sometimes you have no idea how some black-box API will behave until you try it. The “think-first” approach usually applies to algorithmic solutions to novel problems. They do both have their place.
I've been trying to work towards this. I'll sketch out a prototype and reason through it on paper sometimes before writing code. It's an interesting exercise.
Problem for me, probably because I'm inexperienced developer is that no matter how much I plan things will change.
So for me it is better building multiple small things and then wiring them together.
Only after this im capable of doing any realistic implementation planning
That's a pointless metric because it excludes the time taken to research requirements, possible solutions, and plan a suitable architecture.
It's akin to praising people for generating many lines of code. But truly good programmers are the ones that write efficient, concise, and, hence, readable code.
Similarly, more planning and less typing is probably a good thing.
They wake up, judiciously hit the "{" key on their keyboard, taking a leisurely 500 msec to do so.
Immediately the floorboards start to creak. A framed cat picture shakes itself loose from its position on the desk and drops to the floor as a clinking, rattling sound of metal-on-metal builds. A deluge of gold coins is extruded from the bare earth itself as gaia supplicates herself to the 21st century god of productivity, the 100x developer. Now the sky can be seen to darken, as a tornado of 100 dollar bills sweeps over the area, hovering up the gold coins.
As the money maelstrom recedes in the distance, headed due west towards silicon valley, the 100x developer inhales deeply.
This will make a fantastic piece of motivational broetry for my linkedin, they think.
Plot twist: they glued some libraries together in an afternoon and successfully replaced a system with several person-years of work in it. Actually 100x more effective dev.
Double plot twist: after the 100x dev had left for greener pastures, nobody understands the system anymore and of course the initial afternoon of coding had no time for documentation or design reviews. The system has to be re-built and this time it will be built in-house with due attention to knowledge sharing and design documentation.
Triple plot twist: Several years later someone realizes that the in-house system is overly complex and maintenance heavy, then replaces it with some glued-together open source libraries on a Friday afternoon. The cycle continues.
>it excludes the time taken to research requirements, possible solutions, and plan a suitable architecture.
I interpret that as being implicit. If 3 minutes of planning are needed for 1 minute of coding, it's still alarming that half of a developers hours are going to...less important work.
I spend almost half my time reviewing code or pairing with more junior members of my team while they are driving with the IDE open, and I expect other more senior members of my team to do the same.
I don't consider that less important work, but it does change the ratio for myself and other more senior members of my team to more like 1:6
Having just read the headline... but to me it's not a pointless metric because it exemplifies that there's more to software development that purely writing code.
I keep a physical timer on my desk that I start and stop during the day. Hands on keyboard coding? Reading documentation? Sketching? Pushing the project forward using technical or design skills? Timer on. Anything else, food, break, YouTube? Timer off.
I don't stop working until I have five hours of coding or coding related work done each day. Some work days are six hours long, others are twelve. They all have about five hours of coding.
I keep a log book and track my hours each day. If it's Saturday morning and I'm at 24 hours for the week, Saturday morning is a work day. Some of my work weeks are four days long, others are seven. They all have about 25 hours of coding.
I've been doing this for three years and I'm incredibly proud of what I've been able to accomplish by keeping myself honest and holding myself accountable. It's easy too. Keeps you from working too much or too little.
edit Coding doesn’t mean “TYPING”. I include anything related to coding that pushes the project or my understanding of it forward.
Most people work jobs where they only get paid for the time they produce. Mow lawns or do landscaping for a few summers, it’s not fun. I set my own schedule and only put in 5 hours a day. I’m done before most people would get lunch. I feel like I’m working a part-time job most weeks.
I also like what I do, most days.
The details don’t matter much, this is the important bit: “Keeps you from working too much or too little.” Plug in whatever numbers work for you or do your own thing.
If I’m spending so much time in meetings or writing emails that I can’t do the work I’m good at, I need to hire.
It’s flexible too. I spent the first four hours of most days last week watching Star Trek or doing chores before finally getting to work. And the end of every day I have a yes/no answer to the question “Did I work enough today?”
Now, if you haven’t run your own company you might never have felt “did I work enough today” gnaw at you while you’re trying to sleep to sound of your bank account draining.
Not so sound too negative, but to me, this actually seems terrible. Because somehow any work not behind the keyboard coding is not considered work by your standards.
I don't think this is being honest. This is choosing some arbitrary metric and sticking to it, and very much Goodhart's law in practice.
If your job takes you away from the thing you want to be doing, you should try to change your job, not work 6-day weeks or 12-hour days for your employer.
Not honest? Employer? And, a very literal take on classification.
Coding doesn’t mean “typing”. I include anything related to coding that pushes the project forward.
Have you ever bootstrapped a company? I’ve done it twice successfully and once unsuccessfully. You have to figure out how to make sure you work enough without working too little. It’s not an easy balance.
This isn’t arbitrary, far from it, it’s what works naturally for me. Measured and adjusted over two decades.
I think I would find myself really frustrated with this workflow. I have some days where I'm reading documentation more than anything else. I don't write that off as not time well spent.
Same for meetings, not a lot but planning meetings, implementation discussions etc. That is time that should be considered too.
5 hours pure coding per day is just... Not healthy in my opinion. But each to their own.
> If people are interested I can put together a post about the process.
I think that would be good as it might clear up a lot of questions.
Hahaha, I have to rescind my offer to explain it in more detail. I can’t think of anything less interesting than a whole thread of “What about activity X? Surely activity Y? He didn’t even consider activity Z, WHAT A MONSTER! His silence on Q is telling.”
I like what I do (even if I might not like what I’m doing on any given day) and this lets me do it in a way that doesn’t cause any damage.
I don’t have anything to sell you. I’ll write it up if I can find a way to make money off it, if not I’m happy to keep chugging along in obscurity.
With all due respect, I'm struggling to imagine what you could possibly be coding that needs 5 hours of "hands on" time every single day - from my experience most of my productive time is spent thinking about what to code & reading code, the actual "hands on" time is fairly minimal.
Are you sitting at your keyboard? Are you reading documentation and clicking around? Or sketching something out? Sounds hands on to me, keep the timer running. Are you listening to a podcast while cooking and thinking about code sporadically? Timer off.
That's alright then :) I don't know if I just missed it or it came in the edit, but as I read it it just seemed way beyond 'conscientious employee'. Which if you are way beyond employee can be fine.
>> I've been doing this for three years and I'm incredibly proud of what I've been able to accomplish by keeping myself honest and holding myself accountable.
Honest question. Why exactly do you do this? Just pride in your work? Or do you it makes you more effective, less stressed etc?
It’s less stressful. Wouldn’t you want to be done for the day six or seven hours after you wake up? Like I said in another comment, I could easily work from the moment I wake up to the moment I fall asleep, seven days/week, every single day. I don’t. I work about six hours a day, five days a week.
I don't want to be too confrontational, but it almost feels like you're doing something wrong. 5 hours of typing a day every day? That sounds unfathomably high.
Could you detail the kind of projects you're working on?
Also, are you a consultant or working for your own company?
I run my own company. I could easily work from the moment I wake up to the moment I sleep. This forces me to focus, get things done, and hire if I can’t.
Have you ever worked in an environment where your ability to produce reliable code, consistently, was the only thing keeping a company running for 6-12 months? That’s bootstrapping as the sole engineer. If you break, the company will die. You have to keep yourself from working too much without working too little either. There’s no one-size-fits-all model to copy.
edit
On working for a bigger company: Yes, that’s why I don’t work at big(ger) companies.. Unless I have a lot of leverage. I wouldn’t rewrite things or over-engineer them. I would quit.
This corroborated with your replies to sibling comments makes more sense.
The thing is, in a big(ger) company, even if you pull in 5 hrs of coding per day, you will be limited by the average speed of the people working around you. You would soon find yourself running ahead of scoped projects, over-engineering, feeling an urge to re-write the whole codebase etc.
That’s why I won't work at big(ger) companies.. Unless I have a lot of leverage. I wouldn’t rewrite things or over-engineer them if I was idle. I would quit.
How do you fully stop thinking about, e.g., an algorithmic problem when eating or taking a break? I cannot pause my brain like that so the actual limit between working and not working is never clear to me.
Coding isn't the only thing that works like that... clutch replacement (in a car) is just pulling the old one off the shaft and putting a new one on.... literally 1 minute of work, even less. Of course dissassembling half the car to get there (with some cars) is not included in this time measure.
I don't type for a living, I think for a living, and then type the results. If that is 52 minutes a day, so be it. That isn't a valid measurement of what I did that day.
It wouldn't surprise me if the total number of bugs to be fixed skyrocketed in the past 5-10 years, too. The design and testing phases of the SDLC are nonexistent at most web dev companies and the culture is focused around adding as many new features as fast as possible. With those priorities, bugs wouldn't even be noticed until after they've been deployed, and the later in the SDLC you catch the bug the more expensive and difficult it is to find the root cause of.
Maybe because it's harder to test the interactive features in a website. Sure, Selenium and Playwright exist, but they're not perfect solutions. There are a lot of moving parts to a typical website, and also maintaining these tests is a nightmare.
What is a developer? At some places developers are not expected to do much more than coding. At other places you will spend most of your time thinking about architecture, performance, error budgets, analyzing SLIs etc.
In my experience places with a devops culture will actively encourage developers to do stuff beyond coding. Places with a classic corporate culture enforce a more limited scope.
I don't think it's devops, per se; that just adds another "not coding" item to the list. Anyone in the role of a "Software Developer" will wind up doing things that aren't coding; because coding is only one component of software development. A lot of times, it's one of the smallest components.
> But our findings point to a more alarming hypothesis: that most companies ineffectively deploy their development teams, bogging down engineers with distractions, disruptions, and meetings as well as system inefficiencies, such as slow reviews, slow builds, and bad tools.
So what they are saying (presumably to company managements/executives) is that you can make your developers code more per day by adopting better tooling ("perhaps buy our products?"). To me, this sounds like a classic "manufacture anxiety then selling solutions" scheme.
It is also worth noting that the "developers spent most of the time thinking" argument against the claimed statistic won't stand when companies need to lay off the "low performers" based on how much time they spent coding --- after all, were you able to come up with the right solutions more quickly, you will be able to spend more time coding implementing them.
I worked with a guy that would churn out code constantly. He would rewrite it or delete it a week later. According to this metric he was very productive.
He was a disaster to the team. It felt like having someone constantly talking or screaming in the office.
He was also a terrible communicator. He talked like everyone had read his code and understood his thinking process.
Developer's job is to provide solutions. Sometimes writing code is the optimal way to provide it. Code written usually becomes a liability rather than an asset. While LOC is an important metric overall, we should measure productivity in terms of solutions and their TCO.
I think it's pretty difficult to make conclusions about a developer's time based on a metric from an IDE. My coding time varies day-to-day and week-to-week. If my team is in a planning cycle, I may not code at all for a week or more. Or, if I'm investigating an issue from the field, I may spend a lot of time in a debugger, but I may not touch code for several days.
That said, as a lead engineer/subject matter expert for my employer, at least half of my days are spent doing many non-coding things.
Is nobody going to comment on the fact that emerging economies seem to spend more time coding? To me that says the metric is to some extend time wasted, because there’s more to being an effective, innovative company than churning out lines. This is similar to how emerging economies generally spend more time doing everything, and not accomplishing more (or doing so at the expense of certain human values, which will almost always creep into any advanced economy).
Has anyone worked in a place where devs were deliberately given uninterrupted time, time where they were out of contact?
The closest examples I have personally is contracting and co-running my own business, where I'd just turn off all my points off contact and work. (I set my hours.)
It was way more than an hour a day of coding, let alone coding+thinking.
A discussion of potential sampling bias is missing - the data seems to be entirely based on the usage statistics from their IDE plugin. Are their users representative for the whole population of developers?
I could imagine eg that time-constrained devs might be more likely to install the tool than people who are happily coding away most of their working hours, but I might be wrong.
As already called out as vague in term, I will share my $0.02 worth of observation in regards to "coding", at least in the space of my most recent workplace: by far the largest amount of coding is being produced in SRE, followed by PE, followed by the actual software product creators.
Yep. Majority of creating code is thinking, thinking, thinking and making sure that everything will work and be maintainable into the future. Then there are also cases in which business considerations step in. Those are even more complicated.
>Based on our estimates, developers spend an additional 41 minutes per day on other types of work in their editors, such as reading code, reviewing pull requests, and browsing documentation.
Interesting. I’m learning and find yeah, most of my time is spent researching, learning, etc. but still could get in an hour - then of course, fixing bugs, mistakes, interactions with other code, better options.
