Hacker News Reader

Comment by yawnxyz | Hacker News Reader

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.

View on HN

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.

Careful, you will upset the poor fools who have to deploy our - I mean, their - own products (and therefore have to write the config files, too!)

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.

Having the similar logic, most CEO/CTOs have 0 coding time, would we say they're not productive? Nope

Having some metrics is good, but coding time is definitely a wrong one

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

Reply on news.ycombinator.com