Comment by bsindcatr

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.