Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

LoC isn't a perfect metric by any means, but it's also not a completely irrelevant metric as people always keep claiming. Especially if you showed up at a new company and had to fire 50% of the staff with zero context. There are too many tenured employees at Twitter, Google, Facebook and everywhere else who stopped writing code a long time ago and spend their time trying to seem as busy and important as they can while doing basically nothing. Firing based on LoC will definitely get rid of a few great engineers, but it will also correctly identify the 40% useless engineers.


> Firing based on LoC will definitely get rid of a few great engineers

The average front end developer probably writes 10x the LOC of the best backend developers, so it may actually get rid of the majority of your best engineers.


Or you can segment people into relevant groups and judge them within those groups?


Juniors produce more code then seniors. Easy tasks produce more code then hard tasks. And the distribution of tasks is not random either, some people do more of easy ones others hard ones.


Judge seniors as seniors, and juniors as juniors. You say that juniors are probably writing a ton of code.. well some of them aren't doing that. Some of the juniors are slackers who are coasting on their social skills and office rapport. Looking at LOC changed can help you identify these people. Confront them with this data and give them the opportunity to explain themselves. Some of them may have good excuses for why they don't have much code but have certainly been working hard. Many of them won't.

Or should we pretend that everybody at twitter is a hard and honest worker?


> Or should we pretend that everybody at twitter is a hard and honest worker?

Much like how we are asked to assume the best of posts here on HN, and presume innocence of those on trial for crimes, yes, that seems like a good place to start from.


Assuming that any particular worker is competent until proven otherwise is fair. Assuming that all workers are competent is just naive. You may as well assume there are no bike thieves in NYC.


We're discussing 50-75% layoffs - terminating the employment between 3,500 and 5,250 software engineers... people. I feel it's completely fair to assume that a vast majority of them are competent.

Just as I assume that a vast majority of people on bicycles in NYC aren't thieves.


I did not said probably. I said, Juniors systematically as a rule produce more code.

And even in that bracket, I will give harder tasks to more capable junior ... leading to them producing less code. I will also help less to more capable junior and help more to weaker one - leading to more capable junior spending more time figuring stuff independently. That is super useful for team productivity (he is not hogging senior).

Seniors have also huge differences due to doing different tasks. A go to guy for stuck out issues produces less code then someone on greenfield module. And loc has zero with productivity.

Unclear analysis and requirements are another source of low LOC. You produce less of them when you are spending a lot of time reading convoluted sentences or calling people for clarifications.

Seriously, are you all working on repetitive web shop tasks that you think loc has anything to do with productivity? Or not coding at all?


At my job juniors dev write a lot more code than needed, having 12y of experience I know how implement same things with much less code. So, from my point of view, LoC is really a stupid metric.


The point isn't to compare those who wrote 10K vs 11K lines of code, it is to compare both of them with someone who wrote no code in the last 6 months.


Top seniors at my job almost write no more code. They mentor, teach, design, troubleshoot etc. By Musk metric, they should be fired even if they basically run company systems.


By Musk metric, people who write lots of code should be in those positions.


Fire that person and their manager for not doing anything about it. Either way its still a terrible metric. I wrote shit loads of code and was still beat out by the worst member of our team because they were given oddball tasks like copy all of this code into a new area, or even worse when they accidentally force merged a different repo into another, good grief.


Typically, someone who wrote no code in 6 months was doing different position for those 6 months. Analysis, infrastructure or whatever, usually without formally changing position. That is significantly more common then imaginary coder who produces no code.


Elon: So what your saying is, junior engineers are cheaper and write more LOCs, while senior engineers are expensive and not productive. Brilliant!

Fire everyone under 10000 lines and give this fellow Autoformatbot a $10 Starbucks gift card. He’s employee of the month!

I am very smart. This will go great.


I don't think it rises even to 40%, because I think an excessively productive idiot is way harder to deal with than a person who just doesn't write enough code. Cutting based on LOC biases towards retaining excessively productive idiots.


An engineer who writes a lot of code and contributes nothing of value is an outlier.

An engineer who writes no code but contributes a lot of value is an outlier.

So yes, you will miss these two outliers if you go by LoC, but sometimes that is acceptable as long as you are handling the majority correctly.


The thing is, in my experience, the people who write a ton of LoC often need more effort to review, introduce instability, and slow down the rest of their team because their stuff needs bugfixing or is difficult to parse.


There's an easy way to validate these assumptions. Go to any repo in your company's GitHub and open the contributors section. Tell me who you'd rather fire - the 10 people on the top of the page or the 10 people at the bottom?


The 10 people in the bottom are people whose primary job is not to code. I don't actually want to fire my team leader nor the guy who often helps analysts, I actually think they do good job.


Well, it's apparently a good way to get rid of the accessibility team. Who needs those folks?


Some teams (accessibility, diversity & inclusion) were fired because Elon doesn't give a shit about those areas. That has nothing to do with lines of code.


> Especially if you showed up at a new company and had to fire 50% of the staff with zero context.

It's almost like this is the problem.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: