Global Code Time Report

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.

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.<p>First off, who says their users are professional developers? Working full time? Always using the same tooling? Spend time on pair programming? Etc<p>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 &amp; algo&#x27;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.

&gt; 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.<p>Sounds like “I need to hear more tappy-tappy; that way I know the developers are working.”<p>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&#x27;re designing as you&#x27;re writing code, you&#x27;re probably doing it wrong.

That&#x27;s a pointless metric because it excludes the time taken to research requirements, possible solutions, and plan a suitable architecture.<p>It&#x27;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.<p>Similarly, more planning and less typing is probably a good thing.

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.<p>I don&#x27;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.<p>I keep a log book and track my hours each day. If it&#x27;s Saturday morning and I&#x27;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.<p>I&#x27;ve been doing this for three years and I&#x27;m incredibly proud of what I&#x27;ve been able to accomplish by keeping myself honest and holding myself accountable. It&#x27;s easy too. Keeps you from working too much or too little.<p><i>edit</i> Coding doesn’t mean “TYPING”. I include anything related to coding that pushes the project or my understanding of it forward.<p>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.<p>I also like what I do, most days.<p>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.<p>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.<p>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&#x2F;no answer to the question “Did I work enough today?”<p>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.

Coding isn&#x27;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&#x27;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&#x27;t a valid measurement of what I did that day.

Not surprising.<p>I had a dev job where 90% of the work was maintainence.<p>I searched like 1-2 days for a bug and then wrote two lines to fix it.

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.<p>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.

That&#x27;s way too much. No wonder there&#x27;s so much bad code out there.

It&#x27;s worth noting the author&#x27;s agenda:<p>&gt; 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.<p>So what they are saying (presumably to company managements&#x2F;executives) is that you can make your developers code more per day by adopting better tooling (&quot;perhaps buy our products?&quot;). To me, this sounds like a classic &quot;manufacture anxiety then selling solutions&quot; scheme.<p>It is also worth noting that the &quot;developers spent most of the time thinking&quot; argument against the claimed statistic won&#x27;t stand when companies need to lay off the &quot;low performers&quot; 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.<p>He was a disaster to the team. It felt like having someone constantly talking or screaming in the office.<p>He was also a terrible communicator. He talked like everyone had read his code and understood his thinking process.<p>I&#x27;ve never been happier to see someone fired.<p>But oh boy he was &quot;productive&quot;.

Developer&#x27;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&#x27;s pretty difficult to make conclusions about a developer&#x27;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 <i>at all</i> for a week or more. Or, if I&#x27;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.<p>That said, as a lead engineer&#x2F;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?<p>The closest examples I have personally is contracting and co-running my own business, where I&#x27;d just turn off all my points off contact and work. (I set my hours.)<p>It was way more than an hour a day of coding, let alone coding+thinking.<p>I thought it was great.

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?<p>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.

I tend to take a very &quot;iterative&quot; process, in my coding and design.<p>It&#x27;s kind of a &quot;chicken and egg&quot; thing.<p>I often start with what I call a &quot;napkin sketch,&quot; implement it quickly, kick the tires, and then see what needs to change.<p>The results are good, but the process can look messy. It involves a lot of both &quot;thinking,&quot; and &quot;doing.&quot;

As already called out as vague in term, I will share my $0.02 worth of observation in regards to &quot;coding&quot;, 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.

FYI, they discussed this report with its author on the DevOps Paradox podcast:<p><a href="https:&#x2F;&#x2F;www.devopsparadox.com&#x2F;episodes&#x2F;you-probably-code-less-than-an-hour-a-day-2022-08-12&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.devopsparadox.com&#x2F;episodes&#x2F;you-probably-code-les...</a>

<i>Our takeaway: Our findings suggest that developers frequently face constraints at work that prevent them from finding uninterrupted time to code.</i><p>No shit, Sherlock - though this is a very shallow reading of what a developer does or wants to do, or the variety of personality types out there.

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.

Because coding is the result of the previous development process.<p>Is debugging included in that 52 minutes?

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.<p>Makes me feel a lot better about my progress.

If they had figure for home working vs in-office, that could really be something worth reading.<p>As it stands, I&#x27;m inclined to agree with others who have said there are just too many hidden variables here.

On this basis, without interruption every author could finish a book a week (... I know some famously did!).

Taking a step back, a number like this suggests that even a tool like Copilot is optimizing the wrong thing.

My Wakatime stats beg to differ. My daily average is 4 hours and 57 minutes.

Luxury

~$13 per minute sounds about right.