Gave myself RSI deleting On the plus side I replaced an O(n²) algorithm with a faster one in the very next commit. Needed to get rid of the ninety copies of the same bad idiom first.
[deleted]
-2000 Lines of Code (2007)
81–90 of 222 posts
Re: -2000 Lines of Code (2007)
#82The largest impact is sometimes asking simple questions (how are you going to handle X?) which leads to not building something. When this something hasn't ever had a chance to work, you saved the whole cost of trying to build it. This is not only impossible to measure as a numerical metric but also makes you enemies. Kudos to those who dare to do that anyway.
> The largest impact is sometimes asking simple questions (how are you going to handle X?) which leads to not building something. Which is why I teach new people to have that loop in your head and not start pounding the keyboard at high velocity. The people who find programming to be akin to fast typing show very interesting equivalence with LLMs; fully write/remove/write/remove etc of not very well written code.
Mhh for me it is always a combination of the two. I like making a good high level plan, but for certain problems it is better to make the plan as you go, because you can't fully understand the shape of the problem and the potential solutions as you start. Sure maybe that means your first code sucks and is a prototype that should be replaced, but if you are aware of that and don't pretend otherwise I don't see why this wouldn't be okay.
Re: -2000 Lines of Code (2007)
#83Cartoonish anecdotes like this take away from that actual value that LOC can provide to management, when employed judiciously as one data point among many. It is very informative for managers to take a periodic look at the number/frequency of commits from each engineer and their size, and from there dive into each commit and explore the denseness of the code, the cyclomatic complexity, and the overall nature of the c…
> Why have they reported at every standup the last six months Every what?
heh, I note your recent comment history is you being salty about everything you deem "cargo cult agile", and people patiently responding to that.
Yes, having a chat between the team for fifteen minutes every day is in fact quite useful, believe it or not.
We're not talking about hour long waterfall-y management progress review meetings here.
Re: -2000 Lines of Code (2007)
#84Cartoonish anecdotes like this take away from that actual value that LOC can provide to management, when employed judiciously as one data point among many. It is very informative for managers to take a periodic look at the number/frequency of commits from each engineer and their size, and from there dive into each commit and explore the denseness of the code, the cyclomatic complexity, and the overall nature of the c…
Here's some counterexamples to that idea:
- a bugfix which takes ages to find and ends up being one or two lines of locally trivial code
- a senior who spends most of their day unblocking junior devs and keeping the team on track: 0 lines of code
- overzealous code formatters: lots of lines of code
- a junior writing an overly complicated mess of a solution to a problem that could be solved much more simply: ungodly amounts of code
- a developer talking to the client directly and finding out that problem that they're trying to solve is already solved by the product in a way that the client didn't think of, rather than immediately wasting company resources on a feature that's ultimately unnecessary (0 lines of code over lots of lines of code)
There is 0 correlation, none whatsoever, between lines of code committed by a dev and their value they provide to the business.
Re: -2000 Lines of Code (2007)
#85Earlier quoted context omitted.
> Why have they reported at every standup the last six months Every what?
heh, I note your recent comment history is you being salty about everything you deem "cargo cult agile", and people patiently responding to that. Yes, having a chat between the team for fifteen minutes every day is in fact quite useful, believe it or not. We're not talking about hour long waterfall-y management progress review meetings here.
Daily status updates are not useful. Linux kernel developers don't do them. I trust that nothing is stopping your engineers from having a chat and that their manager doesn't need to schedule their chats for them.
Re: -2000 Lines of Code (2007)
#86Earlier quoted context omitted.
If six months of daily meetings did not lead anywhere then cancel those meetings.
Many teams have short daily gatherings — especially now that so many teams are fully distributed, it’s good for everyone to come together like that. But while every team member talks about the difficult bugs they’re facing, sometimes the actual code tells a different story and can reveal that a team member is struggling to get working code together in any reasonable amount of time.
It sounds like you could just read their code and the meeting was unnecessary. Linux kernel developers are distributed but don't do daily status update meetings.
Re: -2000 Lines of Code (2007)
#87Cartoonish anecdotes like this take away from that actual value that LOC can provide to management, when employed judiciously as one data point among many. It is very informative for managers to take a periodic look at the number/frequency of commits from each engineer and their size, and from there dive into each commit and explore the denseness of the code, the cyclomatic complexity, and the overall nature of the c…
It is clear that the weight attached to LOC will decline as management acquires more directly relevant information. The difficult issue is whether there is a zero lower bound.
Imagine buying in software, against a specification. A fully detailed specification with tests both for logical correctness and performance. If there is a choice of vendors, at similar prices, one naturally chooses the package with fewer lines of code. The weight attached to LOC is negative.
The anecdote is interesting because it invites the following speculation. Question: How many extra data points, beyond LOC, does one need to manage a software project? Answer: Enough that the weight attached to LOC, given optimal use of the other information available, is negative.
Re: -2000 Lines of Code (2007)
#88Cartoonish anecdotes like this take away from that actual value that LOC can provide to management, when employed judiciously as one data point among many. It is very informative for managers to take a periodic look at the number/frequency of commits from each engineer and their size, and from there dive into each commit and explore the denseness of the code, the cyclomatic complexity, and the overall nature of the c…
The main issue is the majority of managers arent especially qualified to make a judgement of the code itself which makes the metric spurious at best. Lines changed is at least a better version than lines added. But it is fairly devoid of meaning removing ten lines can be extremely hard and impactful compared to adding 1000 lines of deeply nested ifs written poorly. Lines changed multiplied by number of files touched…
Any generic measurement of productivity is a sign that the manager is incompetent.
If you're a manager and can't tell what your employees are doing, you're a terrible manager. Same reason they hate people working from home, they can't actually tell if someone's a good employee, they have no clue whether anyone is good at their job because they don't understand their job
Re: -2000 Lines of Code (2007)
#89Gave myself RSI deleting On the plus side I replaced an O(n²) algorithm with a faster one in the very next commit. Needed to get rid of the ninety copies of the same bad idiom first.
600dd:w shouldn’t cause RSI ;)
It was five to six lines of code repeated in half a dozen spots in a dozen files, with different variable names, and different arguments. And I wasn’t deleting them, I was replacing them with the same function call.
Re: -2000 Lines of Code (2007)
#90Earlier quoted context omitted.
LOC as a datapoint provide no value that a manager couldn’t get quicker and with less ambiguity via other sources. For example, identifying engineers struggling for a month on a topic, as you described, can be uncovered way earlier by replacing a reporting-Like „standup“ with collaborative structures that help the team, and the manager, understand progress and potential blockers. LOC are lagging way behind on issues…
With the exception of engineers whose role is strictly advisory, architectural, etc, for most engineers the direct literal expression of their work is the code that they commit. Not the design document, not the ideas in their head, but the code in the repo. Managers should be looking at this code in their evaluation of everyone's work. Someone with an unusually-small amount of code shouldn't be "punished" but it is s…
That is the equivalent of saying that the direct expression of a musician‘s work are the sounds they produce and therefore they should be heard in isolation.
But as much as an orchestra produces symphonies as a group, development teams produce software as a group. This output matters and should be looked at, the individual code contributions to that output matter less and looking at them in isolation doesn’t provide insights that looking at the team‘s output in terms of working software, bugs, incidents and more wouldn’t.
A manager looking at the individual LOC contributions is looking into the wrong direction.