-2000 Lines of Code (2004)
folklore.org
folklore.org
It's just like shift times for workers in manual labor jobs. You can't tell which of the people who are meeting up 8 hours a day is most productive based on if they where there for 8 hours and 12 minutes or 8 hours and 25 minutes. But you sure as hell can easily see that if someone is showing up 4-5 hours on a nine-to-five job, then something is wrong. And if that person tries to "fake it" but showing up for 8 hours but spends half the time slacking off, but coworkers and managers will call him on the bullshit.
The idea the manager would call out individuals is laughable too. Most managers barely know how to code themselves. Give it another few decades before your manager looking through commits is a standard, you're more likely to see alert tools be prevalent before that.
You just need to create a shitload of bloated bullshit that somehow "works" (at least more or less).
That doesn't make you productive.
Actually that's even counterproductive as it creates technical debt. But by the bogus metric that would be positive.
I'm still to find the place where this is true in software development.
And when I then do actual work in between I lean towards the solution giving me more lines. Longer variable names, more line breaks, ...
There are so many ways to manipulate that, one I know it's a key metric. Sure, it's hard to go from weakest to top contributor that way, but good enough to get away from last spot who is being fired. At least till all play that game. By then the project goes towards a wall.
So yes, for a one off case to identify engineers one should talk to it is a somewhat useful metric, but I would look at more business relevant metrics like amount of closed bugs or similar first (while of course they can be manipulated easily as well ...)
Lines of code rewritten (changed N days after)
Lines of code removed
Lines of code that contributed to linting problems
Lines of code that contributed to security issues (as reported by the static analyser)
Average complexity measures
CI/CD build failure rates
Lines of code reviewed
Gitlab has plugins to generate reports like this, and if you have enough data (multi year preferably) you can use this as a springboard for deeper analysis of members of the team, I find all these metrics together (non taken as absolutes because there’s many assumptions built into each one) can give a good overview of individuals in a team
Build failure rates encourages frustration as long as you don't provide ways to run the exact tests in isolation locally, under the same rules as CI. Meanwhile, branch triggers and pre-push hooks trivialize this further.
Most of these metrics are strange given they are trivial to check pre-merge. Meanwhile, running these statistics pre-merge discourages small commits and sharing code prior to having ideal builds.
The moment this gets out is the moment devs will game your statistics and any benefit you gain goes out the door. And almost every one of these, even combined, is easy to game.
If they are important enough to measure, why not hard force them and focus on the remaining metrics instead?
And
“Use these as a springboard for deeper analysis of devs”
These are only used as high level metrics to guide further analysis, we are keenly aware of the faults of these metrics - but the alternative of no-metrics or worse, “gut feel”, is slow and riddled with more problems.
It doesn’t mean a dev is bad, maybe it means there’s some tooling failure, or organisational problem, or personal problem they need help with. These metrics give visibility into anomalies, and their imperfect nature doesn’t mean they are useless.
There’s also like 20 more metrics but I’m on my phone and couldn’t recall them all right now
Also I don’t know where all of this nonsense about “forcing” to run CI/CD before branch merges and “slap on the wrist” - all our devs can run the test suites locally in docker and inside their IDE, nobody is forced to do anything in the pipeline severs, and also nobody gets a slap on the wrist for CI/CD failures, actually I like to see larger changes with more failures because it means the dev is trying and I consider this normal behaviour, your incorrect assumptions about our test environment and how we interpret these metrics sound like you’re projecting.
i.e. you are not a competent manager by the usual understanding of «competent».
The metrics actually showed no surprises when I saw them, had I been asked to name the worst 5 devs, I would have named the same people that the metrics would have highlighted.
I raised this suggestion with management, but since we had a handful of devs who were drastically underperforming we decided to help them out first with increased mentorship, in order not to embarrass them in front of their colleagues.
I don’t know why you’re assuming the worst and malicious intent, it’s a great place to work, especially when we have a good vibe and all enjoy working together.
I think what contributes to this positive environment is not employing developers who instantly assume malicious intent, and aren’t paranoid about being discovered as incompetent. These people are usually the ones most opposed to metrics, and also are the ones who the metrics show are the worst performers. Instead of objectively assessing the facts they attack the messenger, full of emotion and vitriol because of their insecurities and inabilities.
There are many factors that go into firing a dev, if someone needs help we mentor them and grow them, but if someone has a bad attitude, assumes the worst and is full of negativity, then we are very quick to fire them.
Maybe your company is still a great place to work in spite of that. Or maybe it's only a great place for you to work, and your colleagues would feel differently if they knew about this. I can't say for sure because I don't have any further insight into your company. But that's also not the point about why it's unethical.
Nor is it having a 'bad attitude', assuming the worst, or being full of negativity to be opposed to the secret use of metrics in this way.
I see the metrics as a chance to provide visibility and support, you see it as a way to “manage” the devs. I see a chance to help, you see tyranny.
I see my viewing of my own metrics as a chance to introspect with an open mind and a willingness to see fault in myself and improve, you see an abuse of authority and a land grab to get ahead.
Then you say “I’m not assuming the worst, or full of negativity” when clearly you are, you just demonstrated it.
So like you, let me fall back on the ethics argument:
I think it’s unethical for a software manger not to take machine collected metrics and to manage on “gut feel” and intuition, just as all gut feel and intuition are not explained as rationale to all decision making (thus are also “secret metrics” - i.e. collected without transparent knowledge of all reasoning)
I think it’s unethical not to have secret metrics and inform every person of every thought and data point you have, so there aren’t any secret measures. (You better call your bank, your insurance company and loan companies and marketing companies who are all collecting secret metrics on you, in the sense their rationale, data points, and algorithms are not 100% open and are therefore secret)
I think it’s unethical to distribute reports that might demoralise some devs without helping them out first, especially if we know some of these reports might look unfair, and we are only using them as springboards for further investigation, like I have mentioned many times in this thread.
I think it’s unethical to complain about ethics and not address any of the points in the above discussion with objective facts.
But ethical things are ultimately subjective, so our conversation ends there, we will have to agree to disagree.
What company are you working for? Human "resources" department, I guess?
Looks like a place to strongly avoid because of very bad ethics and culture!
Your bank is scoring you by machine, so is your insurance company, and loan companies, are their algorithms 100% open and publicly available? No. Because they are secret metrics. Your bank knows more about you than you know, and so do the loan companies, I know, I used to work there. The datasets the loan companies have are insane, I could see if you are in financial distress or not, the value of your house, whether you were a “complainer” or not, your favourite music, whether you’re a foodie or not, and heaps, heaps more, I think 250 attributes on each person in the USA at one company.
What difference does it make if some metrics are collected by machine and not fuzzy, vague, human intuition? I think it’s an improvement.
Yes the metrics inform the seniors decisions partially like I said above, and yes they are taken with a grain of salt, like I said above, they are inputs for deeper investigation, that’s it.
Here’s an example that happened just the other day: I noticed heaps of CICD failures for one dev and I reached out to him. He told me he couldn’t easily run the test suite, so I spent an hour peer coding with him and showed him how to use VSCodes debugger.
1 day later he called me up and told me that “using the debugger was a life changer” and he was thrilled to be working so quickly, the faster feedback cycle from code->debug had restored his enthusiasm for work.
> Lines of code written
Less is better, right?
Because it's really easy to throw code at a problem.
OTOH it's hard to come up with an optimal minimal solution.
> Lines of code rewritten (changed N days after)
Means: Your devs commit unfinished, not thought out crap.
Or: Management is a failure because they change requirements all the time.
> Lines of code removed
More is better, right?
Because cleaning up your code constantly to keep it lean is key to future maintainability.
But could be also a symptom of someone with a NIH attitude.
Or, management is a failure because they don't know what they want.
> Lines of code that contributed to linting problems
If it's more than zero that's a symptom of slacking off and / or ignorance.
Your local tools should have showed you the linting problems already. Not handling them is at least outright lazy, and maybe even someone is trying to waste time by committing things that need another iteration later on.
Or, your linting rules are nonsense, and it's better to ignore them…
> Lines of code that contributed to security issues (as reported by the static analyser)
Quite similar to the previous.
Ignorance or cluelessness. Maybe even the worst of form of "I don't care", while waiting whether your crap passes CI.
In case someone doesn't know how to handle such warnings at all you have a dangerously uneducated person on the team…
Or, what is at least equally likely: Your snack-oil security scanners are trash. Producing a lot of the usual false positives (while of course not "seeing" any real issues).
> Average complexity measures
Completely useless on it's own.
Some code needs to be complex because the problem at hand is complex.
Also more or less most of this measures are nonsense. The complexity measure goes usually down when you "smear" an implementation all over the place. But most of the time it's more favorable to concentrate and encapsulate complex parts of your code. Hundred one-line methods that call each other are more complex than one method with hundred lines of code. But the usual complexity measure would love the hundred one-liners but barf at the hundred line method.
If there's someone who constantly writes "very complex" code (according to such measure done by some tool) this can mean that this person writes over-complicated code, as it could mean that this person is responsible for some complex parts of the code-base, or is consolidating and refactoring complexity that was scattered all across the place. Or maybe even something else.
> CI/CD build failure rates
This means people can't build and test their code locally…
Or someone is lazy and / or ignorant.
Or, equally possible, your CI/CD infra is shit. Or the people responsible for that are under-performers.
Or your hardware is somehow broken…
> Lines of code reviewed
How do you even measure this?
Just stamping "LGTM" everywhere quickly would let this measure look good. But is anything won by that? I guess the contrary is more likely.
Also someone who's constantly complaining about others code would look good here…
OTOH valuable and insightful code review is slow, takes a lot of time and effort but does not produces a lot of visible output. That's why I think it's disputable whether this can be measured even in a meaningful way.
There is only one valid way to asses whether someone is productive: You need to answer the question whether what this person is doing makes sense in the light of the stated goals.
But to answer this you need to look at the actual work / things produced by the person in question, and not on some straw man proxy measures. All measures can be gamed. But faking results is much harder (even still possible of course).
But not so good for comparing Joe and Mo. Or even saying “how is Joe doing”. Unless the reviewer is very skilled in navigating that data without bias. Most people I have worked for wont be and will ruin the employee relationship by making some comment about how “this could improve” when the employee things “ok this is BS but better go along with it, and maybe i’ll open CV.docx tonight and give it a spring clean”.
Bullshit is the biggest turn off for me in jobs and I will leave a job with too much (some is to be expected and a side effect of getting groups to work together). Team leaders tracking my time and commits closely to judge performance is this. How should they judge? Best way is get people to pair often. You will know what they are actually doing that way or can talk to someone who did. Any real laggers will be found naturally, and then find out why and fix (might be onboarding sux for example).
People do hate paring I know but it doesn’t have to be all the time. Even an hour a day of someone jumping on to help will spread boats loads of useful information.
- patents written / rewritten / meetings with lawyers / issued - mentoring of other engineers - PRs reviewed - talks given - meetings attended - RFCs / ADRs written - customer calls attended - quality of code (the original and best reason that LOC is bad.)
Et cetera, et cetera
If you are truly an engineering manager, unless all your direct reports are fairly junior, I sincerely hope you realize soon that LOC is a pretty terrible measure of engineer contribution.
I am old enough to remember when the industry finally came around to accepting LOC is a worthless measure of engineer productivity in the late 90s. I am not exactly shocked but dismayed that this conversation needs to be rehashed.
Number of tasks closed is a better measure than LOC and it is still a terrible measure.
Equivalent would be saying “our sales rep only said 2300 words today but that is ok, we can accept it he was visiting an old customer not cold calling like the juniors”
Usually LOC modified correlates with actual productivity but there are lots of exceptions. Like if someone copies an open-source library directly into the repo, commits a formatting change, is working on a critical section of code, is working in a different language, is writing new features while everyone else is fixing bugs, has been told they are going to be measured by LOC, etc.
The fact that you actually analyze your team members' contributions, know the codebase, and measure productivity in more ways than LOC is a good sign. The problem is when managers exclusively measure LOC to gauge productivity and make decisions. While LOC and productivity correlate more often than not, I bet you can spot at least some cases where the LOC is not an accurate measure.
Maybe for junior engineers and that’s it. I want my seniors and leads mentoring, doing code reviews, designing, communicating with the business about impact and the like, training, and yes, coding, but not as much as juniors.
Those seniors that maintain their output are only able to do that as long as they maintain their knowledge of the codebase. As soon as you lose control your output goes from 10x to 0.1x in the blink of an eye. At that point your options are to look like a fucking idiot because your juniors are out-doing you, or to optimise for blowing smoke up the manager's ass. Easiest way to do that is large sweeping rubbish architectural changes that look good on paper.
Some people will take a stand, but most just play the cards they're dealt. Every great engineer I know has had both 0.1x projects and 20-50x projects. Knowing why that's the case is more important for a senior/lead dev than coding ability IMO. Get the best out of others and all that...
As I’ve become more senior, I’ve found ways to push back on product requirements that add little value for the users, but tons of complexity in the code. If I don’t follow the requirements exactly, I can usually write ~10% of the code. But you need to learn how to do that with lots of experience.
It takes the same amount of time, because I need to dive in deeper to understand the problem and how it interacts with my features, lots of planning and meetings to change the scope, but the final output might only be 5-10% as much code if we can reuse things that already exist in the codebase.
—
For example, product team wanted something to be bold that we had set up to be within dynamic plaintext. It would’ve taken a rewrite of that entire UI component to be able to make some bits of text dynamically bold. But I was able to push back and say “what if we just rearrange it slightly so that the bold is unnecessary”, and the designers+business were ok with that too!
If I hadn’t pushed back, my more junior teammate would’ve written 2k+ lines of code to support that requirement. But instead it was probably like 10 lines to support the alternative formatting. That 10 lines took lots of time to understand the requirements, but was much better for code cleanliness and consistency in the end.
The team _will_ find out, and then instead of contributing to the success of the business in earnest, they’ll be doing stupid things like maximizing their changesets or racing for “easy” large changes like deleting a module.
It doesn’t matter whether those values do or do not correlate with reality (IMO, if they do, it is for relatively junior engineers only). If you give off the smell of measuring people like that, you will ruin any collaborative team environment and you risk never being able to recover that.
There’s a good chance you’ll chase away excellent engineers with this sort of low-effort metrics management too.
There are exceptions, but these are extremely rare.
Look for code created in collaboration by multiple engineers, with contributors or reviewers across multiple teams. This code is more likely to be an asset.
(Unless created by Google for external use or by xOoglers. Such code outside Google is a near guaranteed liability.)
Contrary to some other comments, I'd argue it's the people who ship lots of value, but very little code, who are rare to find in practice.
Looking for healthy collaboration is the key, this is where the magic usually happens. Counting lines of code is a poor proxy for this.
A single opinionated developer laying the foundation and core architecture is important for getting a coherent developer experience.
The other outcome if that developer is a good leader and interested in developing a community is that a community builds around the core foundation that was laid and begins to take a life of its own.
Look at React. Started by a single opinionated developer who laid the foundations and built a prototype. From there it's taken on a life of its own and evolved. It was not designed/built by committee from day 1.
Or python for that matter.
Counting them alone won't, but incentivizing people based on changesets will. IMO there are plenty of cases where counting LOC is useful to a manager. It's a discrete piece of data than can be combined with other data to make informed decisions as a manager.
Another major confounder is that super deep investigations that fix major problems often have relatively trivial solutions at the end. But the effort to debug and fix them (that is largely hidden by conventional metrics) is enormous. The people working on these types of things are often your best devs (because you know they will actually get to the root cause), but if you are only looking at LOC you wouldn't know that.
For example, I have just written a Snowflake stored procedure that auto generates SQL code and then executes it. I am going to call this stored procedure from multiple places in my Python codebase. Now if my manager would look at the number of lines of code I would still write the stored procedure, however, rather than auto executing the SQL code, I would just copy and paste the auto generated code into my Python codebase increasing my LOC for that week.
Not everyone panders exclusively to optimizing grading metrics. I wouldn’t do that even if my manager looked at lines of code because I care about the quality of my work. I’m confident a lot of people share my sentiment.
If you are trying to use lines of code to measure productivity, the only reason is because you think some members of the team are not being productive. Sure, the good and productive team members won’t try to game the metrics… but the bad programmers, who you are trying to find, sure will.
The good programmers won’t game the system, but that doesn’t matter because they are going to be fine no matter how they are evaluated. So what is the point of measuring lines of code? You aren’t gaining any new information.
Bottom 10% get fired each year. What about now?
As others point out though, the moment something becomes a metric it ceases to be useful. Check out the book "The Tyranny of Metrics" for a breakdown of it.
Depends what you mean by "productive". If you mean "appear to be busy" then yes. But by using this metric you disadvantage people who measure twice before cutting once, people who think deeply about a problem and find a simpler way to solve things.
In my experience, more junior people tend to spin their wheels a lot, and out of that spinning comes out a lot of code. Code that is often broken and then is is fixed again, and again. And such people appear to be more productive and busier, at a first glance.
People will retort: "But, but, but... what about pushing junk?" Well, if you've decent code review system how will that get merged? Pushing junk is often a less of a problem provided you've a good engineering culture. The best teams I worked with were just plain fast. The worst ones had plenty of engineers hiding behind meetings, reviews, and bike-shedding.
[1]: https://medium.datadriveninvestor.com/when-overachievers-sel...
Most good writers will tell you that shorter is almost always better. You want to express your thoughts in the most succinct way possible. Review your own writing to remove as much as you can, then hand your draft off to an editor who'll try to cut even more.
And yet, many writers are still paid by the word, and many book contracts still specify target page counts. Because even though shorter is better, the shortest possible length of a given text still serves as a rough measure of that text's breath and complexity.
Is code any different?
Yes, paying or evaluating programmers by lines of code is going to lead to misaligned incentives. However, I'm not convinced the dynamic is any worse than for prose. Bill Atkinson spent a week removing extraneous code from QuickDraw; an author might spend a week cutting extraneous subplots from a novel. Word count is still a useful metric for the author.
Perhaps the difference is that non-writers tend to be more familiar with the writing process than non-programmers are with coding. If an author was working on revising a novel, no one would ask them how many words they'd written that week.
Or maybe word count measurements are in fact making everyone's prose worse and we should do away with them too.
That's where your example of writers should take hold too: good writers stop being paid by the word and start being paid by number of sales. The same should be done with devs.
That said, the entire thing gets tossed out of the window when considering significant portions of developers will overthink abstractions, fiercely hold onto overabstractions (which end up bloating LoC), have discussions with each other ad nauseam, slow down code reviews over petty differences, and more.
If
But when spread out it's nice.
That doesn't really mean anything, after all some managers still judge productivity by LoC. They both can be bad.
And at least IMO, using word counts for books is giving very wrong incentives. I've stopped reading non-fiction books because absolutely every single one i've tried to read over the years always *ALWAYS* gets way too wordy, spending entire chapters in what one could fit in a blog post. And i'm writing that as someone who also tends to err on the "wordy" side - both when writing and when reading (i.e. when in doubt, i think it is better to write more). But books tend to overdo it to fill those contract pagecounts.
However, I'd posit that if you went into a forum of professional writers and asked how they felt about word count measurements, they'd be a lot more divided than we are regarding lines of code. Or, to pick another example, NaNoWriMo seems to be pretty popular among aspiring authors, and that's all about the wordcount. Maybe it shouldn't be—or maybe there's something we're missing.
For example: it may be the case that lines of code is a useful goal during certain phases of a project—maybe while prototyping, for example. Just like how a target word count is useful when writing a rough draft, but obviously stupid while revising a draft.
Although, an author might set a goal to get below a certain word count during the revision phase—and that again might be a useful target for programmers refactoring code.
However, people don’t buy programs like that. If Madden 2023 has 10x as many LOC as Madden 2022 the price doesn’t change.
Online daily newsletters are designed to take so many minutes to read, which is calculated directly from the word count. So word counts often have utility.
Coding sometimes has space and memory constraints but often it works best to optimize for maintainable code, which might be shorter or longer depending on the case.
The ex-NeXT management who took over from them never asked for LOC.
It's good because I need few shell commands to measure it.
Goodhart’s Law: when a measure becomes a target, it cease to be a good measure.
It also doesn't tell you how much effort should have gone into a software system. Spend six months writing your own message queue? 16384 lines of code. Spend two weeks wiring up your system to RabbitMQ? 1024 lines of code.
Not always. LibreSSL is probably smaller than some applications but much denser with complicated code than a simple system with lots of CRUD screens.
But it’s an easy to grasp metric. It’s also quite easy to figure out. It’s automated and doesn’t require weeks of study by specialists.
But as we all know, using it to manage productivity of individuals or teams can be heavily misleading.
Also, though, I don't think that needing only 1024 lines of code to wire your system into RabbitMQ is any kind of indictment of the quality of RabbitMQ or of the code being wired into it. It would be even less of an indictment if it was only 128 lines or 16 lines or 1 line. But sometimes you need to grok a whole new paradigm; if you've never worked with AMQP before, you probably aren't going to be able to write those 16 lines in half an hour.
Similar comments apply to other domains with well-developed libraries for them. OpenCV, BLAS, regular expressions, LALR parsers, SQL databases, GNU MathProg, and so on: if you haven't worked with them before, it's probably going to take you a while to learn enough about them to apply them to your problem, and then you're going to produce an extremely small amount of code to actually use them. But that doesn't mean your time learning about them was wasted; quite the contrary.
4 pages? No problem.
What I remember reading on Twitter at the time, was that devs were expected to print out about fifty pages of diffs relevant to the last six months of their work. Rather than printing out all changes from the last month.
The printout part makes me question the idea that code was being counted. That part is easy to do with tools which Twitter undoubtedly has.
I've never worked a job where I couldn't print out 50 pages of diffs for six months, although I have the sort of temperament where I'd probably sandbag or quit if asked to.
There's little point in speculating on this until a clear picture emerges. I can't imagine a winnowing process for a new takeover that didn't involve some kind of portfolio justifying the worker's salary. Not at Twitter, which was notoriously overstaffed and had a reputation for rest-and-vest.
I'm not aware of any such reporting, just rumours.
But it seems obvious that since they scrapped together this list in just a single week, they can't have done anything much more complex than use some simple metrics.
-2000 Lines of Code - https://news.ycombinator.com/item?id=26387179 - March 2021 (256 comments)
-2000 Lines of Code - https://news.ycombinator.com/item?id=10734815 - Dec 2015 (131 comments)
-2000 lines of code - https://news.ycombinator.com/item?id=7516671 - April 2014 (139 comments)
-2000 Lines Of Code - https://news.ycombinator.com/item?id=4040082 - May 2012 (34 comments)
-2000 lines of code - https://news.ycombinator.com/item?id=1545452 - July 2010 (50 comments)
-2000 Lines Of Code - https://news.ycombinator.com/item?id=1114223 - Feb 2010 (39 comments)
-2000 Lines Of Code (metrics == bad) (1982) - https://news.ycombinator.com/item?id=1069066 - Jan 2010 (2 comments)
Do we actually know that? People were asked to print their code, and a mass layoff happened. But AFAIK, what feature of the code was judged (if any) is kept as a secret.
Reposts are fine after a year or so (this is in the FAQ: https://news.ycombinator.com/newsfaq.html) and for classics and perennials, occasional reposts are important so more recent cohorts of users can get to know the culture (https://news.ycombinator.com/item?id=32405060).
LOC is obviously very flawed, but to be completely honest it has been useful as part of a heuristic for figuring out where something has gone wrong in a department (after applying basic heuristics like removing packaged code, vendored stuff, etc.)
For example, if engineers are constantly committing and then deleting huge amounts of code (somewhat like this example) then it’s good to dive in and make sure you don’t have some issues creating that situation. This can range from product managers who aren’t validating their requests before engineers start working on them, to interpersonal issues such as unqualified juniors writing large amounts of buggy code and leaving it for senior engineers to fix.
These metrics can also be warning signs that something has gone wrong. If an engineer’s number of commits have plummeted and LOC committed has gone way down, it’s a sign that you should ask more deeply how their work is going. I’ve had situations where programmers were being pulled into 20+ hours of meetings each week and being given weird research assignments from random C-level executives that took away all of their coding time. I’ve also had situations where people weren’t getting along with each other in private and DMs, and the first warning sign was that their contributions stalled.
So while LOC and commit metrics can absolutely be misinterpreted in the wrong hands (e.g. as a proxy for laying off Twitter employees without trying to understand the context of their work) I’ve actually found them to be helpful as one of several early warning systems that something is going wrong with a team or project. Work with people for a while and it’s not hard to recognize their normal output and when it has stalled for unexpected reasons. Use that as a signal to start a conversation about how they’re doing.
This story, however, is not a story of someone who deleted 2k lines of code.
It's story of someone who wrote, let's ballpark, 4k lines of code and then rewrote them, which resulted in 2k lines of code left. Not sure how to account for that but let's say it's 5k lines of new code written in total which ended up as 2k loc.
This story does not prove that you are a great programmer if you write little code. It actually shows that even the best of the best (like Bill Atkinson) write a lot of code and cannot arrive at the ideal code at the first try. Writing the first 4k loc was a necessary step to gain knowledge that enabled him to refactor the code down to 2k loc.
Negative LOC is not uncommon in maintenance work; things become obsolete or better solutions are invented.
The guy who started the project came from an enterprise Java background, and his code was the stereotypical design pattern pileup. I only jumped in because he was having trouble actually wrapping it up, and, with every commit, I deleted a bunch of code and replaced it with just a small fraction of what was there before, and he reviewed the changes and agreed they were an improvement.
Yet, even though he genuinely agreed his code was overly complicated, he never internalized the learnings, and kept repeating the same mistakes over and over again. He was fixated on the idea that his coded needed to be extensible (without a clear notion of how or why) and kept adding abstraction after abstraction for every new feature he added.
So, yes. It is uncontestably true that you often need to write 4k LOC before you understand how to write the same thing in 2k LOC. But it's also very much the case that there's a baseline of skill you need to write those 4k LOC instead of a 10k monstrosity.
Sad to say, usually the only way this lesson can be learned is through being fired. And not always then, but at least it is no longer your problem after.
He watched C++ YouTube videos by experts and preached practices to us all - some of which were genuinely good ideas - but he lacked the judgment of when to apply what. He made massive changes without seeking team consensus, never accepted feedback, and totally lacked the desire for concise code that seems natural to most good developers.
Sadly his manager was enamored with him and kept him around far longer than we should have. I still run across his code to this day, overcomplicating and getting in the way of needed refactoring.
Cleaning up his code has given me a couple of -2000 LOC days...
Of course you can’t determine the best person by lines of code (package.lock files lol) but you can often make a guess at the worst person
I use the loops one more often in discussing development.
Of course, loc is a bad goal for productivity, but it can still be an interesting measure (similar to test coverage): If I count lines of code added, commits, or tickets closed, I cannot compare any two developers. But if I count that metric for the same developer, or the same team, I can certainly spot changes in productivity. (As every metric has its outliers it would probably be. best to combine all of them.)
So if I was managing a team and wanted to know if it would be beneficial to optimize test execution times, I could just rent some bigger machines and see what happens. I could also do a similar experiment with organizational aspects like the size and schedule of meetings or the introduction of a dedicated on-call contact for support requests, etc.
As a senior technologist who bills his time as a consultant, I can tell you that I (correctly) get paid the most for days where I write 0 lines of code.
But also, my most valuable code was code where I spent a week thinking and writing maybe 5 lines of code a day, and my least valuable code was when my output was limited by my typing speed.
Thoughts? I think the biggest counterargument is that it incentivizes churn like making a commit and then reverting it later.
Besides, you might as well start counting closed number of issues/tasks/tickets, story points or whatever, and skip the commit count altogether.
You could then go with features only tickets but those vary in size and complexity. Now, if we would put complexity as a measure (on which the team of developers should agree) and then measure the number of issues on that implementation we might get a better measure of that person's contribution.
That said, once that would be in place, even that can be gamed.
I think there is no silver bullet here, as much as we would like it to exist.
If your engineers truly aren't getting shit done, you should be able to tell without looking at their code.
We don't get paid to write code. We get paid to _think_; it's just that if we don't write code afterwards, we get fired.
Therefore, a language that allows a programmer to turn thoughts into correct code faster is a win.
The size of the code as writter is only slightly interesting: almost everyone can type faster than they can think clearly. A more compact notation is preferred for reducing the delay between typing and testing, but not to the point of impairing readability.
What do you do then?
Or listen to the requirements from a new system and propose an existing tool that solves 90% of them. Or explain why the library they were going to use solves a different problem and how they'll regret choosing it.
Or talk to folks and figure out why my proposed new design for a system doesn't cover all the needs of the old one (and eventually that some iteration of it _is_).
Or sketch possible algorithms for a difficult problem on a whiteboard / notepad until I figure out a good-enough solution.
Or talk to stakeholders about their needs and concerns regarding a new system I'm helping design.
Or talk to customers. Or help prepare a pitch or customer demo.
It's very rare that a customer feels it's worth paying me rate for writing code. Though it does happen, and when it does it's usually very interesting code with a very interesting story behind it.
>But if I count that metric for the same developer, or the same team, I can certainly spot changes in productivity
No you can't.
Sometimes I will be working on coding related tasks for months, and then mostly on design tasks for months. I am not more or less productive in either, but I will close a lot less tickets and write 0 lines of code when I'm doing design-related work.
Same with oncall. I probably won't write much code but I can close a hundred tickets in a week.
Metrics are just a stupid measure of an engineer's productivity.
There's been so much fake news regarding Twitter and Musk these days that I honestly can't tell anymore.
I’d be interested in evidence too.
I've seen in the news that Musk asked devs to print their code for review by Tesla engineers. Not that their LoC would be counted strictly speaking.
Now is this piece of news even true?
Where are these LOC counting managers I hear so much about?
You might be unaware that you are not such a great manager.
In general, the more code you have the more code you have to maintain and massive codebase churned out by a single engineer is more often a liability, not an asset.
There must be a point where this doesn't hold as well - new feature projects or, especially, newer projects themselves - where adding code is more correlated with value.
If you need a metric for, say, large teams, how about: # PRs x level of effort, + bonus points for being useful outside of code.
Great engineers are like a 5'10" [attractiveness redacted] [hair color redacted] [gender redacted]; it's very obvious, isnt it??
It was copypasta of a bad n² idiom for collision detection between two search criteria. So first I had to replace it all with a function, then change the function. Made the app actually usable though.
Is there a better way to gauge "churn" or risk? Cyclomatic complexity deltas?
I think what you meant was that people love learning lessons the hard and slow way instead of taking others’ word for it.
I’m sort of conflicted on this. Yes, it is faster to take an expert’s word for it. But after a couple of human generations of that, do we actually lose understanding?
I think we can only stand on the shoulders of giants standing on the shoulders of giants to some N giants until the whole acrobatic totem pole comes tumbling down. The game of telephone through the ages produces belief, not understanding.
Another option is making giants more giant, but that is an even slower process than one person learning from first principles: humanity has to find a way for our brains to learn those principles faster. Maybe that will take millions of years of evolution. Or maybe something like neuralink will provide a shortcut so it only takes thousands of years.
Either way, with such management...