[esotericn]

From the sounds of it that also includes a decent amount of greenfield work.

I don't have hard figures to easily consult but I'd guess that I'm at about your average in total, but then on the days when I'm refactoring/debugging existing stuff, honestly it could be like 3 lines a day, or 5, or just planning/sketching something out.

It's like the old mechanic trope. It's not hard to replace a bolt, what's hard is knowing which bolt to replace and where.

[mumblemumble]

This "LOC as a proxy for productivity" metric seems so much harder to measure in a useful way on brownfield work.

On my most productive (in my own estimation) brownfield days in recent memory, the codebase would generally shrink by several hundred LOC.

I also find that a huge factor in my code production rate on brownfield projects might not have much to do with me, because it's factors like, "Is the code well-documented, easy to understand, and backed by tests that make the intended behavior clear? Or do I have to start by burning days or weeks on wrangling with Chesterton's Fence?"

And, on the other side of it, when is documenting and cleaning my own code to guard some future maintainer from that situation vital, and when am I burning a day of my own time to save someone else only an hour in expectation? All I know for sure in that situation is that, if my manager is assiduously counting LOC, ticket close rate, anything like that, then game theory demands that I should never bother to spend an extra hour on making it more maintainable if I expect that the cost of that decision will be born by one of my teammates. The 10X rockstar developer at a previous team of mine taught me that lesson in a rather brutal manner.

[hinkley]

> I should never bother to spend an extra hour on making it more maintainable if I expect that the cost of that decision will be born by one of my teammates.

If you want to be a team lead, though, or even just have people follow your lead, I find that not only do you want to worry about these costs, but you need to talk openly about them, and be seen addressing it. Most devs follow the ones they trust, no matter what title they have.

On all the projects where we tried to build people up instead of get shit done, we were consistently getting more shit done at the two year mark, if not sooner. Any idiot can ship a version 1.0.0, but it takes some talent (and luck) to ship version 2.3.0

From what I’ve seen, Postgres followed a similar model, and if you look at the performance benchmarks over time, it has progressively narrowed the gap with each major release. That kind of momentum is something worth sacrificing for.

[mumblemumble]

> If you want to be a team lead, though... you want to worry about these costs...

This may depend on the extent to which your organization conforms to the Peter principle.

[biztos]

I am about to rewrite something (different cloud, blabla) and if I do a good job I think the program’s LOC will go down by about 25%, the unit testing LOC will go up by maybe 50%, and maybe 50% of each will be the same old logic while the other half will be new logic.

I have no idea how I would try to count that if I wanted to measure “productivity.”

[thomk]

Interesting so maybe the more accurate way to measure is increase LOC + decrease LOC.

[virgilp]

Or even better, don't measure LOC.

[milesvp]

LOC is a terrible measure for productivity, but I like to think about it more as a measure of capacity. LOC/day is useful as an upper bound in the same way pages per day is an upper bound for authors. Stephen King is notorious for being one of the most prolific writers, and he can’t produce more than 8 publishable pages a day (top hit on google suggests his average may be close to 6). Knowing that the number of LOC/day is so low on average, can really help keep estimates honest, and remind us how truly difficult what we do actually is.

[aidenn0]

Isaac Asimov, another prolific author, averaged something like 2800 words per day[1] over the most productive period of his career, which works out to about 9 pages, so that seems like a good estimate.

1: Google is giving a much higher number but they all seem to go back to the same estimate which is more hand-wavy than a printed source I found in college when researching it. Sorry I don't have it to source. The other number from that source was 1800 published words per day if you start from his first published book, which is absurd, since new authors tend to be much less prolific.

[milesvp]

Interesting, I'd never thought to look much at other authors output on this topic. There was a post the other day talking about Jules Verne's corpus, and I now wonder what his output was like.

I've another thought on the topic as well, which is that I have a friend who hired a lot of former newspaper journalists circa 08 when there were mass layoffs in that industry. He said they were able to most consistently churn out content for his book over other writers, but that it was significantly lower quality, and needed a lot more rework and polish. For him the tradeoff was worth it, and he organized his time and resources around this increased quantity. But this adds to the idea that you really can't look at pages/day (or LOC/day) on an individual basis either, since it's the whole pipeline that matters. And if you really want to improve total output, you need to look at variables outside of individual contributors. Things like code reviews and QA can perhaps greatly increase total output.

[vannevar]

LOC is a poor way to measure progress, but it's not a bad sanity check on time estimates for a proposed project. Most experienced programmers have some points of reference where they know the approximate LOC count, and can make a rough functionality/complexity analogy to a proposal. If the proposal is less time than the team could possibly generate a comparable amount of tested code at 10-100 lines/day (wherever your team is in that range), then you should probably revisit the estimate.

Apply a few of these kinds of comparisons using different metrics, and you may be able to improve your estimates.

[goatinaboat]

Bill Gates said something like measuring progress on a program by LOC was like measuring progress on an aircraft by its weight

[mumblemumble]

"Measuring programming progress by lines of code is like measuring aircraft building progress by weight."

I'm no expert in aircraft, but I'm guessing that in both cases the relationship between progress and the metric in question is logarithmic: The first bits to be put place represent the bulk of the (weight|LOC), but only a relatively small percentage of overall time and effort.

[MR4D]

Same metric applies - lighter is better.

;)

[mumblemumble]

Hence why the absolute best aircraft are usually made of something like expanded polystyrene.

(At least, that's how it tended to go for the ones I was making as a kid.)

[thomk]

Alrighty.

[anoncake]

BRB reformatting the codebase.