5 ms·

Cartoonish 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

Cartoonish 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 commits. This can reveal potential problem areas for the manager to investigate with the engineer. You might find that the engineer has very few, very small commits compared to their peers, and then upon looking at the actual code you may find that the code seems rather trivial. This would warrant a conversation. Why have they reported at every standup the last six months that they're stuck behind very tricky problems when the commit history shows only a couple of seemingly simple changes? Maybe the problem really was tricky, but maybe the engineer is struggling and doesn't realize it. So let's find out. So while no one should be reduced to a simplistic LOC metric, and recognizing that more code can mean more bloat, we can't pretend that the amount of code that a developer writes is devoid of any meaning, as if it were just a random number.

lakpan 3y ago
Sorry but your argument makes no sense. The 10LOC/day guy is not to be singled out from the 1000LOC/day people because 1000 LOC could be just as trivial; 1LOC could have taken hours to discover.
- xandrius 3y ago
  Exactly! I've myself spent days investigating an issue only happening on a specific Android device (but used by an important client) only to find that the solution was something along the lines of using "opacity: 0.1" instead of 0. That bug was left unfixed for months but now it's solved. Should I have received a talk because of that? (Of course the commit would have had at least 10 LOC more, explaining the reasons and providing references to future devs/self)
  - khazhoux 3y ago
    > Should I have received a talk because of that? Of course not. But, if your commit history for last 6 months is just one or two of those one-line changes a month, that might hint that there’s a problem.
    - mdp2021 3y ago
      That makes your point clear, but then what you are looking for is not a scalar value (that may be for instance be subject to a proportional judgement) but a fuzzy threshold.
    - eviks 3y ago
      Might that hint that the problem that is there is that the metric is bad?
      - khazhoux 3y ago
        So if you managed a team, and when you look at commit histories you notice that one person has <1 commit a month and you look at the commits and they're trivial... you would disregard any concerns?
        jen20 3y ago
        I would wonder how it got to the second month, certainly - getting to the point where this kind of post-hoc analysis can actually be done is a serious failing of management.
        xandrius 3y ago
        The answer is still "it depends", I would imagine that issues would arise well before you had to look at their commit history. I believe that if you are a good manager, you would just need to look at what tickets get done during the sprint and that's it. If you complete your tickets and pass QA/UAT in 10 LOC, so be it. There is no need to micromanage.
    - Moru 3y ago
- khazhoux 3y ago
  Right. One data point among many. And managers should be looking at everyone’s code, not just the low LOC ones. But there are people (I’ve seen this frequently) who constantly represent their work as having been “much more difficult than expected” but then you discover that they actually are struggling with what should be easy tasks, and looking at code (complexity and volume) is a data point. For me, more often than not, it serves as a confirmation of a problem I’ve started to suspect.
  - eviks 3y ago
    confirmation bias indeed works that way more often than not: it confirms what you already believe
    - khazhoux 3y ago
      I'm confused which part of this is so off-putting. Joe is always the one in every standup saying the thing he's working isn't done yet because he's wrestling "one last tough bug." As a manager, you wonder if the technical problems are really that tough or if Joe is just struggling. Let's look at the commit history... yeah, something is off here, Joe has 1/10th the commits of his peers and they really don't seem more complex in any way, but look rather trivial. Time to talk to Joe and look at these commits together and see what's going on. Is that really such a troubling proposition?
      - eviks 3y ago
        So troubling that you can't propose it cleanly: if you've already defined that "they really don't seem more complex in any way, but look rather trivial", why would you need to count? (another troubling sign is going for the order of magnitude assessments, and another minor point: you've mistakenly replaced volume of code with # of commits)
      - jen20 3y ago
        So why wasn’t the response after day 1 of the “tough bug” something like “hey, why don’t you pair with X to get to the bottom of it?”?
- supriyo-biswas 3y ago
  I wonder what the grandparent would think about a few LOC/month, there were a few rather gnarly performance issues in the codebase at my work for which the fix was usually a one or two liner, but that took an inordinate amount of research to even know where to start looking. I guess I should be grateful for having a workplace that has sufficient understanding for the effort it takes to debug such issues.
  - khazhoux 3y ago
    Yes, but I'm guessing your commit history over the last year is not just 1/2-liners once a month, right?
octopusRex 3y ago
Do you really expect most managers, if any, would do this?
- khazhoux 3y ago
  No, probably not. And most don't try. My point is that --with proper context and thoughtful analysis-- it is data that can be useful.
  - peteradio 3y ago
    At the end of the day nothing about the number of commits was used in your thoughtful analysis, it was only the contents of the commits which you attribute any value.
    - khazhoux 3y ago
      Yes and no. Certainly I know lots of great developers who prefer to commit work frequently and incrementally, others who do slower bigger changes. But I don't think I know any engineers who can create a substantial amount of software with only infrequently and tiny changes. I encourage you to look at the code produced by whoever you think is the top engineer in your team or company (and I'm talking only about the engineers whose job is still primarily hands-on coding, versus advising/mentoring/architecting etc). Now look at the code by that one person who you know isn't pulling their weight and who you think isn't getting much done. I'll wager that your top engineer is pumping out a ton of strong code, and the other one is a trickle.
      - yunwal 3y ago
        > Now look at the code by that one person who you know isn't pulling their weight and who you think isn't getting much done. This is bad, but it’s not the worst type of engineer. The worst engineers often have huge deltas and can kill companies singlehandedly.
Ultimatt 3y ago
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 is possibly better too.
- mavhc 3y ago
  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
  - khazhoux 3y ago
    My entire premise is: 1) A good manager needs to look at code to see what employees are actually doing. They can't just rely on the employees' verbal description. 2) One (correlated though not guaranteed) indicator that an engineer is struggling is when they are producing much less code than their peers or compared to any natural expectation of the role. Yes of course it's 100% that some bugs are super tricky and take a long time to find the magical one-liner fix. But statistically those are not common. This is premised also on my belief that every engineer manager should be a very strong engineer themselves. This is common at most of the big tech companies.
mdp2021 3y ago
> we can't pretend that the amount of code that a developer writes is devoid of any meaning The scalar of «amount of code that a developer writes» is «devoid of any meaning» outside frameworks of streamlining of such code (which would themselves not be a good idea, as you would in fact actually have classes of code, to be judged differently). The submitted specifies it was a case of a simple scalar field in a form. Your argument is of course valid, but your conclusion disregards it. Outside a defined framework of quality adherence, the «amount of code» is «a random number». The interesting part is all in the productivity (bulk of quality). That is the area that should be investigated - in both discussion and assessment. And clearly, "amount of code produced" is a bad incentive, against quality. Aaaalways take care and beware of incentives.
pflenker 3y ago
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 like these and are devoid of any meaning in isolation. I know your counter argument here is „one data point among many“, but mine is: if your other data points are solid, LOC do not add any value.
- khazhoux 3y ago
  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 something that should be noticed and examined.
  - pflenker 3y ago
    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.
ZaoLahma 3y ago
There was a bug in an embedded system I worked on that several engineers, software as well as hardware, spent months troubleshooting. I eventually got called in and fixed it with a while loop and one function call inside of that loop. 4 lines in total, counting the brackets. A very trivial change if you didn’t know why it was there, what impact it had on the system or how much it would have continued to cost in engineering hours if I hadn’t figured out what went wrong, why it went wrong and how to fix it. I’ve spent a good chunk of my 15 years as a software developer as a pure “bug killer” and then you don’t really get to write that many lines of code, but the impact per line is big.
- khazhoux 3y ago
  Agree fully. Yours isn't the case I'm talking about. I'm talking about the people that aren't hunting big bugs, aren't serving as advisors or architects, aren't deleting unused code, and aren't implementing a significant volume of features or functionality, but who instead trickle out a small amount of simple code month after month. I claim that when inspecting commit histories, a very low LOC or very low commit-frequency is something a manager should look into.
  - datavirtue 3y ago
    All you have to do is read commit messages.
    - khazhoux 3y ago
      Reading commit messages is a poor substitute for reading code.
ResearchCode 3y ago
> Why have they reported at every standup the last six months Every what?
- khazhoux 3y ago
  Standup. Daily meetings where teams talk about their blockers and so forth.
  - ResearchCode 3y ago
    If six months of daily meetings did not lead anywhere then cancel those meetings.
    - khazhoux 3y ago
      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.
      - ResearchCode 3y ago
        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.
- erinaceousjones 3y ago
  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.
  - 3y ago
wesselbindt 3y ago
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.
- samatman 3y ago
  > There is 0 correlation, none whatsoever This is quite unlikely to be true. No correlation at all? Especially if we shift to ΔSLOC rather than +SLOC, I don't believe that for a second. You've made a good case that it's a bad proxy for productivity. It is. But there's no need to over-egg the pudding.
  - wesselbindt 3y ago
    I think it'd help to go over what the word correlation means, and then go over the examples again, and then look at the claim that there's a correlation between the value a dev provides and lines of code.
- khazhoux 3y ago
  > a bugfix which takes ages to find and ends up being one or two lines of locally trivial code I once had a junior engineer who took maybe 4-6 weeks to fix an intermittent bug in dynamic lib loading. When he finally fixed it, the fix was <5 lines of code. But it was obvious that (1) the bug was insanely deep and hard to find, and (2) he did amazing kick-ass debugging to uncover it deep in Linux code. It was great work, and he was one of our top rising talents. But that's not the kind of cases that I'm talking about. No, it's instead the engineer who gives the appearance that they're always doing tough work, but then the commit history shows that they're simply not. The person who says they're implementing a new data structure in the code, but really then take a month to replace a list with a dict in python, or whatever. This happens. > a senior who spends most of their day unblocking junior devs and keeping the team on track: 0 lines of code I'm not talking about them at all. I'm talking about people who aren't doing mentoring, advising, architecture, forward-looking design docs, etc. > 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 Yup, this happens. This is also something managers will learn by looking at 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) Absolutely. The best way to get more work done is to figure out what work you don't have to do. But if you have an engineer on your team make $200+K/year and they're not writing much code, nor writing design docs, nor advising other engineers, nor guiding the technical strategy, etc... if all the engineer does all day is "not wasting company resources" by doing very little whatsoever, you have a problem on your hands.
alan-crowe 3y ago
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.
convolvatron 3y ago
oh no. you're responsible for a group of skilled and not so skilled engineers in a domain that you don't understand. all is not lost. what is your only goal - to maximize your teams contribution to the goals of the company. full stop. its not to stack rank your employees unless it serves that greater goal. but you don't understand the domain. oh no. all you can do is develop a human relationship with the team. listen to them. you can't judge the quality of their work, but they can. don't ask them to rank each other (I've seen this), but just be attentive. after not to much time you can really start to understand how people are helping the effort, and how they are undermining it. in broad terms, without understanding the gory details. this is the only thing that works. everything else is just obfuscation.
- khazhoux 3y ago
  What's all this business about ranking that you're talking about? I didn't mention it. And asking engineers to rank each other? Seems you've picked some bad companies to work at. You should consider working somewhere where management is deeply technical. At everywhere I've worked, the entire eng-management chain (up to CEO) fully understood the domain (as you put it), the state of the art, the key system architectures, and so on. The idea that an eng manager's role should be limited to "developing human relationships and being attentive", would simply not fly. Eng managers need to be able to go into code, and they must be able to gauge the complexity of the work under them, or they'll be unable to spot the difference between someone aggressively chasing a nasty heisenbug for weeks, versus someone struggling for weeks to put together a basic block of working code.

lakpan 3y ago

Sorry but your argument makes no sense. The 10LOC/day guy is not to be singled out from the 1000LOC/day people because 1000 LOC could be just as trivial; 1LOC could have taken hours to discover.

xandrius 3y ago
Exactly! I've myself spent days investigating an issue only happening on a specific Android device (but used by an important client) only to find that the solution was something along the lines of using "opacity: 0.1" instead of 0. That bug was left unfixed for months but now it's solved. Should I have received a talk because of that? (Of course the commit would have had at least 10 LOC more, explaining the reasons and providing references to future devs/self)
- khazhoux 3y ago
  > Should I have received a talk because of that? Of course not. But, if your commit history for last 6 months is just one or two of those one-line changes a month, that might hint that there’s a problem.
  - mdp2021 3y ago
    That makes your point clear, but then what you are looking for is not a scalar value (that may be for instance be subject to a proportional judgement) but a fuzzy threshold.
  - eviks 3y ago
    Might that hint that the problem that is there is that the metric is bad?
    - khazhoux 3y ago
      So if you managed a team, and when you look at commit histories you notice that one person has <1 commit a month and you look at the commits and they're trivial... you would disregard any concerns?
      - jen20 3y ago
        I would wonder how it got to the second month, certainly - getting to the point where this kind of post-hoc analysis can actually be done is a serious failing of management.
      - xandrius 3y ago
        The answer is still "it depends", I would imagine that issues would arise well before you had to look at their commit history. I believe that if you are a good manager, you would just need to look at what tickets get done during the sprint and that's it. If you complete your tickets and pass QA/UAT in 10 LOC, so be it. There is no need to micromanage.
  - Moru 3y ago
khazhoux 3y ago
Right. One data point among many. And managers should be looking at everyone’s code, not just the low LOC ones. But there are people (I’ve seen this frequently) who constantly represent their work as having been “much more difficult than expected” but then you discover that they actually are struggling with what should be easy tasks, and looking at code (complexity and volume) is a data point. For me, more often than not, it serves as a confirmation of a problem I’ve started to suspect.
- eviks 3y ago
  confirmation bias indeed works that way more often than not: it confirms what you already believe
  - khazhoux 3y ago
    I'm confused which part of this is so off-putting. Joe is always the one in every standup saying the thing he's working isn't done yet because he's wrestling "one last tough bug." As a manager, you wonder if the technical problems are really that tough or if Joe is just struggling. Let's look at the commit history... yeah, something is off here, Joe has 1/10th the commits of his peers and they really don't seem more complex in any way, but look rather trivial. Time to talk to Joe and look at these commits together and see what's going on. Is that really such a troubling proposition?
    - eviks 3y ago
      So troubling that you can't propose it cleanly: if you've already defined that "they really don't seem more complex in any way, but look rather trivial", why would you need to count? (another troubling sign is going for the order of magnitude assessments, and another minor point: you've mistakenly replaced volume of code with # of commits)
    - jen20 3y ago
      So why wasn’t the response after day 1 of the “tough bug” something like “hey, why don’t you pair with X to get to the bottom of it?”?
supriyo-biswas 3y ago
I wonder what the grandparent would think about a few LOC/month, there were a few rather gnarly performance issues in the codebase at my work for which the fix was usually a one or two liner, but that took an inordinate amount of research to even know where to start looking. I guess I should be grateful for having a workplace that has sufficient understanding for the effort it takes to debug such issues.
- khazhoux 3y ago
  Yes, but I'm guessing your commit history over the last year is not just 1/2-liners once a month, right?

octopusRex 3y ago

Do you really expect most managers, if any, would do this?

khazhoux 3y ago
No, probably not. And most don't try. My point is that --with proper context and thoughtful analysis-- it is data that can be useful.
- peteradio 3y ago
  At the end of the day nothing about the number of commits was used in your thoughtful analysis, it was only the contents of the commits which you attribute any value.
  - khazhoux 3y ago
    Yes and no. Certainly I know lots of great developers who prefer to commit work frequently and incrementally, others who do slower bigger changes. But I don't think I know any engineers who can create a substantial amount of software with only infrequently and tiny changes. I encourage you to look at the code produced by whoever you think is the top engineer in your team or company (and I'm talking only about the engineers whose job is still primarily hands-on coding, versus advising/mentoring/architecting etc). Now look at the code by that one person who you know isn't pulling their weight and who you think isn't getting much done. I'll wager that your top engineer is pumping out a ton of strong code, and the other one is a trickle.
    - yunwal 3y ago
      > Now look at the code by that one person who you know isn't pulling their weight and who you think isn't getting much done. This is bad, but it’s not the worst type of engineer. The worst engineers often have huge deltas and can kill companies singlehandedly.

Ultimatt 3y ago

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 is possibly better too.

mavhc 3y ago
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
- khazhoux 3y ago
  My entire premise is: 1) A good manager needs to look at code to see what employees are actually doing. They can't just rely on the employees' verbal description. 2) One (correlated though not guaranteed) indicator that an engineer is struggling is when they are producing much less code than their peers or compared to any natural expectation of the role. Yes of course it's 100% that some bugs are super tricky and take a long time to find the magical one-liner fix. But statistically those are not common. This is premised also on my belief that every engineer manager should be a very strong engineer themselves. This is common at most of the big tech companies.

mdp2021 3y ago

> we can't pretend that the amount of code that a developer writes is devoid of any meaning The scalar of «amount of code that a developer writes» is «devoid of any meaning» outside frameworks of streamlining of such code (which would themselves not be a good idea, as you would in fact actually have classes of code, to be judged differently). The submitted specifies it was a case of a simple scalar field in a form. Your argument is of course valid, but your conclusion disregards it. Outside a defined framework of quality adherence, the «amount of code» is «a random number». The interesting part is all in the productivity (bulk of quality). That is the area that should be investigated - in both discussion and assessment. And clearly, "amount of code produced" is a bad incentive, against quality. Aaaalways take care and beware of incentives.

pflenker 3y ago

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 like these and are devoid of any meaning in isolation. I know your counter argument here is „one data point among many“, but mine is: if your other data points are solid, LOC do not add any value.

khazhoux 3y ago
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 something that should be noticed and examined.
- pflenker 3y ago
  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.

ZaoLahma 3y ago

There was a bug in an embedded system I worked on that several engineers, software as well as hardware, spent months troubleshooting. I eventually got called in and fixed it with a while loop and one function call inside of that loop. 4 lines in total, counting the brackets. A very trivial change if you didn’t know why it was there, what impact it had on the system or how much it would have continued to cost in engineering hours if I hadn’t figured out what went wrong, why it went wrong and how to fix it. I’ve spent a good chunk of my 15 years as a software developer as a pure “bug killer” and then you don’t really get to write that many lines of code, but the impact per line is big.

khazhoux 3y ago
Agree fully. Yours isn't the case I'm talking about. I'm talking about the people that aren't hunting big bugs, aren't serving as advisors or architects, aren't deleting unused code, and aren't implementing a significant volume of features or functionality, but who instead trickle out a small amount of simple code month after month. I claim that when inspecting commit histories, a very low LOC or very low commit-frequency is something a manager should look into.
- datavirtue 3y ago
  All you have to do is read commit messages.
  - khazhoux 3y ago
    Reading commit messages is a poor substitute for reading code.

ResearchCode 3y ago

> Why have they reported at every standup the last six months Every what?

khazhoux 3y ago
Standup. Daily meetings where teams talk about their blockers and so forth.
- ResearchCode 3y ago
  If six months of daily meetings did not lead anywhere then cancel those meetings.
  - khazhoux 3y ago
    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.
    - ResearchCode 3y ago
      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.
erinaceousjones 3y ago
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.
- 3y ago

wesselbindt 3y ago

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.

samatman 3y ago
> There is 0 correlation, none whatsoever This is quite unlikely to be true. No correlation at all? Especially if we shift to ΔSLOC rather than +SLOC, I don't believe that for a second. You've made a good case that it's a bad proxy for productivity. It is. But there's no need to over-egg the pudding.
- wesselbindt 3y ago
  I think it'd help to go over what the word correlation means, and then go over the examples again, and then look at the claim that there's a correlation between the value a dev provides and lines of code.
khazhoux 3y ago
> a bugfix which takes ages to find and ends up being one or two lines of locally trivial code I once had a junior engineer who took maybe 4-6 weeks to fix an intermittent bug in dynamic lib loading. When he finally fixed it, the fix was <5 lines of code. But it was obvious that (1) the bug was insanely deep and hard to find, and (2) he did amazing kick-ass debugging to uncover it deep in Linux code. It was great work, and he was one of our top rising talents. But that's not the kind of cases that I'm talking about. No, it's instead the engineer who gives the appearance that they're always doing tough work, but then the commit history shows that they're simply not. The person who says they're implementing a new data structure in the code, but really then take a month to replace a list with a dict in python, or whatever. This happens. > a senior who spends most of their day unblocking junior devs and keeping the team on track: 0 lines of code I'm not talking about them at all. I'm talking about people who aren't doing mentoring, advising, architecture, forward-looking design docs, etc. > 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 Yup, this happens. This is also something managers will learn by looking at 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) Absolutely. The best way to get more work done is to figure out what work you don't have to do. But if you have an engineer on your team make $200+K/year and they're not writing much code, nor writing design docs, nor advising other engineers, nor guiding the technical strategy, etc... if all the engineer does all day is "not wasting company resources" by doing very little whatsoever, you have a problem on your hands.

alan-crowe 3y ago

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.

convolvatron 3y ago

oh no. you're responsible for a group of skilled and not so skilled engineers in a domain that you don't understand. all is not lost. what is your only goal - to maximize your teams contribution to the goals of the company. full stop. its not to stack rank your employees unless it serves that greater goal. but you don't understand the domain. oh no. all you can do is develop a human relationship with the team. listen to them. you can't judge the quality of their work, but they can. don't ask them to rank each other (I've seen this), but just be attentive. after not to much time you can really start to understand how people are helping the effort, and how they are undermining it. in broad terms, without understanding the gory details. this is the only thing that works. everything else is just obfuscation.

khazhoux 3y ago
What's all this business about ranking that you're talking about? I didn't mention it. And asking engineers to rank each other? Seems you've picked some bad companies to work at. You should consider working somewhere where management is deeply technical. At everywhere I've worked, the entire eng-management chain (up to CEO) fully understood the domain (as you put it), the state of the art, the key system architectures, and so on. The idea that an eng manager's role should be limited to "developing human relationships and being attentive", would simply not fly. Eng managers need to be able to go into code, and they must be able to gauge the complexity of the work under them, or they'll be unable to spot the difference between someone aggressively chasing a nasty heisenbug for weeks, versus someone struggling for weeks to put together a basic block of working code.