Comment by khazhoux
1 month ago
> Some things that don’t measure whether a developer is “good”:
> # LoC added, changed, removed
Everyone loves to say this, and yet at every company I've worked at, the top developers just cranked out code. High quality, performant code.
And at every company I've worked at, the lowest performers would take a week to write 100 lines of basic python.
"Oh, but khazhoux, those 100 lines were really very complex!" No, not actually.
"But won't people just pad their code with comments to increase their LOC?" 1) I've never seen anyone bother, 2) I'm not saying "managers should count LOC"... I'm saying managers should look to see how much code each developer is actually committing to the codebase. If someone isn't committing much code, but talks like they're writing a lot of code, then you may have a problem.
Honestly, somewhere along the way people seem to forget that software is made from code.
I would never suggest a manager stack-rank their team by LOC, but the notion that the code people write means nothing, is preposterous.
You can make massive LoC changes by reformatting everything or just adding superfluous code or changes.
You can rip out a lot of code rewriting it to simplify and then losing a ton of business functionality that was used, or causing the need for a lot of business changes in process that might not be for the business’s benefit.
You can, on your own or with AI, write many LoC, and maybe it provides business value, which seems to align with being a “good developer”, but someone has to maintain those LoC, so then you have to weigh the business value to the end user and the team. Is it ok to the team to have all the extra LoC to maintain? How often will those changes eventually result in valid further changes to get that code to work? Will other devs just rewrite it and are their changes good?
So in the end, no, LoC added/changed/removed is not a good indicator of added overall business value when weighing both the business value to the user and the ongoing maintenance time that ensues, even though “good developers” along with “average developers” and even “bad developers” may have high LoC added/changed/removed counts.
During what some come to think as their peak years, they still don’t think of things this way. But as we get older and more experienced, we realize that sometimes new or old crappy code is ok, sometimes we should do a better job if it makes sense for the business and team, that many can contribute in their own way if those are the people and resources we have, things may change, and overall there is a limited amount that humans can do.
If you base performance on LoC and alter the team accordingly, you may lose great developers. You may also introduce volatility and risk later having a codebase that is higher cost to the business.
But embracing change and working fast and loose may also be important, so it depends.
You're arguing a different point. I never said a manager should simply count the number of LOC changes as a productivity metric.
I said that good developers write a lot of code. And I'm not talking about senior developers who now do mostly advising/review/architecture work (and don't code much anymore). And sure, sometimes someone takes a long time for a critical few-line change, but that does not happen every day.
I find it exhausting, frankly, how much pushback this simple concept gets around here. It seems to be a reflection of the gigantic team sizes that are common these days, and the modern tolerance for low-output (but still highly paid!) developers. Maybe the popularization of 2-week sprints 15-20 years ago corrupted everyone into thinking that everything should take that long, minimum.
People are shockingly ok with taking 3 days to add an argparse block to a python script, or half-week to implement a single HTTP call. It's nuts!