3 ms·
For one of the most frustrating projects I ever worked on, my net contribution was in the vicinity of -1k to -2k LOC in a service that weighed in at around ~5k
by pdpi 4y ago
For one of the most frustrating projects I ever worked on, my net contribution was in the vicinity of -1k to -2k LOC in a service that weighed in at around ~5k LOC in the end.
The guy who started the project came from an enterprise Java background, and his code was the stereotypical design pattern pileup. I only jumped in because he was having trouble actually wrapping it up, and, with every commit, I deleted a bunch of code and replaced it with just a small fraction of what was there before, and he reviewed the changes and agreed they were an improvement.
Yet, even though he genuinely agreed his code was overly complicated, he never internalized the learnings, and kept repeating the same mistakes over and over again. He was fixated on the idea that his coded needed to be extensible (without a clear notion of how or why) and kept adding abstraction after abstraction for every new feature he added.
So, yes. It is uncontestably true that you often need to write 4k LOC before you understand how to write the same thing in 2k LOC. But it's also very much the case that there's a baseline of skill you need to write those 4k LOC instead of a 10k monstrosity.
- pencilguin 4y ago> He was fixated on the idea that his code needed to be extensible (without a clear notion of how or why) and kept adding abstraction after abstraction for every new feature he added. Sad to say, usually the only way this lesson can be learned is through being fired. And not always then, but at least it is no longer your problem after.
- zugi 4y agoOof, this sounds sadly familiar to me. One of the most damaging developers at my company had a huge line of code count. I feel bad because he loved coding, and worked long hours, and always added lots of unit tests... But the unit tests were massive copy-pastes of each other that tested the trivial stuff (setFoo(), getFoo(), check the result) and often didn't test the complex logic that was harder to test but more important. He watched C++ YouTube videos by experts and preached practices to us all - some of which were genuinely good ideas - but he lacked the judgment of when to apply what. He made massive changes without seeking team consensus, never accepted feedback, and totally lacked the desire for concise code that seems natural to most good developers. Sadly his manager was enamored with him and kept him around far longer than we should have. I still run across his code to this day, overcomplicating and getting in the way of needed refactoring. Cleaning up his code has given me a couple of -2000 LOC days...