As a manager, I won't care that dev A produces 2k vs dev B produced 4k. But if I see dev C would produced only 30 loc over say a quarter, something is most likely off.
Please take my argument in good faith: I am not looking at evaluating people based on their added LOC. The context is at orgs where I have reason to believe some people are slacking off, and looking for people who do next to nothing.
That's much more common than people who magically make everyone more effective by only deleting code.
Depends on the size and age of the company. In a startup, approximately never since the job is to build something out of nothing.
In a large enterprise with decades of codebase history to be optimized, very frequently.
I did say I wrote 30 lines of code, which was reusing other code instead of copy-pasting and changing a few things
It's not because the ratio is bad - if you wrote 300 and removed 19500 that might be fine. It's just that 30 is, in an absolute sense, too low.
The number of lines removed I don't remember and it changes nothing about the effort to read and understand the whole codebase
That's more lines of code than https://www.gnu.org/software/bash/
For sure there may be a thousand good reasons for it, but as a quick heuristic for 'who is worth having a quick check to see if we're getting the value out of them that we're paying them for?', I don't think it's irrational.
My team, and at least 4 other surrounding teams, had one full-time SWE cleaning up after him. He would go around making changes assuming things that he thought were safe and breaking tests, then his manager would argue with you that because you didn't make a promise that what he did wasn't safe, you have to fix the test breakage.
I used to work in a very dysfunctional org where the main "architect" was writing lots of broken code that kinda works, and the 20+ people in the team around it would basically be full time in fire fighting mode. The architect was a very smart guy but ironically enough without any sense of architecture: his level of abstraction for network was pushing bytes through a pipe, and for loops for calculations.
That's mostly an organisation failure.
In my experience, I have found it is more productive to coach and mentor developers to adapt TDD and DevOps practices than to vet their code. Instead of vetting their code, I would incorporate statistical code analysis and vulnerability analysis into the build system.
If you're also the one responsible for writing tests, you can easily churn out even more unmaintainable crap.
In my experience it's not enough to just have them do TDD, because writing a good test suite is hard.
How do you teach these things concretely without discussing specific code? How do you tell if the lessons are sticking without checking their future work?
Aside from that, neither TDD nor DevOps practices will get you idiomatic (relative to internally and externally) code, documentation, non-requirement performance worth a damn, test suites that are any good to begin with, etc. etc.. If you're running through a backlog of CRUD-ish features or whatever maybe those don't matter, though then I also wonder why the need for TDD instead of just a good CI pipeline.
*I'm probably remembering everything wrong but it was something like:
Cowboy: move fast and break things style. Sorta what you mentioned above.
Duct tape: most people are a form of this. Work on something just long enough to get it working but it's not beautiful and not prepared for the future or edge cases.
Professor: these get very little done because of the amount of planning put in and tend to over think most things. But almost never have to come back to a job since it's done properly and to completion.
Any team without a blend or with too many cowboys or professors is going to have a tough time.
The only exception is, if management come to understand what went wrong there and how it should be done. The chances of that are very slim, however.
I fully understand that there are circumstances where true tactical changes do make sense, but the tradeoffs should be considered up front.
Reviews also slow things down. You can't move quite as fast and break as many things if everything goes through a review pipeline.
Test-oriented development helps. Sometimes people find it easier to develop a tactical solution that somehow gets certain tests working and then refactor for strategy. They don't have to feel they have wasted time on the tactical solution because they get to reuse parts of it, and use it as a jig to guide the improved solution.
Sometimes people aren't being tactical; they really don't understand the system fully to know that some obvious solution will hit a snag.
I ran across some developers (in multiple orgs over the years) that would produce large amount of almost purposefully unmaintainable code. Yes, they were “productive”, and no, the stuff they produced made no difference and was a waste (both features wise and code wise since). 100% of these codebases turned out to be unsalvageable and were rewritten. It just would usually take orgs many months, usually after such developers leave to realize the complete and utter waste they left.
Not saying there are no slackers, it’s just productive devs are not necessarily those that produce the most of code.