5 ms·

I'm not saying that measuring programmer's productivity by lines of code written is good. This story, however, is not a story of someone who deleted 2k lines o

by kjksf 4y ago

I'm not saying that measuring programmer's productivity by lines of code written is good. This story, however, is not a story of someone who deleted 2k lines of code. It's story of someone who wrote, let's ballpark, 4k lines of code and then rewrote them, which resulted in 2k lines of code left. Not sure how to account for that but let's say it's 5k lines of new code written in total which ended up as 2k loc. This story does not prove that you are a great programmer if you write little code. It actually shows that even the best of the best (like Bill Atkinson) write a lot of code and cannot arrive at the ideal code at the first try. Writing the first 4k loc was a necessary step to gain knowledge that enabled him to refactor the code down to 2k loc.

pjc50 4y ago
It doesn't specify whether _he_ wrote the 4kloc first .. Negative LOC is not uncommon in maintenance work; things become obsolete or better solutions are invented.
- pencilguin 4y ago
  He did. Or anyway the first version. Possibly other people dirtied it after.
  - Izkata 4y ago
    Doesn't really matter either way, article indicates the report the -2000 was put on was from a restricted time range.
- Olumde 4y ago
  Steve Balmer on IBMs obsession with KLOCS https://www.youtube.com/watch?v=kHI7RTKhlz0 https://www.youtube.com/watch?v=kHI7RTKhlz0
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 ago
  Oof, 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...

by kjksf 4y ago

pjc50 4y ago

It doesn't specify whether _he_ wrote the 4kloc first .. Negative LOC is not uncommon in maintenance work; things become obsolete or better solutions are invented.

pencilguin 4y ago
He did. Or anyway the first version. Possibly other people dirtied it after.
- Izkata 4y ago
  Doesn't really matter either way, article indicates the report the -2000 was put on was from a restricted time range.
Olumde 4y ago
Steve Balmer on IBMs obsession with KLOCS https://www.youtube.com/watch?v=kHI7RTKhlz0 https://www.youtube.com/watch?v=kHI7RTKhlz0

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 ago
Oof, 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...