4 ms·
One project I was on someone added a tool and posted the results of the past week of number of lines of code added, my count was -5900 and I had been put at the
by PaulKeeble 2y ago
One project I was on someone added a tool and posted the results of the past week of number of lines of code added, my count was -5900 and I had been put at the bottom. This was a legacy project.
Its pretty easy to explain why removing a bunch of complexity and replacing it with something smaller and meeting the customers requirements better is obviously the goal on any project. Everyone that added lines had made things more complex. Its obviously a useless measure for productivity or saying anything of note about the work at all other than the lines of code making up the project and how it is changing over time.
- stavros 2y agoThat's not useless at all, the moment I saw -5900 I knew that was the most valuable contribution to the codebase.
- ajuc 2y agoEven if you insist on having these metrics and using them - it's another level of stupid to measure lines of code added instead of edit distance.
- r1chardnl 2y ago“One of my most productive days was throwing away 1000 lines of code” ― Ken Thompson
- canucker2016 2y ago-2000 lines of code, Bill Atkinson, Apple Lisa Quickdraw developer https://www.folklore.org/Negative_2000_Lines_Of_Code.html https://www.folklore.org/Negative_2000_Lines_Of_Code.html
- m463 2y agohttps://www.folklore.org/Negative_2000_Lines_Of_Code.html https://www.folklore.org/Negative_2000_Lines_Of_Code.html
- mirekrusin 2y agoRemoved LoC should count double. Edit: But then again, the point is not about individual examples really – the point is that whichever metric you choose, with time you'll see diminishing returns followed by negative ones. In case of doubling removals, you can easily game it by dumping json files for tests, then removing them ie. in favor of generator etc. What's interesting is universality of this phenomenon (strong goodhart's law?) – overfitting in llms, using metrics discussed here and why it makes sense to vote on opposite ruling party etc.
- maeln 2y agoThat is how you end up with a unreadable code where everything is a oneliner and there is no comment and no documentation :D
- mirekrusin 2y agoAbsolutely agree, added edit, should have posted long answer instead of update with clarification, my bad.
- nosianu 2y agoRelated, research: "Humans solve problems by adding complexity, even when it’s against our best interests" Article: https://www.washingtonpost.com/business/2021/04/16/bias-problem-solving-nature/ https://www.washingtonpost.com/business/2021/04/16/bias-prob... Study published in Nature: "Adding is favoured over subtracting in problem solving" -- https://www.nature.com/articles/d41586-021-00592-0 https://www.nature.com/articles/d41586-021-00592-0 > A series of problem-solving experiments reveal that people are more likely to consider solutions that add features than solutions that remove them, even when removing features is more efficient. > ...the authors observe that people consistently consider changes that add components over those that subtract them" -- be it bricks or regulations, so it works like this for real as well as for abstract things.
- vdvsvwvwvwvwv 2y agoI reckon that depends. Coporate culture encourages adding. Half your job is justifying keeping your job. It takes a lot of swagger/social capital/clout to subtract and be loved for it. Or you need to work somewhere (a company or protected team) with a first principles thinking culture (and not a cargo cult one) which is very rare. In personal life I think people do often subtract. They give up X where X is harmful. They simplify. Not everyone but many. It feels like a natural part of life.
- nzach 2y ago> even when removing features is more efficient Efficient in what sense ? > Our conclusion is that people systematically overlook subtraction; it’s not that subtraction is always better My personal experience agrees with these findings, but I think they missed something more important. People try to change things because they want to see something new in the real world. But from ideas to real world impact there is always at least one level of 'approving' you will have to go through. And adding things will generally have less risk associated. Besides that, I think our education system doesn't train us to remove things. Everything we learn is incrementally built upon what was already there. So our default mode of thought is to add things. Now imagine we have 2 developers, one how always solves problems by adding something new and another one that always refactor things to keep things efficient. My guess is that by only adding things you will end up delivering more features with less bugs. Sure your code will be slower and at some point it will become impossibly complex to manage, but it takes quite a long to time to get to this point. After writing this message I've realized that 'making things easy to delete' is a pretty important feature.
- hinkley 2y agoI gave myself carpal tunnel replacing over a hundred copies of the same five lines of code with an n² complexity with a single implementation, so then I could fix the perf issue later. -500 lines over a holiday week, which was nice, but not as nice as landing the changes to the shared function and making 2/3 of the app 10x faster with the test data, which was ultimately going to be a fraction of the real data. Don’t large scale refactor in vim folks, especially if you haven’t memorized all of the shortcuts (I hadn’t discovered block indent until weeks later. Ouchie)
- John_Cena 2y agoIf vim's macros and the per line ":norm @q" style didn't exist i'd want to stand on the edge of a bridge with one foot on a banana peel.
- positr0n 2y agoI've worked at a company for 6 years and still been net negative a thousand lines of code for the project I was on the entire time!