Hacker News Reader

Comment by jeffbee | Hacker News Reader

Productivity as a software developer consists chiefly in not making mistakes. That can lead to the situation where your best developers may appear to do nothing for long stretches. Research and deliberation are desirable. Blind hacking is the least valuable yet most visible activity of inexperienced programmers. All common "objective" measures of productivity such as closed tickets, lines of code, or PRs are seriously flawed.

View on HN

The most common implementation I've seen of this are senior developers who write almost no code, but spend their time telling junior developers what to go back and reimplement, giving advice, etc. It's still the junior programmer's actually getting the product written, just with nudges in the right direction. Not a bad system really, reminds me of the relationship between officers and enlisted in the military.

I'm currently building models around high functioning software developers/projects and what I've noticed is, churn can swing quite a bit. Take the following for example:

https://imgur.com/Yb8WvJY

Over 150 days, this developer's churn really fluctuates and that's because they work on different things, that requires different amounts of code. And if you look at the following:

https://imgur.com/oNmsMSV

you can see they still commit regularly, but as the Reviewability section shows, their changes are mainly small ones, which sort of aligns with what Sid (sytse) mentioned, which is mainly focusing on small changes.

If you look at the bigger picture:

https://imgur.com/vmiOtgU

https://imgur.com/5vf3kWj

The churn for the project microsoft/vscode fluctuates quite a bit as well.

Based on what I've learned so far, you really need a good baseline (that can vary greatly from one developer to another) to be able to determine if somebody is more/less productive.

This isn't at all universally true, it depends on the costs of failure. If you're programming a Mars rover, then sure, avoiding mistakes is paramount. If you're writing a one-off data analysis script that only has to work once and only has to be mostly accurate, spending a week coming up with the ideal specification and writing a full comprehensive test suite is usually much less productive than hacking at it for a few hours until it works. Good software developers know when to make the appropriate safety tradeoffs given the goals and constraints of the task at hand.

That's a straw-man retort. I never said every task requires one to go up a mountain. I only said that sometimes a software developer has reason to stop and think.

Also I would suggest that ad-hoc analyses and other such hacks are unlikely to lead to PRs and other visible artifacts.

I should have been more clear; I was mainly disagreeing with your first sentence. The rest mostly makes sense to me. Ad-hoc analysis was only one example, you could easily replace it with working on a prototype, where part of your goal is to find mistakes by making them, as that is often the most efficient way to discover what the problems with your design are.

Eventually any simply metric like this will become warped because of the effects of both Goodhart's Law, and Campbell's Law.

Something that I've been wondering about is that maybe team's should decide what their metrics are for the upcoming 3 months and then come back and decide what the new metrics are. At the very least, it becomes a big game about the org then.

Impossible to have 'metric based reviews' at that point. But I think that's fine.

That seems to be how quarterly planning worked in the largest org I've seen inside, though the PM and EM did most of the deciding and execs+board approved/disapproved.

How do people learn about a lot of “laws”? I know practically none, and it seems so useful to be able to produce them when explaining an idea...

I wouldn't say I know very many laws. I happen to know a few relevant to my fields of interest. They are memorable to me because they state complex ideas in brief, understandable ways. Rather than trying to learn a bunch of laws for the sake of knowing laws, look to your field for the important ideas and you'll often discover that someone has written formulated a "law". Most folks know Murphy's law, a general one, perhaps Occam's razor, and there's also Sturgeon's law and Godwin's law. In computer science you have Conway's Law, Brooks' Law, and Moore's law.

You probably already know quite a few laws, just not that they have names. "Power tends to corrupt; absolute power corrupts absolutely", and "Any sufficiently advanced technology is indistinguishable from magic" come to mind.

I don't know the answer to your question, but it helps to know what Wikipedia really likes lists, so I was able to guess that it might have an article called "List of eponymous laws", and so it does:

https://en.wikipedia.org/wiki/List_of_eponymous_laws

I assume you mean expensive mistakes! Making cheap mistakes is a great way to learn!

Cheap quickly discoverable mistakes that actually get fixed are a fantastic way to learn - about the tech, about the market, about software in general, about yourself.

One cheap, but mostly invisible mistake that lingers isn't a problem... but they can pile up.

Not making mistakes isn't productivity, that's the bare minimum of acceptable behavior.

People aren't perfect. Mistakes abound. If the bare minimum for a position was "no mistakes" you'd never find a qualified candidate. I'll go further and add that your attitude makes things worse in practice because since mistake can, and do happen, your wholesale rejection incentivizes effort spent hiding mistakes and scapegoating. That's effort that could have gone into getting useful work done.

I’d go even further and say there are two types of programmers:

1. The ones that “don’t make mistakes”, but actually they are just unaware. 2. The ones that expect themselves to make mistakes and prepare for that.

You'd think so but I've met a lot of programmers who just sit there and type out inadvisable programs non-stop.

Reply on news.ycombinator.com