-2000 Lines of Code (2007)(folklore.org)
folklore.org
-2000 Lines of Code (2007)
https://www.folklore.org/Negative_2000_Lines_Of_Code.html
221 comments
Not just IBM. A few years back I worked on a large project with one of the big international consulting companies as the prime contractor. They threw a party for the whole team when the codebase hit one million lines of code.
Those of us who knew better treated the "celebration" as a wake.
Those of us who knew better treated the "celebration" as a wake.
It's terrifying working around fintec and seeing how many 20MLOC monoliths are laying around and the code quality issues that crop up in them.
This is cope. those applications are there because they work. Mistakes in "20M LOC monoliths" are exceedingly rare in the financial world. Look how bad "hipster" software is in comparison! Billions in profit means billions in quality
The problem is not that they don't work, it's that they can't ever be touched again because it's impossible for anything to understand the code.
The people looking at them just lack the skills...
For a bit of context, the TV series this refers to is called „Triumph of the Nerds” and it’s a great watch, even today (maybe ever more so?).
Found it on youtube: https://www.youtube.com/watch?v=toSRmKKiosQ
Counting lines of code as a production metric is very stupid.
I remember solving an unsolvable 20 years old bug with a line of code, another 3 years old with a order by. How to measure the impact of a line of code? And in my experience, bad programmers write a lot more code...
I will never forget the story[1] of a Microsoft developer rewriting a piece of IBM code that had 33 thousand characters, after rewrite ... 220. This generated a war because MS's work was... negative.
[1] https://archive.org/details/bigbluesunmaking00carr/page/4/mo... page 101
I will never forget the story[1] of a Microsoft developer rewriting a piece of IBM code that had 33 thousand characters, after rewrite ... 220. This generated a war because MS's work was... negative.
[1] https://archive.org/details/bigbluesunmaking00carr/page/4/mo... page 101
Using production metrics as a whole is very stupid and a good way to get devs to optimize for the metrics rather than quality work. A contemporary example would be a company that promotes for "impact" (i.e. launching new products) which is a great way to have a bunch of failed products that nobody maintains!
The trick is to align the metrics with company goals. It's not easy, but not impossible either.
For example, if quality is your goal, then the metric you give your devs is "number and severity of bug reports coming in from customers". If unsatisfied feature requests are part of that number, then the devs have to strike a balance between churning out features and preventing bugs (and fixing discovered ones).
Obviously your customer support needs a different metric.
For example, if quality is your goal, then the metric you give your devs is "number and severity of bug reports coming in from customers". If unsatisfied feature requests are part of that number, then the devs have to strike a balance between churning out features and preventing bugs (and fixing discovered ones).
Obviously your customer support needs a different metric.
Ye and you end up with blame games and hot potatoes being passed around.
Bug count metrics incentives "don't touch anything" and coding with feuture flags and globals to limit the scope of change and circumvent the architecture.
Like, just don't do metrics and have the management actually review the work of their subordinates if that is important to follow up on. Actual management can't be compressed to a acting on some scalar values.
Bug count metrics incentives "don't touch anything" and coding with feuture flags and globals to limit the scope of change and circumvent the architecture.
Like, just don't do metrics and have the management actually review the work of their subordinates if that is important to follow up on. Actual management can't be compressed to a acting on some scalar values.
Objective measures are a good thing. Otherwise you just end up with some subjective opinions nitting bro culture even closer together.
I know at least a few many-hundred-billion dollar companies that fit that description...
I’m sure there are engineers who fix a critical bug every few months and generate millions of dollars of value, but as a general rule great engineers tend to be prolific and engineers who aren’t prolific tend to not be great.
Engineers who are obsessed with greatness tend to not be great either
In my opinion, there is still some relation between LoC and engineering output over a long period of time. Some of the greatest computer scientists and engineers have insane code outputs and I believe it does directly translate into impact in some ways. The issue is when Loc becomes a metric to measure performance. At that point, we have an instance of Goodhart's Law: “When a measure becomes a target, it ceases to be a good measure.”.
As your examples indicate, one reason it's a bad production metric is that it's a reasonable measure of the burden carried by the maintainers of the codebase. The production metric point of view classifies code as an asset. It's closer to the truth to view the functionality as an asset, and the code itself as a liability.
This comes up often! A few previous discussions:
https://news.ycombinator.com/item?id=33483165 (2022)
https://news.ycombinator.com/item?id=26387179 (2021)
https://news.ycombinator.com/item?id=10734815 (2015)
https://news.ycombinator.com/item?id=7516671 (2014)
https://news.ycombinator.com/item?id=4040082 (2012)
https://news.ycombinator.com/item?id=1114223 (2010)
https://news.ycombinator.com/item?id=1545452 (2010)
https://news.ycombinator.com/item?id=33483165 (2022)
https://news.ycombinator.com/item?id=26387179 (2021)
https://news.ycombinator.com/item?id=10734815 (2015)
https://news.ycombinator.com/item?id=7516671 (2014)
https://news.ycombinator.com/item?id=4040082 (2012)
https://news.ycombinator.com/item?id=1114223 (2010)
https://news.ycombinator.com/item?id=1545452 (2010)
Early in my career I once optimized an inherited 10,000+ line C program to less than 500 lines. It was a C program making SQL calls into a Sybase database.
No, not because I had some brilliant insight but for the simple assumption that my predecessor may not have been aware of how to write functions or use parameters to supply variable data to the SQL query. They had literally written the same SQL statement inline with a couple of changed values in each SQL call.
I just rewrote the code making the SQL call as a function call with bind variables as parameters into the function. All the replicated inline code was replaced with the function being called in a loop with the changed bind values supplied from an array.
No, not because I had some brilliant insight but for the simple assumption that my predecessor may not have been aware of how to write functions or use parameters to supply variable data to the SQL query. They had literally written the same SQL statement inline with a couple of changed values in each SQL call.
I just rewrote the code making the SQL call as a function call with bind variables as parameters into the function. All the replicated inline code was replaced with the function being called in a loop with the changed bind values supplied from an array.
[deleted]
Yooo, no params == no injection /s
The 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.
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.
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.
When I managed software for a large corporate, I kept a box of pencils on my desk.
For around 1/2 the information requests that came through the department (always very important, we need the info now, it will save/make big dollars) the obvious answer was "Work it out from the info you already have. You've got a calculator and spreadsheet - would you like a pencil?"
Better to avoid the system handling X than having multiple special cases bulking up the systems, most of which only get used once in a blue moon. No one knows the special cases/programs are there, or what actually do. Even if well documented, no one spends the time required to know what's available. So most of those special features are actually waste of time.
For around 1/2 the information requests that came through the department (always very important, we need the info now, it will save/make big dollars) the obvious answer was "Work it out from the info you already have. You've got a calculator and spreadsheet - would you like a pencil?"
Better to avoid the system handling X than having multiple special cases bulking up the systems, most of which only get used once in a blue moon. No one knows the special cases/programs are there, or what actually do. Even if well documented, no one spends the time required to know what's available. So most of those special features are actually waste of time.
A corresponding thought-experiment is to consider the results of the opposite situation: if a manager read this article, and simplemindedly decided to measure by lines of code removed instead. Would that make things better or worse?
Easier to be gamed depending on the company and method of measuring; let llama dream up code that looks fine, add some code so the code has no actual effect, commit, remove at some time later. Any measuring of this kind is pretty much useless you have solid code review practices in general place (which, unlike people here like to believe, is a rarity). But with good reviews, underperformance and gaming the system would also be caught so you would have less reason to implement metrics like this.
Marginally worse, but not as bad as you'd think, because the industry already has similar shortsighted impulses in that direction.
For example, the perennial idea of replacing all the software engineers and their arcane code-text with product-managers drawing some special diagrams or flowcharts for "low"/"no"-code results.
For example, the perennial idea of replacing all the software engineers and their arcane code-text with product-managers drawing some special diagrams or flowcharts for "low"/"no"-code results.
Any line-based metric should be suspect, but 'delta-SLOC' is probably the least bad. I would count added lines and removed lines separately, so a +50,-150 patch would be 200 ΔSLOC.
This isn't a good measure of productivity, especially not in isolation, but it's a reasonable napkin-math metric of change. A developer with a high ΔSLOC count may or may not be more productive than a peer who has a week or two of no ΔSLOC at all, depending on what that peer is up to, but the first of these is definitely changing the codebase more than the second, during the measured time span.
This isn't a good measure of productivity, especially not in isolation, but it's a reasonable napkin-math metric of change. A developer with a high ΔSLOC count may or may not be more productive than a peer who has a week or two of no ΔSLOC at all, depending on what that peer is up to, but the first of these is definitely changing the codebase more than the second, during the measured time span.
There is I believe a specific context where removal is good and others where that is not the right measure
I'm working on some java 8 cide that was written by folks still living in java 1.4 land, lots of opportunities there to reduce 20 lines into 3 (plus those devs kinda insisted on doing things in painful and unnecessary ways). In parallel, I'm working on a Greenfield project. Even on the Greenfield, there are times when negative code added is good. Not all programmer activities are equal
It's like measuring gas consumption during emergency braking, during acceleration, and during normal highway cruising. Sometimes it firs, or kinda fits, other times it's just the wrong metric. Programming is not a homogeneous activity
I'm working on some java 8 cide that was written by folks still living in java 1.4 land, lots of opportunities there to reduce 20 lines into 3 (plus those devs kinda insisted on doing things in painful and unnecessary ways). In parallel, I'm working on a Greenfield project. Even on the Greenfield, there are times when negative code added is good. Not all programmer activities are equal
It's like measuring gas consumption during emergency braking, during acceleration, and during normal highway cruising. Sometimes it firs, or kinda fits, other times it's just the wrong metric. Programming is not a homogeneous activity
I think we agree with each other? Or mostly so.
ΔSLOC is just a metric, and what it measures is change to the codebase. Yes, some changes are very important, and others nearly trivial, so it's quantitive because a qualitative metric is a contradiction.
It certainly means different things in different contexts, if it's even meaningful at all. My claim is that +SLOC is entirely meaningless outside of the tautology that it measures what it is, where ΔSLOC is in fact informative about change to the software, albeit not perfectly so.
ΔSLOC is just a metric, and what it measures is change to the codebase. Yes, some changes are very important, and others nearly trivial, so it's quantitive because a qualitative metric is a contradiction.
It certainly means different things in different contexts, if it's even meaningful at all. My claim is that +SLOC is entirely meaningless outside of the tautology that it measures what it is, where ΔSLOC is in fact informative about change to the software, albeit not perfectly so.
I believe we would agree, yes.
My hope is to convey more texture here, that programming is more than just one thing. EG: "Today I was mostly debugging". That could have its own measures. I think in large part the measures of programming productivity are often too reductive, the measure is incomplete or tries to measure "programming" rather than its _many_ distinct sub-activities.
My hope is to convey more texture here, that programming is more than just one thing. EG: "Today I was mostly debugging". That could have its own measures. I think in large part the measures of programming productivity are often too reductive, the measure is incomplete or tries to measure "programming" rather than its _many_ distinct sub-activities.
Worse, because codegolfing the entire codebase is undesirable.
Definitely no new features.
If the product is "finished" then it would probably be equal or better (otherwise the negative LOC change wouldn't make it to prod).
But most products are ever evolving (that's why we have the luxury of remaining on the same project for years), so just negative contributions will invariably not add anything.
If the product is "finished" then it would probably be equal or better (otherwise the negative LOC change wouldn't make it to prod).
But most products are ever evolving (that's why we have the luxury of remaining on the same project for years), so just negative contributions will invariably not add anything.
Cue the perl one line challenges.
Metrics that are team level dashboards and not shared outside of the team are different from pay and promotion incentivized metrics. The same metric can have very different behavioral outcomes between the two scenarios
Metrics that are team level dashboards and not shared outside of the team are different from pay and promotion incentivized metrics. The same metric can have very different behavioral outcomes between the two scenarios
The real story here is that sometimes you start a project and don't really know exactly where you're going, as you get into it you start to understand both the problem and the answer you want much better - and then yes, you can rip a chunk out and replace it with something smaller and better
And don't forget, these guys had to fit everything, including those -2000 lines of code (assembler code) into 64kbytes of ROM - there was intense pressure to make stuff smaller
And don't forget, these guys had to fit everything, including those -2000 lines of code (assembler code) into 64kbytes of ROM - there was intense pressure to make stuff smaller
QuickDraw is mostly written in Pascal with critical loops in assembly[1,2]. I’m also not sure if it’s in actually in ROM or on the boot floppy. (Incidentally, Wikipedia tells me the Lisa’s ROM was 16K.)
[1] https://computerhistory.org/blog/the-lisa-apples-most-influe...
[2] https://computerhistory.org/blog/macpaint-and-quickdraw-sour...
[1] https://computerhistory.org/blog/the-lisa-apples-most-influe...
[2] https://computerhistory.org/blog/macpaint-and-quickdraw-sour...
I think it started out in ROM, it has low core jump vectors so that portions can be replaced (rather than just the whole thing) I worked designing Mac graphics accelerators back in the day, we hooked them up by replacing bits of QD through these vectors. So over time rom fixes got made and some of it would have come off of disk
If you follow that second link you'll find a zip file with quickdraw source in it, you'll find that while there is a little pascal (.p files) most of the core is assembler (.a files)
If you follow that second link you'll find a zip file with quickdraw source in it, you'll find that while there is a little pascal (.p files) most of the core is assembler (.a files)
Also putting display core routines in ROM was important because RAM access was slower (because the display used 1/2 the RAM bandwidth)
Good point. The Amiga did the same thing in the Amiga 500 and 2000. The Amiga 1000 would have if the operating system had been more stable at time of release. It also saved a significant chunk of RAM as the 1.x releases of AmigaOS used 256KB ROMs while 2.x on were 512KB ROMs.
Bill Atkinson, of Atkinson Dither fame. https://beyondloom.com/blog/dither.html
Bill Atkinson wrote QuickDraw (the graphics libraries that underpinned the Lisa and Mac UI), and MacPaint, and HyperCard.
Along the way he kept having to both invent new ways for user interfaces to work, and new ways to write software to solve for them. There's a kind of synergy that emerged out of the fact that he was optimizing both for 'can be done quickly in the hardware available on the Mac', and 'provides a great user experience', which means that his fingerprints are all over the aesthetic of the old black and white Mac. That dither style is another example of that kind of marriage of algorithmic genius and aesthetic sensibility.
And it shows up in things like the 'marching ants' selection boundary (https://en.wikipedia.org/wiki/Marching_ants). Or the way lots of user feedback in the classic Mac UI comes in the form of inverting pixels (text selection, menu highlighting, the way buttons appear during a mouse-down, the boundary of a window while it's being dragged), because drawing over something in XOR mode was a great way to generate that effect. The way he approached putting these tools together in QuickDraw also had the effect of things like his famous conversation with Steve Jobs about rounded rectangles (https://www.folklore.org/Round_Rects_Are_Everywhere.html) manifesting as it being as easy to draw a rounded rectangle as a square one in QuickDraw, which led to them showing up everywhere in the operating system.
The success of the Mac UI was not just that it looked good; it was in large parts that Bill Atkinson made a really cleaver, small set of tools that made making things that looked good easy to make.
Susan Kare's amazing icons wouldn't be nearly as fondly remembered if Bill hadn't built the tools that made it easy to drop 32x32 pixel masked bitmaps into the UI and invert them when you clicked on them.
Along the way he kept having to both invent new ways for user interfaces to work, and new ways to write software to solve for them. There's a kind of synergy that emerged out of the fact that he was optimizing both for 'can be done quickly in the hardware available on the Mac', and 'provides a great user experience', which means that his fingerprints are all over the aesthetic of the old black and white Mac. That dither style is another example of that kind of marriage of algorithmic genius and aesthetic sensibility.
And it shows up in things like the 'marching ants' selection boundary (https://en.wikipedia.org/wiki/Marching_ants). Or the way lots of user feedback in the classic Mac UI comes in the form of inverting pixels (text selection, menu highlighting, the way buttons appear during a mouse-down, the boundary of a window while it's being dragged), because drawing over something in XOR mode was a great way to generate that effect. The way he approached putting these tools together in QuickDraw also had the effect of things like his famous conversation with Steve Jobs about rounded rectangles (https://www.folklore.org/Round_Rects_Are_Everywhere.html) manifesting as it being as easy to draw a rounded rectangle as a square one in QuickDraw, which led to them showing up everywhere in the operating system.
The success of the Mac UI was not just that it looked good; it was in large parts that Bill Atkinson made a really cleaver, small set of tools that made making things that looked good easy to make.
Susan Kare's amazing icons wouldn't be nearly as fondly remembered if Bill hadn't built the tools that made it easy to drop 32x32 pixel masked bitmaps into the UI and invert them when you clicked on them.
The moral: even if you are smart as Einstein you are still an employee and need to do employee things.
If Einstein was pressured by metrics we would have never heard of him.
I suspect he was... as a patent clerk. And that may be why we never heard of him THEN.
> I suspect he was... as a patent clerk.
I believe he managed to work on patents only in the morning..
I believe he managed to work on patents only in the morning..
I never understood why is it when people talk about LoC of code written, they always use 'lines added - lines removed'. If I do a run 10km run and end up in the same place I started, it's not a 0km run.
I think a part of it is that dumb diff tools may record large diffs when the change in functionality is limited and the rest is more or less moving lines around. Like making
if cond { ... return; } ...
into
if cond { ... return; } else { .... }
But that's not comprehensive either.
if cond { ... return; } ...
into
if cond { ... return; } else { .... }
But that's not comprehensive either.
If you measure productivity by LOC, then generally what you will get is lots of LOC. Cut and paste is easy if that's what makes you look good.
Of course what companies should really be incentivizing is well written code that is easy to maintain and extend, not bloated cut-n-paste garbage.
Of course what companies should really be incentivizing is well written code that is easy to maintain and extend, not bloated cut-n-paste garbage.
And when somebody figures out how to metricize "well written" then that will turn to fecal matter. Re: Goodhart's Law [1] (admittedly meant to be economic, yet applies to most metrics).
Also related to Enshittification (see fecal matter), the platform shifts, no longer prioritizes quality, and instead shifts to whatever "well written" is defined as.
LLM's and especially online song choice algorithms have a heavy dose of this. "Make whatever pop music says is 'well written'" You have included all the keywords necessary to SEO your billboard submission.
Also related to Enshittification (see fecal matter), the platform shifts, no longer prioritizes quality, and instead shifts to whatever "well written" is defined as.
LLM's and especially online song choice algorithms have a heavy dose of this. "Make whatever pop music says is 'well written'" You have included all the keywords necessary to SEO your billboard submission.
Where does Uncle Bob fit into this? Because he sure does love to give advice
How small a function should be? https://youtu.be/rXjf8eiGsSI
How small a function should be? https://youtu.be/rXjf8eiGsSI
I think I'm totally missing the reference (apparently the Robert in the video?). I thought it was Bob's your uncle (instructions complete), or Uncle Bob the photographer (who doesn't know how to use his own equipment).
Pretty sure its not a T-800 Terminator or smoking pot like Bob Marley reference.
Also, totally feel like an LLM doing the %chance this word game.
Pretty sure its not a T-800 Terminator or smoking pot like Bob Marley reference.
Also, totally feel like an LLM doing the %chance this word game.
Google Robert Martin => "first chairman of the Agile Alliance".
Wouldn't the really agile thing be to get rid of alliances and chairmen in charge of telling people how to develop software?
Wouldn't the really agile thing be to get rid of alliances and chairmen in charge of telling people how to develop software?
It’s the wrong metric. We all know that. It’s like measuring a manager by “meetings attended” or something like that.
The hard part is measuring the effectiveness of people whose output is realized in the future, not today.
The hard part is measuring the effectiveness of people whose output is realized in the future, not today.
I guess somehow remarks about lines of code being (mostly) meaningless to measure programmers’ productivity feels related to the extent of the impact AI will have on software engineering.
this keeps coming… recently there’s been a bit of debate between Milvus and Qdrant on this topic: https://www.linkedin.com/posts/yujiantang_how-can-you-judge-...
It was a great write up in its time but has since become a goto cliche for people who can't write much code.
Article: "Did you know that geniuses like Einstein tend to be night owls?"
Unemployed guy who wakes up at 11 a.m. every day: "I must be a genius!"
Barba non facit philosophum: a beard doesn't make one a philosopher.
Unemployed guy who wakes up at 11 a.m. every day: "I must be a genius!"
Barba non facit philosophum: a beard doesn't make one a philosopher.
> But the fact that some geniuses were laughed at does not imply that all who are laughed at are geniuses. They laughed at Columbus, they laughed at Fulton, they laughed at the Wright brothers. But they also laughed at Bozo the Clown.
― Carl Sagan
― Carl Sagan
This is what I always think of when someone tells me that AI will replace coders. I tell them: "A coder can only write about 100 lines of good code a day, but I look forward to when the AI can write 100 million lines of code a day."
I do a lot of code review for SQL. One thing that I always to is reduce the number of lines of code, usually by ~10% on the first read. I need to focus not to become a target :)
Was this the original TPS report?
In evaluating software value, lines of code fall under the denominator.
Same nonsense at Convergent in the early days. Jim Frandeen worked on tightening up the OS, saved like 10% memory footprint. Likewise, a negative code count. That manager actually quit.
My own experience was changing a 10K line module with a template in one page. Put some angle-brackets in about 100 references which left a net -9900 LOC
My own experience was changing a 10K line module with a template in one page. Put some angle-brackets in about 100 references which left a net -9900 LOC
[deleted]
There is a deeper lesson here: Someone was thinking of lines of code as an asset, not a cost. It's a an error you also see in junior programmers writing reams and reams of code. The lesson is a harsh one for us code lovers, at least it was for me:
Code is a means to an end, and an expensive one at that. The best code is the code never written. Our job is to solve problems, not to write code.
You can use LOC as a crude measure of progress, in the same way as tons of concrete used is a crude measure of progress when building a skyscraper.
Code is a means to an end, and an expensive one at that. The best code is the code never written. Our job is to solve problems, not to write code.
You can use LOC as a crude measure of progress, in the same way as tons of concrete used is a crude measure of progress when building a skyscraper.
Not even that, I'm not a civil engineer, but it looks pretty hard to add a ton of concrete without really helping a skyscraper, but I could add a few thousand lines of code without improving a system one bit, and even more lines to make the system slower, more complex, and still not add any functionality.
LoC is about as good a measure of a system quality as weight is for an aircraft project.
LoC is about as good a measure of a system quality as weight is for an aircraft project.
> LoC is about as good a measure of a system quality as weight is for an aircraft project.
This is a very good an analogy. A plane has to weigh something, but the absurdity of measuring how much progress you’ve made building a plane by how much weight you’ve added is immediately obvious.
This is a very good an analogy. A plane has to weigh something, but the absurdity of measuring how much progress you’ve made building a plane by how much weight you’ve added is immediately obvious.
> Not even that, I'm not a civil engineer, but it looks pretty hard to add a ton of concrete without really helping a skyscraper.
I am also not a civil engineer but I can think of a lot of ways to add concrete to a skyscraper in ways that are somewhere between nonhelpful and burdensome.
I am also not a civil engineer but I can think of a lot of ways to add concrete to a skyscraper in ways that are somewhere between nonhelpful and burdensome.
You might acknowledge this analogy is popularly ascribed originally to Bill Gates.
“Measuring programming progress by lines of code is like measuring aircraft building progress by weight.” ― Bill Gates
“Measuring programming progress by lines of code is like measuring aircraft building progress by weight.” ― Bill Gates
Very clever analogy!
This sentiment goes too far in the opposite direction for me. Code that solves a problem is an asset. To carry your analogy forward, code is the concretization of the solution of the problem. The idea of the skyscraper is useless on its own and requires the concrete that materializes it. The skyscraper would become a lot less valuable if you removed the concrete...
Of course, you also don't make the skyscraper better by indefinitely adding concrete. A balance must be found with the right amount to be load bearing but not too much. Just like code.
Of course, you also don't make the skyscraper better by indefinitely adding concrete. A balance must be found with the right amount to be load bearing but not too much. Just like code.
Agreed. And a point that keeps getting missed whenever this discussion comes up is there's a big difference between junior and senior programmers. What should a junior programmer do? Write as much code as possible! KLOC is a pretty good measure of progress for junior programmers, how else do you get better at programming? To know when not to write a line of code, you have to know how to write the line of code in the first place.
It's not a spectrum, instead a duality. An engine is an asset, yet it needs maintenance. Because software is soft, existing assets become yet more stuff to understand, more stuff to fix and keep in sync.
Compare for example a building made of stacked stone, brick, concrete, or modular carbon sheets on rebar
Another example, 100 hotel rooms, rearrange the layout and it's 101 things to do.
The analogies still fail, software updates are more akin to welding an airplane on to a car attached to a subway train. It's less, oh, we need to rework these weldzhere, it's often trying to make the software do something that is radically different. Like inserting a romance chapter into a mystery novel that starts as a chemistry how-to
Compare for example a building made of stacked stone, brick, concrete, or modular carbon sheets on rebar
Another example, 100 hotel rooms, rearrange the layout and it's 101 things to do.
The analogies still fail, software updates are more akin to welding an airplane on to a car attached to a subway train. It's less, oh, we need to rework these weldzhere, it's often trying to make the software do something that is radically different. Like inserting a romance chapter into a mystery novel that starts as a chemistry how-to
Costs are not a pure negative. Just like a skyscraper without concrete would be silly, so is an IT solution without code. I have no problem paying for extra code, just like I have no problem paying for an extra server. IF they are worth it. Software engineering is also the act of making a reasonable tradeoff.
Lines of code are capital. They cost money to make, and they cost money to maintain. They can be productive capital, but if they aren't, they're a drain on your resources and a liability.
This is what fills me with dread when it comes to LLM coding assistants.
LLMs solve the problem of "we don't have enough code, so let's generate low-quality code faster than ever", which, to a first approximation, is not actually the problem that anyone has; the problem we have is that we don't have the right code, and the code that we do have is already shit.
But at least managers will be happy that their reports are now checking in +100,000 LoC a day. What could possibly go wrong?
LLMs solve the problem of "we don't have enough code, so let's generate low-quality code faster than ever", which, to a first approximation, is not actually the problem that anyone has; the problem we have is that we don't have the right code, and the code that we do have is already shit.
But at least managers will be happy that their reports are now checking in +100,000 LoC a day. What could possibly go wrong?
"Our job is to solve problems, not to write code."
My job is what my employers pays me to do. If my employer agrees with that sentiment then it is. If I'm volunteering on open source, I can do my best, but if my employers rewards lines of code, then I produce LOC. Of course, picking a better employer factors in there somewhere.
My job is what my employers pays me to do. If my employer agrees with that sentiment then it is. If I'm volunteering on open source, I can do my best, but if my employers rewards lines of code, then I produce LOC. Of course, picking a better employer factors in there somewhere.
Wait, does anyone _actually_ reward lines of code today, in this future year of 2024? Like, I remember people joking 20 years ago about how it was the sort of thing companies like IBM used to do in the 80s.
Maybe I've been lucky, but I've been in big (10's of 1000's of employees) firms and small (10's of employees) firms, since the mid 1980's, and have never been measured on LsOC. But I play along with the joke, because it's an easy strawman.
That said, there are other equally bad metrics that are in current use.
That said, there are other equally bad metrics that are in current use.
Lots of people joke about it, but lots of bosses still look at it. When your boss treats the most prolific coders as the best, it sends a message.
Partially true. One of my less glorious days in IT was spent mopping water out of servers. We've all sbeen in situations where the best course of action was to shut up, sit down, type tons of dumb code, and deal with the fallout later.
But if this happens more than rarely, you either find a new job or stay and live with the fact that you've become a second rate programmer in a second rate company.
But if this happens more than rarely, you either find a new job or stay and live with the fact that you've become a second rate programmer in a second rate company.
Sucks doing something you know is a waste. I value my time and personal growth more than my employer does.
As a developer few things make me glow like deleting hundreds of lines of code that have been replaced by simplicity.
I can't believe no one as yet has trotted out the Dijkstra quote, so I will: https://www.azquotes.com/quote/754979
[deleted]
> they stopped asking Bill to fill out the form
which is only possible because he's so important.
imagine doing this as a stack-ranked IC in an org like AWS.
The old days of a software as an artisanal craft is long over imho.
which is only possible because he's so important.
imagine doing this as a stack-ranked IC in an org like AWS.
The old days of a software as an artisanal craft is long over imho.
I'm by no means important in my org but when something appears like a shitty idea I will raise that (like other ICs around me) and more often than not it works out fine. I'll agree to give something a shot but if it doesn't work it doesn't work and my managers so far have all realized that a bit into the trial period.
Reading comments like yours, I guess I should value my work environment more.
Reading comments like yours, I guess I should value my work environment more.
It's not about speaking up on a shitty idea, it's about not playing the game on a tool used to measure employee performance. That's a big difference.
Especially because here we're talking about someone whose performance and contributions were very clear to everyone. Otherwise, he might have been seen like an underperformer by managers.
Especially because here we're talking about someone whose performance and contributions were very clear to everyone. Otherwise, he might have been seen like an underperformer by managers.
If you want to see an extrema of people being afraid to speak up, just look at the Gemini image examples in a company that in theory encourages people to speak up. There are always topics that are exceptions.
If you're OOTL on Google Gemini ML-based content creator then https://blog.google/products/gemini/gemini-image-generation-... is a pretty good summary.
Ostensibly it appeared to be tuned to be racist.
Maybe Google encourages people to speak up but also has a culture of racism?
Ostensibly it appeared to be tuned to be racist.
Maybe Google encourages people to speak up but also has a culture of racism?
I think you are very fortunate then. The number of times I have raised concerns and my warnings have been ignored ... Even when I had direct past learning or experience with the thing they want to do, I can no longer change their mind.
The question is really more do they actually act on the feedback on a regular basis?
Yeah, honestly over nearly 20 years of working in this industry, I’m not sure that I’ve ever worked anywhere where there’d be significant management pushback on something like this. Now, granted, I’ve mostly worked in small companies, and one rather selective largish companies; maybe things really are much worse in the truly huge companies.
> The old days of a software as an artisanal craft is long over imho.
In corporate or government software work, sure. But there are no guilds anywhere in those organizations... unless you count the upper executives.
You might not get paid for it, but the artisanal craft of software is alive and well in free and open source software around the world. Tons of those projects get posted to HN. An app can be a home cooked meal and all that jazz. Lots of open source has been corportized too, but many are closer to an artisanal craft guild than modern corporate software work.
And if it is your startup, you can write code however you want.
In corporate or government software work, sure. But there are no guilds anywhere in those organizations... unless you count the upper executives.
You might not get paid for it, but the artisanal craft of software is alive and well in free and open source software around the world. Tons of those projects get posted to HN. An app can be a home cooked meal and all that jazz. Lots of open source has been corportized too, but many are closer to an artisanal craft guild than modern corporate software work.
And if it is your startup, you can write code however you want.
> free and open source software around the world.
aka, you are not economically valued, and in order to be artisanal, you have to sacrifice monetary gains to achieve it.
> if it is your startup, you can write code however you want.
yes that is true, but a startup is much more than just code. it's a business - with all of the extra work that entails.
aka, you are not economically valued, and in order to be artisanal, you have to sacrifice monetary gains to achieve it.
> if it is your startup, you can write code however you want.
yes that is true, but a startup is much more than just code. it's a business - with all of the extra work that entails.
This is like complaining that the industrial steel mill doesn't hire artisan blacksmiths. You can still be an artisan blacksmith these days, but more likely at a Renaissance Faire than anywhere else. But I don't blame the industrial steel mill for their hiring policy.
[deleted]
For better and for worse, it's been decades since filling out a form was a necessary or even useful part of tracking this sort of thing. The widespread use of revision control and ticketing systems means that management has that data at their fingertips whenever they want it.
Sometimes that's good, sometimes it isn't. But I think we can count relieving the developers of the drudgery of form-filling as an unalloyed good.
Sometimes that's good, sometimes it isn't. But I think we can count relieving the developers of the drudgery of form-filling as an unalloyed good.
While the article mentions form filling, that isn't the point.
The point is that there are management styles out there that tries to objectively measure a software engineer's performance (poorly). And unless you are someone with high clout in the organization, you are subjected to it regardless of whether you like it, it making sense, or it being used to control the employees (politics).
The point is that there are management styles out there that tries to objectively measure a software engineer's performance (poorly). And unless you are someone with high clout in the organization, you are subjected to it regardless of whether you like it, it making sense, or it being used to control the employees (politics).
AWS has 136,000 employees. Of course they're mired in management and processes.
Simply work for a smaller company..
Simply work for a smaller company..
And now you understand why programmers need to be part of a Trade Union.
Protection from retaliation and group negotiation on working conditions are brilliant for people who aren't as "important" as Bill.
Protection from retaliation and group negotiation on working conditions are brilliant for people who aren't as "important" as Bill.
Unions have their own politics. The good ones will do this. The bad ones will make your life a living hell for causing trouble. Whether it's worth it to unionize will be situational.
And the probability of creating a Macintosh in a union shop is zero.
Abusive boss, normalized unpaid overtime, compensation based heavily on stock options, pay and promotions being based on merit and not on seniority and time spent in a company.
Abusive boss, normalized unpaid overtime, compensation based heavily on stock options, pay and promotions being based on merit and not on seniority and time spent in a company.
[deleted]
The cynic in me believes managers actually don't want good metrics because then they have evidence of their bad leadership.
It’s why they love claiming “culture fit” on anyone older than them. 28 year old managers feeling threatened by 30 year old employees.
Anecdotally, I have not found much correlation between age and management style. I have had bad managers of all ages!
I have had one good manager though, and it's pretty obvious what made them great. First is they listen to what problems you have and actually help you do your best work. Secondly, they protect you from the other bad leaders at the company. Thirdly, they work too hard.
I have had one good manager though, and it's pretty obvious what made them great. First is they listen to what problems you have and actually help you do your best work. Secondly, they protect you from the other bad leaders at the company. Thirdly, they work too hard.
Work too hard?
GP probably meant to type "they too work hard", I guess?
Maybe that is a relative thing?
As in the norm is bad managers delegating everything to a fault, so a good manager by comparison works too hard?
Or maybe it is an availability thing? My personal experience is I'm much more motivated to work If my manager is highly available from early morning to late evening.
Or maybe it is an availability thing? My personal experience is I'm much more motivated to work If my manager is highly available from early morning to late evening.
[deleted]
Gave myself RSI deleting <600 LOC with vi.
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.
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.
I was giving myself RSI by deleting <12000 lines of copied comments (only misleading noise, explaining what was happening) and <4000 LOC (replaced with a 120 LOC in a single fn) when I reverted to using regex while sanitizing a badly bloated codebase.
Can feel you right there.
Can feel you right there.
> when I reverted to using regex
Begrudgingly I hope...
If you replaced 4000LoC with a regex that regex scares me...
Begrudgingly I hope...
If you replaced 4000LoC with a regex that regex scares me...
haha! I did use regex to find and delete repetitive patterns of code with slight variation that would be carried out by the aforementioned function.
I wish I could write such a monstrosity though :)
I wish I could write such a monstrosity though :)
Not much of an achievement, but I once deleted a 45k line Jest snapshot test for a React component that basically asserted that a div is rendered.
Maybe you are being sarcastic...
Or you've completely missed the point of the article/story. The point is lines of code are almost meaningless. In this story the person saved 2k lines of code by rewriting a rendering engine, and use somehow think that's less than deleting a 45 k line jest snapshot.
Or you've completely missed the point of the article/story. The point is lines of code are almost meaningless. In this story the person saved 2k lines of code by rewriting a rendering engine, and use somehow think that's less than deleting a 45 k line jest snapshot.
Sorry, if it somehow sounded that my example is somehow more than what was mentioned in the article. Absolutely not. I think that my example also very well demonstrates that lines of code (even that isn't really "code") isn't not a good way of measuring productivity etc. My example could be considered as an example of how a code review didn't "do it's job" for what might have been a newbies mistake. But I also think that code reviewers cannot be blamed for every bad piece of code that gets through (context matters).
“Not much of an achievement, but” here refers to the commenter’s action, not the one in the article
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.
That’s got “macro” written all over it.
That's a sed /d of course. Or a "Replace all in folder" in any decent code editor.
Or a sufficiently efficient "extract to method" on a decent IDE, that notices the different occurrences even with renamed variables.
Unless those lines of code were subtly edited all over the place and needed careful and subtly different replace for each occurrence, or at last review because that's what's truly evil with duplicated code. It's forks that diverged to maintain N times in your codebase.
Or a sufficiently efficient "extract to method" on a decent IDE, that notices the different occurrences even with renamed variables.
Unless those lines of code were subtly edited all over the place and needed careful and subtly different replace for each occurrence, or at last review because that's what's truly evil with duplicated code. It's forks that diverged to maintain N times in your codebase.
> Gave myself RSI deleting <600 LOC with vi.
Why? Didn't you know the shortcut `d600d`? /s
Why? Didn't you know the shortcut `d600d`? /s
[deleted]
+KLoC is a terrible KPI that optimizes for complexity, waste, and artificial job security-seeking behaviors.
It‘s Goodhart‘s law: "When a measure becomes a target, it ceases to be a good measure"
I’d interperet the cease qualifier in goodhart’s law to require the measure to be good in the first place, but I think SLOC is a negative indicator regardless of whether it’s a target
I think there are parallels between Deutsch’s ideas about explanation and the concept of coincident vs inherent complexity
I think there are parallels between Deutsch’s ideas about explanation and the concept of coincident vs inherent complexity
This also goes for Goodhart's law itself
This is indeed funny, but the 'tribune' role of finding bad law/process and advocating for its removal is missing from most government, corporate or otherwise, and that's bad.
It is in fact the same phenomenon as treating +SLOC as a proxy for productivity. When everyone is rewarded for adding process, but it isn't anyone's job to remove it, a system inevitably ends up with too much process.
It is in fact the same phenomenon as treating +SLOC as a proxy for productivity. When everyone is rewarded for adding process, but it isn't anyone's job to remove it, a system inevitably ends up with too much process.
[deleted]
Lines of code is a bad measure even if it's not a target.
It's obvious today to everyone, unfortunately we replaced that by KPI that are no better.
But they ARE a KPI that is easy to understand and measure.
they are not a KPI in the first place. loc is not a performance index of any kind.
Edited: wrong parent
KPI stands for “Key Performance Indicator”. Lines of code are clearly not this; they don’t indicate anything about performance one way or another.
(Now, mind you, I’m sure that lots of other ‘KPIs’ are nothing of the sort, either.)
(Now, mind you, I’m sure that lots of other ‘KPIs’ are nothing of the sort, either.)
For you, maybe; but to your parentposter's point, it is measured not because it is useful to the overall org, but because it is easy to measure. In that sense, it's a great KPI, when the measurer (presumably some middle management) considers it an indicator of performance.
It's just that you and they define "performance" differently. It's perverse incentives all the way down (or, perhaps, up).
It's just that you and they define "performance" differently. It's perverse incentives all the way down (or, perhaps, up).
I mean, sure, if you have a sufficiently bonkers view on performance metrics, then, say, index finger diameter could be a performance metric, but in terms of things which could actually be seen by any reasonable person as a KPI, lines of code ain’t one.
> any reasonable person as a KPI
Have you MET middle managers in the wild? As I said, most of these metrics are measured because they are easy, not because they are useful. The incentives at that level are to come up with some sort of metric and browbeat people into making it; the incentives for the browbeaten are then to make the number. Doesn't matter what the number means.
Have you MET middle managers in the wild? As I said, most of these metrics are measured because they are easy, not because they are useful. The incentives at that level are to come up with some sort of metric and browbeat people into making it; the incentives for the browbeaten are then to make the number. Doesn't matter what the number means.
How can it be a KPI if it doesn’t measure performance?
If you type faster you get more LOC. If you slack off all day you get zero.
It does measure something, not necessary something useful but zero LOC indicates trouble.
It does measure something, not necessary something useful but zero LOC indicates trouble.
That's such a limited view which creates terrible incentives.
If you work insanely hard solving a problem, you often end up with 0 loc + an incredible amount of understanding. If you slack off all day then spend an hour writing a bunch of sloppy code, you have way more loc than someone who worked all day to refine some simple clear performant code (which is then read 500 times before it's changed, hence the time is earned back with interest).
These scenarios don't have to happen for the disincentive to still affect the work people do; there's a continuous problem from the baseline to these extremes.
If you work insanely hard solving a problem, you often end up with 0 loc + an incredible amount of understanding. If you slack off all day then spend an hour writing a bunch of sloppy code, you have way more loc than someone who worked all day to refine some simple clear performant code (which is then read 500 times before it's changed, hence the time is earned back with interest).
These scenarios don't have to happen for the disincentive to still affect the work people do; there's a continuous problem from the baseline to these extremes.
> zero LOC indicates trouble.
It may indicate an employee with nothing to do, but in that situation would you prefer the employee did nothing, or started destroying the code base by adding KLOC of garbage to keep their manager happy and unsuspecting ?
It may indicate an employee with nothing to do, but in that situation would you prefer the employee did nothing, or started destroying the code base by adding KLOC of garbage to keep their manager happy and unsuspecting ?
I'm on day two of an analysis, zero code written. I don't know what, if anything, needs written. If I had to pound out something to keep from being zero it would be fraud.
The Platonic ideal of the perfect manager is still going to want to know what's going on when a report isn't checking in commits. I vigorously agree that software quality requires that developers be free to take time to analyze, plan, or just think things through, but zero code days can also indicate a blocker or a performance issue, and a manager should be helping with those.
The most valuable work I ever did, at least in monetary terms, involved zero lines of code (or certainly mergeable lines of code) for significant amounts of time while I figured out if the thing was possible, desirable, tested it, advocated for it… My manager was fine with this.
I’ve got to admit, I found this kind of _frustrating_ at the time, but if I’d insisted on writing something, anything, from the get-go, it would have been a complete disaster, and no-one would have thanked me for it.
I’ve got to admit, I found this kind of _frustrating_ at the time, but if I’d insisted on writing something, anything, from the get-go, it would have been a complete disaster, and no-one would have thanked me for it.
the platonic ideal of a perfect manager grows a culture where if people have issues with other developers, or the organization, or is just stuck, they naturally reach out to other people. I fail to understand this model where 'blockers' are some kind of hidden disease that a manger needs to actively ferret out. in fact, in healthy organizations I've worked in..the whole notion of a blocker doesn't really exist. its more like 'I talked to this person and we decided that they should merge an earlier version of their work, because otherwise I'm not going to be able to start for another 3 weeks and that totally blows our schedule'
and that ideal manager has a much better and multidimensional idea of performance over time than commit rate.
the platonic ideal of manager isn't some kind of school marm whose primary concern is figuring out when people are slacking off
and that ideal manager has a much better and multidimensional idea of performance over time than commit rate.
the platonic ideal of manager isn't some kind of school marm whose primary concern is figuring out when people are slacking off
> the platonic ideal of a perfect manager grows a culture where if people have issues with other developers, or the organization, or is just stuck, they naturally reach out to other people.
Agreed, and this includes managers reaching out to their reports.
> I fail to understand this model where 'blockers' are some kind of hidden disease that a manger needs to actively ferret out.
You're imputing an attitude to me which I neither hold nor intended to convey.
> in healthy organizations I've worked in..the whole notion of a blocker doesn't really exist.
Weird. The idea that a step in a process can't be completed before another step seems bedrock to me. It's always good to eliminate these dependencies when one can, but that isn't always possible.
> the platonic ideal of manager isn't some kind of school marm whose primary concern is figuring out when people are slacking off
Considering that should be obvious, since an ideal doesn't have negative qualities, I'm forced to conclude you're responding to a bunch of things I didn't say.
Agreed, and this includes managers reaching out to their reports.
> I fail to understand this model where 'blockers' are some kind of hidden disease that a manger needs to actively ferret out.
You're imputing an attitude to me which I neither hold nor intended to convey.
> in healthy organizations I've worked in..the whole notion of a blocker doesn't really exist.
Weird. The idea that a step in a process can't be completed before another step seems bedrock to me. It's always good to eliminate these dependencies when one can, but that isn't always possible.
> the platonic ideal of manager isn't some kind of school marm whose primary concern is figuring out when people are slacking off
Considering that should be obvious, since an ideal doesn't have negative qualities, I'm forced to conclude you're responding to a bunch of things I didn't say.
[deleted]
For all the people dismissing lines of code as a metric, I want to point out that very early on a line of code was literally a CPU instruction. While there was certainly something to be said for efficiency of your subroutine, lines of code was not a totally unreasonable measurement of things that your program was doing. Obviously we get removed from that the more we abstract and well constructed code is different from lines of code, but I can see where they were coming from.
One of those CPU instructions (or one class of them anyway) is called a jump. It allows you to move to a different instruction than the next one, including going backwards. There has always been reusability of already written code in digital computers. LOC was no more or less meaningful when code was written in assembly or machine language than it is today.
It only measures something loosely correlated with progress toward completion and only if you know what done looks like.
It only measures something loosely correlated with progress toward completion and only if you know what done looks like.
[deleted]
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.
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.
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.
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.
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.
All you have to do is read commit messages.
Reading commit messages is a poor substitute for reading code.
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.
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
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
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.
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.
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.
- 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.
> 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.
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.
All you're doing is affirming the antecedent.
> 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.
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.
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.
> 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.
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.
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.
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.
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.
A manager looking at the individual LOC contributions is looking into the wrong direction.
Do you really expect most managers, if any, would do this?
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.
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.
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.
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.
> 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.
This is bad, but it’s not the worst type of engineer. The worst engineers often have huge deltas and can kill companies singlehandedly.
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.
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.
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.
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)
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)
> 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.
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.
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.
This is exactly why KLoC is not a good measurement. If you know about this, you will make sure you match everyone else by embellishing your line count with comments, copy and rename functions or extra deep nesting. The manager will still not know anything without looking at everyones code.
A good manager should look at everyone's code.
A good manager should recognize that if a developer does nothing but annotate code with comments, and that's not what they're expected to be doing, there's a problem.
A good manager should recognize that if a developer does nothing but annotate code with comments, and that's not what they're expected to be doing, there's a problem.
Ofcourse, but if the manager is using the KLoC to decide who to look at, that won't happen.
Might that hint that the problem that is there is that the metric is bad?
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?
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.
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.
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.
I mean, seems highly role-dependent. If, in practice, your role is to investigate and fix very difficult problems, that’s precisely the sort of commit history one might expect.
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.
I guess I should be grateful for having a workplace that has sufficient understanding for the effort it takes to debug such issues.
Yes, but I'm guessing your commit history over the last year is not just 1/2-liners once a month, right?
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.
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.
confirmation bias indeed works that way more often than not: it confirms what you already believe
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?
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?
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)
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?”?
> Why have they reported at every standup the last six months
Every what?
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.
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.
Cargo-culting someone else's process is a bad way to develop good process for your specific team and its needs.
You could use the same logic to claim that "issues and PRs are not useful" because the Linux devs use a mailing list and patches. I think that's obviously absurd, all that this example shows is that a mailing list and patches can be a useful way to develop programs. It says nothing about alternatives at all.
You could use the same logic to claim that "issues and PRs are not useful" because the Linux devs use a mailing list and patches. I think that's obviously absurd, all that this example shows is that a mailing list and patches can be a useful way to develop programs. It says nothing about alternatives at all.
What specific needs are met by daily status updates? Professionals outside of software don't do that. The best software projects don't do that. It's very popular in CRUD projects led by non-technical middle management with trust issues.
> What specific needs are met by daily status updates?
You are assuming (1) that standups are status updates, and (2) that they are scheduled by manager, and (3) for benefit of the manager.
In the last several teams I’ve managed, it’s the crew that has encouraged meeting daily, and in the standups they are mainly talking to each other. It’s where they cover hot topics and bugs for the day quickly, with the fluidity of spoken conversation instead of Slack, and also there’s a non-zero amount of friendly casual conversation.
Don’t force teams to have standups, but also don’t assume a team won’t like it.
You are assuming (1) that standups are status updates, and (2) that they are scheduled by manager, and (3) for benefit of the manager.
In the last several teams I’ve managed, it’s the crew that has encouraged meeting daily, and in the standups they are mainly talking to each other. It’s where they cover hot topics and bugs for the day quickly, with the fluidity of spoken conversation instead of Slack, and also there’s a non-zero amount of friendly casual conversation.
Don’t force teams to have standups, but also don’t assume a team won’t like it.
They just recommended cross-checking status updates in "stand up" meetings with commit history to catch engineers underperforming. That is (1) (2) and (3).
A manager has a duty to "catch" (as you put it) underperformers, to help them improve.
If you ever move to management, you'll see that as lovely as it would be if every hands-on developer was an amazing and super-productive engineer writing high-quality code and delivering tons of value , the reality is that most teams have one or more people that are struggling and aren't getting much done, but aren't forthcoming about it. They'll represent their work as very challenging (which it is, to them), meanwhile others on the team are objectively better and faster at figuring out solutions and not getting stuck, and they understand the codebase better, and the architecture, and so on. The manager has a duty to spot when this is happening, and engage with the engineer immediately to figure out what's going on and try to help them.
Engineer managers should themselves be strong engineers (and in every company I've worked at, this has been the case up the senior leadership chain), so that they can form a realistic, fair, and reasonable assessment of whether there's a discrepancy between how an engineer represents their work, versus what is shown in the actual commit history.
If you ever move to management, you'll see that as lovely as it would be if every hands-on developer was an amazing and super-productive engineer writing high-quality code and delivering tons of value , the reality is that most teams have one or more people that are struggling and aren't getting much done, but aren't forthcoming about it. They'll represent their work as very challenging (which it is, to them), meanwhile others on the team are objectively better and faster at figuring out solutions and not getting stuck, and they understand the codebase better, and the architecture, and so on. The manager has a duty to spot when this is happening, and engage with the engineer immediately to figure out what's going on and try to help them.
Engineer managers should themselves be strong engineers (and in every company I've worked at, this has been the case up the senior leadership chain), so that they can form a realistic, fair, and reasonable assessment of whether there's a discrepancy between how an engineer represents their work, versus what is shown in the actual commit history.
The engineer did not choose to represent themselves in weird daily show-and-tell meetings. The commit history is there regardless. You could just look at that.
> Professionals outside of software don't do that.
How do you know this? Have you done an exhaustive search?
For one example, are you quite certain that no part of any military ever does this?
What about every factory?
How do you know this? Have you done an exhaustive search?
For one example, are you quite certain that no part of any military ever does this?
What about every factory?
You are not answering my question. No, you ask your acquaintances who work in law, finance or medicine. Neither does academia have any "stand up". What specific needs do CRUD software projects have that are met by infantilizing daily status reports? What needs for daily status reports do these projects have that the Linux kernel doesn't?
> Professionals outside of software don't do that.
What, and I mean this in the nicest way possible, the everliving fuck are you talking about?
Professionals do this constantly. Go sit in an ER and watch the hand off between shifts. Go see any serious manufacturing facility and see them review daily everything that happened the previous day. Go see an effective sales org in action.
The scrumbags may have ruined software, but that certainly isn’t the world.
You make your not entirely unreasonable points sound like the output of a zealot.
What, and I mean this in the nicest way possible, the everliving fuck are you talking about?
Professionals do this constantly. Go sit in an ER and watch the hand off between shifts. Go see any serious manufacturing facility and see them review daily everything that happened the previous day. Go see an effective sales org in action.
The scrumbags may have ruined software, but that certainly isn’t the world.
You make your not entirely unreasonable points sound like the output of a zealot.
"Stand up" meetings are not hand offs in the ER. Continuous integration with automated testing is.
Why are there no laymen agile coaches at law firms, and no "today I did this, today I did that" breakfast meetings in finance, or in CS academia? Other professionals don't accept this kind of infantilization.
Why are there no laymen agile coaches at law firms, and no "today I did this, today I did that" breakfast meetings in finance, or in CS academia? Other professionals don't accept this kind of infantilization.
You speak in absolutes. What works for me, works for me :)
Standup. Daily meetings where teams talk about their blockers and so forth.
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.
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.
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.
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.
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.
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.
>In the PBS TV series based on Bob Cringely's Accidental Empires, there is a sequence where Steve Ballmer describes the experience of co-developing OS/2 with IBM, how the whole thing became a fantastic clash of corporate culture, with Microsoft having the small-company attitude of getting things done, and IBM being focused on internal measures primarily KLoCs, that is thousands of lines of code as a measure of programmer productivity. "All they cared about," raves Ballmer, "was KLoCs and KLoCs and KLoCs." IBM, apparently, did not care whether the code was any good as long as there was a lot of it.
https://ubiquity.acm.org/article.cfm?id=1022357