Stanford Research Reveals 9.5% of Software Engineers 'Do Virtually Nothing' (x.com) 100
A Stanford study of over 50,000 software engineers across hundreds of companies has found that approximately 9.5% of engineers perform minimal work while drawing full salaries, potentially costing tech companies billions annually.
The research showed the issue is most prevalent in remote work settings, where 14% of engineers were classified as "ghost engineers" compared to 6% of office-based staff. The study evaluated productivity through analysis of private Git repositories and simulated expert assessments of code commits.
Major tech companies could be significantly impacted, with IBM estimated to have 17,100 underperforming engineers at an annual cost of $2.5 billion. Across the global software industry, the researchers estimate the total cost of underperforming engineers could reach $90 billion, based on a conservative 6.5% rate of "ghost engineers" worldwide.
The research showed the issue is most prevalent in remote work settings, where 14% of engineers were classified as "ghost engineers" compared to 6% of office-based staff. The study evaluated productivity through analysis of private Git repositories and simulated expert assessments of code commits.
Major tech companies could be significantly impacted, with IBM estimated to have 17,100 underperforming engineers at an annual cost of $2.5 billion. Across the global software industry, the researchers estimate the total cost of underperforming engineers could reach $90 billion, based on a conservative 6.5% rate of "ghost engineers" worldwide.
Replace managers with AI (Score:3)
Their managers don't seem to be able to figure out they are doing nothing, I bet software could do it. LLMs give pretty mixed results when creating things but they're super good at summarizing. You could eliminate the worthless coders AND their worthless manager at the same time!
Re: (Score:2)
Also, could we agre
Re: (Score:3)
Re: (Score:3)
Re: (Score:2)
Re: Replace managers with AI (Score:2)
Re: (Score:2)
Wat metric would you have the LLM look for exactly to figure out automatically that someone is slacking off ?
Re: (Score:2)
Wat metric would you have the LLM look for exactly to figure out automatically that someone is slacking off ?
Just pick people at random, like real managers do.
Re: Replace managers with AI (Score:2)
You win, that statement has the perfect balance of true and also hilarious.
Re: (Score:2)
You don't need a discrete metric. Ask the LLM to summarize someone's commits week-by-week over the past few months, then have a team lead review and determine whether the output fits with the nature of their role.
Re: (Score:2)
Their managers don't seem to be able to figure out they are doing nothing
They just generate activity to pretend that they are doing something of use to the company. For example, they often come up with slides the only purpose of which is to show that managers are doing something.
Re: Replace managers with AI (Score:2)
Re: (Score:2)
I doubt AI can replace a good manager as well as a good programmer.
The core task of a manager is to help their team to do their work as best as they can. That includes knowing how much each member contributes to the whole. If one or more members can slack off, the manager is the one who fails at their job.
Re: (Score:2)
I doubt AI can replace a good manager as well as a good programmer.
Sure, but that still leaves AI being able to replace most managers.
Re: (Score:2)
You don't really want to waste [wikipedia.org] a good programmer on management duties.
Re: (Score:2)
A good programmer can guide other programmers to improve their code as a group.
Re: (Score:2)
The paper shows those engineers continue to be employed, not that the managers don’t know they are commingling less code. So the managers may know and not have the guts to fire them. The managers may know but HR makes it too hard to fire them. The manager may know, but the corporate structure may make it advantageous to keep them (growing an org may be better for the manager then dropping an employee & the manager may not
Re: (Score:2)
You could eliminate the worthless coders AND their worthless manager at the same time!
My! Just imagine what that would do to Microsoft, for instance...
Would it extend as far as the worthless manager's worthless manager? And so on... Like rm -rf /?
Ads (Score:2, Informative)
Sorry for the hijack, but is anyone else suddenly seeing ads on the Slashdot pages despite both adblockers and checking off the checkbox specifically to disable ads for having been a good user?
Re: (Score:2)
Re: (Score:2)
No, my ad blockers are working. I use noscript and ublock origin, that combo seems to do it.
Are you saying the checkbox to disable ads has been working until now? It didn't work for literally years, and I'm not even talking about slashvertisements like people often do when they say that. So I just gave up on it.
Re: (Score:2)
I've been using uBlock and AdBlock Plus. Ads showed up today. Tried using the disabling checkbox (since no, it had just been off until today) just in case that would do something server side, but nope. Ads keep showing.
Re: (Score:2)
IME adblock plus is now pretty worthless, I dropped it a couple years ago. It was failing to block much of anything and also causing problems.
I see from noscript that two domains are being blocked which I don't recognize from before, ml314.com and 6sc.co. You might try adding blocks for those domains.
Re: (Score:2)
Your original question made me take a closer look at what the blockers are doing. uBlock Origin is apparently no longer running because it will soon 'no longer be supported'. Yay. There is apparently a new uBlock Origin Lite that at least hides the ads but leaves the whitespace where they would be. I'll go give Noscript a chance as well.
Re: Ads (Score:2)
What happened to your Adblock Plus? Is its block list out dated? No ads in Safari on my iPhone for both mobile and desktop views, using Adblock Plus.
Re: Ads (Score:2)
Re: (Score:2)
Wait, you're using Chrome? uBlock Origin is very much still supported on Firefox, where in fact it would like me to install an updated right now which must have dropped in the last couple of days.
Chrome was deliberately impaired by Google to make ad blocking less effective. This will probably be done to Firefox eventually (since Mozilla is now an ads company, since they bought one) but it hasn't yet.
Re: (Score:3)
1.) Stop using two ad-blockers it's the equivalent of using two anti-virus programs. AdBlock Plus is irreverent compared to Ublock Origin.
2.) Stop using Chrome, *oogle has fucked that browser up to the point it's useless for anything but Youtube.
Re: (Score:2)
Yeah, my adblocker cannot block the new ads.
Re: (Score:2)
Yup...just started here today...using Safari and Adblock.
It sucks....ads are WAY too big and intrusive.
net nuetral (Score:5, Interesting)
Re: net nuetral (Score:3)
Approximately the same percentage that was outsourced to low cost countries.
Re: (Score:2)
I work with a team of such people responsible for salesforce dev.
When they get to the change tickets (it can take a couple months), they're just suddenly implemented. The only way I can usually tell that the work was 'finished' is either the case being closed, or running into some other random bug in the UI that wasn't there before - because the requested work wasn't actually done, and a bug was implemented in its place.
Re: (Score:2)
They provide a valuable source of jira bug stories
TV (Score:5, Funny)
I'd say in a given week, I probably only do about (Score:5, Funny)
I'd say in a given week, I probably only do about 15 minutes of real, actual work.
Re: (Score:2)
I'd say in a given week, I probably only do about 15 minutes of real, actual work.
That has to be excruciatingly boring.
Re: (Score:3)
Re: (Score:2)
And yes the character was not a happy camper.
And was therefore promoted to management.
TPS reports don't show up in code commits! (Score:3)
TPS reports don't show up in code commits!
Re: (Score:2)
Not just software engineers (Score:2)
Over my career, I've worked with a lot of different companies and it's the full gambit of people. You always get those that take advantage of the system and do little to know work, usually just enough to get by and not get caught.
Re: (Score:1)
Yep, I would also argue that 9.5% is way to low. After doing this for 20+ some odd years, you get maybe 1 or 2 self-driven performers on the team doing the majority of the work. Maybe 2-3 second tier guys that take a small amount of load from the performers. The rest not only do the minimum to get buy, but the introduce a large load on the performers and second tier guys with the constant hand-holding. You can't fire anyone these days either unless they are a white straight male without HR getting heavil
Who knew? (Score:3)
And it is perhaps not unreasonable to believe that people who don't want to actually work or need active supervision would gravitate toward remote.
I'm sure I'll garner more outrage, but that is just a fact. I've had people who you just gave them a task, and they'd go away, and come back with really good work. And others who were capable of doing good work, but you had to kind of shepherd them. And some others that were pretty good at trying to do as close to nothing as possible, and they worked at avoiding work.
And that was in a normal work environment. It is not reasonable to believe that people who want to do as little as possible or need active supervision might be in remote work as well.
Re:Who knew? (Score:5, Insightful)
A more subtle kind of non-productivity in engineering jobs is "scratching the itch" too much - that is doing the coding that is fun to do or feels necessary, but which isn't actually aligned with any real need. Like, it would be so elegant if the code were refactored this way. Or, I wish I had this useful little utility that would save me 10 minutes per week and only take several days to implement! Or spending days tweaking a model to make that performance number go up just a little bit more... when nobody really even wants the model.
It's tricky because, sometimes, great things can also come from scratching the itch.
Re: (Score:2)
A more subtle kind of non-productivity in engineering jobs is "scratching the itch" too much - that is doing the coding that is fun to do or feels necessary, but which isn't actually aligned with any real need. Like, it would be so elegant if the code were refactored this way. Or, I wish I had this useful little utility that would save me 10 minutes per week and only take several days to implement! Or spending days tweaking a model to make that performance number go up just a little bit more... when nobody really even wants the model.
It's tricky because, sometimes, great things can also come from scratching the itch.
That is kind of aligned with the perfectionist - high quality worker, really good work - but you have to take the work away and declare it finished, while they want to tweak that tiny last bit of accuracy.
Re: Who knew? (Score:2)
Re: (Score:3)
yeah, I was thinking that the ~10% number was certainly no worse than nonproductive employees that nevertheless remain on the payroll in other occupations.
As to your point about how people work vis a vis supervision, that also plays to the manager who assigns the work as well. Some managers are too hands-off, some are too distracted, some are themselves disinclined to actually work, and this can have trickle-down effects leading to the non-work for at least some of that 10%. And sometimes having a patron
Re: (Score:2)
yeah, I was thinking that the ~10% number was certainly no worse than nonproductive employees that nevertheless remain on the payroll in other occupations.
As to your point about how people work vis a vis supervision, that also plays to the manager who assigns the work as well. Some managers are too hands-off, some are too distracted, some are themselves disinclined to actually work, and this can have trickle-down effects leading to the non-work for at least some of that 10%. And sometimes having a patron higher in the org as a protector can lead to not only no punishment, but reward for just being there.
Yup, the whole spectrum of human temperament affects us all.
I was definitely a hands on guy. Still am. People tend to appreciate that. My biggest "failing" is that I bristle when someone tries to bullshit me.
Re: (Score:2)
I can do nothing in the office just as easily.
Re: (Score:2)
I can do nothing in the office just as easily.
Do you like doing nothing?
Re: (Score:2)
And it is perhaps not unreasonable to believe that people who don't want to actually work or need active supervision would gravitate toward remote.
I'm sure I'll garner more outrage, but that is just a fact.
Well, is it a fact, or something that's "not unreasonable to believe"? It can't be both.
As a fact, I'm sure you could prove it with data.
With that out of the way, my project is all about maintaining a large legacy solution which makes a lot of money. There's very little to do in terms of patching, updating, improving that solution. All we have to do is keep it always up and available to customers.
This means it could be days, or even a couple weeks, between bursts of activity. I'm sure that Stanford study wo
God what a fucking joke (Score:5, Informative)
This isn't even close to research. This is absolute fucking trash and is getting absolutely tossed in the comments, but don't take it from the horse's mouth: https://arxiv.org/abs/2409.151... [arxiv.org]
Re: (Score:3)
Re:God what a fucking joke (Score:4, Insightful)
Yeah, there is something weird here. The paper does not show what the tweet is saying. The paper (it's arxiv, so apparently not peer reviewed) is showing how they calibrated a model of fairly standard software engineering evaluation question. It does not show any analysis of remote work/in-person work.
So maybe there is another paper somewhere else with actual details on how they got to that conclusion?
My guess is that if you were actually a full time software engineer and doing only 10% of the job of the median engineer. I think someone would notice!
I don't have a paper explaining the methodology, so maybe there are good answers but some basic questions:
-How do you know that the engineer's job is full time?
-How do you know that the engineer is not a DevOps that mostly worries about Ops problem?
-How do you know that the engineer is not working on a project that is not version controlled/in your data set?
-More generally, how do you know that a particular software engineer full time job IS to write code? There are plenty of soft engineer/trainers; of soft engineers/sales engineer; of DevOps
I'd need a lot more information about the study before taking it for granted.
Re: (Score:2)
"How do you know that the engineer is not a DevOps that mostly worries about Ops problem?"
At the chemical plant that position is called "process engineer". The job description is to do whatever it takes to keep the plant running safely and at capacity.
In the ideal case the plant is running smoothly and the engineer is not doing anything, but it's still worth having him/her around because that 10% of the time when the plant misbehaves is very expensive even without fireballs and vapor clouds.
Re: God what a fucking joke (Score:3)
This is also true for the board operators. The "joke" was if you see them doing nothing, you're making money because the plant is running well.
Re: (Score:2)
Re: God what a fucking joke (Score:1)
Re: God what a fucking joke (Score:1)
Roles (Score:2)
I wonder if some are in roles such as 'architect,' still classified as a 'software developer' but whose duties don't include writing code.
Also I wonder if it's the same 6% to 14% all the time. In a big enterprise it might not be possible to keep everybody full tasked all the time. Just as 4% unemployment is considered "ideal" in the overall economy as there always is and needs to be some slack for people
Re: (Score:2)
And an 'architect' might even skew to look like an entirely unproductive employee through checking out code and then releasing without committing any changes too, because that person is reviewing the work of others.
Accountability (Score:3)
It certainly is easier to slack off and post on slashdot with nobody standing over your shoulder but....
There is not argument with completed deliverables, being present and on time. If there is anyone to blame here its probably the project management people. Yes even team leads and architects should have outputs they are responsible for and someone running the project (who is responsible for the project it self) should be able to at least determine if the stuff looks "real" even if they are not a technical expert. A PM ought to be able to look and see design documents, they should be able to at least map the product specifications to sets of functional sepects that are assigned to developers or groups thereof.
Some people are really great heads down workers who sit down grind it out and are done. Other people do the same 8 hour job by hanging around their PC for 10 or 11 hours and taking 10s and 20s here and there. As a manager I don't give a crap how you get it down. My expectation is you can complete deliverables at roughly the same rate as your peers averaged over some number of weeks; and if a deadline is given because its on our critical path you meet it. The when and how does not matter to me much. You want to want to stay up until 2AM because you didnt feel like working during the day, whatever. I work with a guy that likes to take four hour lunch breaks to ride his motor cycle MOST DAYS, he gets stuff done, he is available for meetings (usually in the AM) I don't care where he is the rest of the day.
I am one of them... (Score:2)
If you judge me by github - I do "virtually nothing" - one line here, one line there...
But I maintain and old system which is stable and should not be changed too much...
So the actual value is in the fact that I have knowledge how to fix things with minimal impact/changes...
"doing-a-lot" guy might be actually a big problem here...
Did they need a study? (Score:1)
Surprised the number isn't higher. Just ask the handful of strong developers in any team - Who causes the team more work just by being here? I doubt it is only 9%. (I'm talking about on average. At Goldman it should less. At "APP company for dentists" or some place like JLL, higher.)
What I read from these numbers... (Score:2)
...While slackers seem to be slacking off more in WFH, office work by no means guarantees that staff is working efficiently.
One wonders if WFH efficiency dips correlate with workplaces where the managers weren't anything to write home about to begin with.
Re: (Score:2)
In the office before telework was even on the table I was regaled of tales of youth, bondoing-over the rear-side windows on a VW Superbeetle, or of the antics of Jesse the Wonder Dog by an employee who was up into management and yet never really did anything.
Re: (Score:2)
Wait! What? Your office didn't have a football pool?
It sounds like remote work is a big money saver (Score:3)
If it only adds 8% dead weight, of they can attract people at 10% less pay (which shouldn't be hard, commuting costs $5,000-$10,000ish+ after taxes (40 miles@$0.50, $8-12 for lunch if you want something warm, maybe $15-20 to have a dog walked, and ) and takes an extra 2 hours a day between getting ready and commuting.
On top of that they can save on office space.
Assumptions (Score:5, Insightful)
Assessing a software engineer's performance solely based on their source control submissions is fraught with peril.
Two real world examples from my prior employment.
An SE and I worked together to knock a full month off of our company's DR exercises. With process changes, documentation, automation, and architecture work we cut many man-years of effort out of an awful manual process. The impact of that was huge, and invisible in code commits.
Another example: A pile of tickets get escalated to an SE on random API errors. A couple of days later the underlying problem is identified as a bunch of bad data in the database from a failed batch job process. A one-off SQL query fixes it, but that gets recorded in a ticket, not normally in source control.
No metrics were disclosed + legacy + tech leads (Score:2)
Another: legacy code. Did you search the FULL history...including the deleted files? If not, my most senior teammates in tech lead roles would
Re: (Score:2)
Re: (Score:2)
everyone uses Git
Unless you're in the Microsoft world and stuck with TFS.
What about legacy/history? (Score:2)
1) Git the fuck outta here, everyone uses Git. (Except my current team, buncha dinosaurs stuck on Mercurial)
Git was rarely used 15 years ago. Most companies are older than 15 years and many tech leads have been at their jobs for longer than 15 years these days. These jackasses didn't disclose how they compiled these metrics.
Did they check legacy repos, likely SVN or even CVS? Did they check the FULL history or just use Git Blame? The number is really really high and doesn't match my daily experience.
You seem to be pretty confident. I'll assume you're an experienced professional. Do you think 1 in 10
Yeah, let's fire Bill Atkinson!!! :-) (Score:2)
https://www.folklore.org/Negat... [folklore.org]
====
Author: Andy Hertzfeld
Date: February 1982
Characters: Bill Atkinson
Topics: Software Design, Management, Lisa
Summary: It's hard to measure progress by lines of code
In early 1982, the Lisa software team was trying to buckle down for the big push to ship the software within the next six months. Some of the managers decided that it would be a good idea to track the progress of each individual engineer in terms of the amount of code that they wrote from week to
Why are you posting a tweet as a source? (Score:2)
I do not believe this (Score:3)
Re:I do not believe this (Score:4, Interesting)
After a non-trivial time with "big enterprises", I can certainly believe that such folks exist. In fact, I have seen them. Several contributing factors.
Executives who feel good about themselves by virtue of having a large number of subordinates. In a lot of corporate structures, there isn't much accountability so they like having hundreds of workers underneath them without suffering downsides.
In our case, there's an offshoring mandate that calls for expanding number of people to make up for reduction in high cost staff. The current staff had no role in vetting the offshoring, and the offshoring site is basically just there to con the company out of money for appearance of a successful offshoring. What happened to the managers that reported difficulty with uncooperative offshore staff? Let go because they made the executive look like he made a bad call, and there was no shortage of sycophant managers willing to pretend it's going fine (after all, they still get their funding, and if they don't care about the work, then why should they care the workforce sucks?). I actually pulled the codebases for one of these staff as an example, 12 lines of code total over 4 years of work (and no, he wasn't off doing other work, he was supposed to be pretty much a 'code monkey'). Every one who called him out as useless got chastised and dinged on performance reviews, because it was "their fault for failing to enable him to be productive".
These places have a non-technical management trying to manage technical people. Makes it super easy to bullshit them and the people who like to talk are favored over people who get results, because the management has no idea. In fact, doing stuff is often riskier. If you do nothing, it's hard to actively screw up.
You have non-tech companies where this should actually be expected, but also "enterprise" tech companies are bad for this, because their business success is more about marketing and the golf course than the products.
The corporate process at work. (Score:2)
Your output in terms of code is not the only factor in determining your productivity as a software engineer. Chasing requirements, dealing with corporate bullshit, dealing with problematic and clueless hands-off managers, copious amounts of unnecessary meetings... Those are just a few of tens of other factors that are a part of being an employed software engineer and while everyone else forces you to do the talk, how on Earth are you supposed to do the walk?
Re: (Score:2)
Every team has the 'productive idiot' whose work always needs to be cleaned up, and every team has the 'unproductive genius', that person everyone goes to for advice when they get stuck, the one who has internalized all the task-relevant institutional knowledge. And their code is solid.
Code volume alone is a stupid metric, used by managers who don't properly understand the people they're managing.
Incompetent managers costing billions to companies (Score:2)
let's fix that headline for ya: Incompetent managers costing billions to companies.
2 questions -
are there no mechanisms for tracking performance at these places? and no i don't mean in number of commits, or lines of code, or useless metrics like that. A task is assigned, and a task is completed - if it took a month to do a single task, so be it.. the manager/lead/supervisor/whatever should be smart enough to know what would be required of the SE to complete the task.
Or are the employees underutilized and d
Re: (Score:2)
Problem is that "performance" tracking is flawed because the one doing the assessment is easy to get manipulated. They are delegating usually because the task is over their head.
So people who talk a good game win over people doing solid work.
More prognostications from the Big Hairy Oracle (Score:2)
Re: (Score:2)
>> Basically, there's is NOTHING new under the sun in terms of software for many years now...
You are clearly making sweeping assumptions about the entire software industry just based on your own experience of cellphones and web tech, and an incorrect assumption that those two things are all there are in the field.
While I agree with your comments that the tech in those two fields is basically stagnant, trust me there is far more interesting things going on in software than there ever was in web and cel
Re: (Score:2)
Medicine? Astronomy? Seriously, I'm listening...
This is exactly what is expected everywhere. (Score:2)
The actual metric is that 9.5% of software engineers have performance that is 0.1x the median software engineer.
Let me rephrase that, the bottom 9.5% of all software engineers have performance that is less that 10% the performance of the median engineer.
This proves, beyond a doubt, that the bottom 10% of people in this field are bad at their jobs.
Which is a theory that didn't need to be tested. This is why there is a bottom 10%.
And although it does play a large role, this isn't all from incompetence - even
The ones doing nothing are less damaging (Score:2)
Here we go again (Score:2)
As someone who's been writing software for a living for more decades than I care to admit, I've lost track of the number of times that I've seen a new crop of bean counters trying to put a new spin on the same old tired and broken idea of measuring productivity by lines of code in one form or another. The only thing that changes is the new name they give it every time. ...And they fail every time because as every actual engineer knowes, it remains a fucking clueless idea, yet for whatever reason they never
I bet those UI changes count as productive (Score:2)
Do you think a bunch of people who keep changing the UI of your software count as "doing work"?
Quite a lot of software "work" provides no value at all to the users, while people who can put a stop to these useless UI changes actually helped the users but counted as "doing minimal work" because they don't produce any lines of code.
Idiot managers get what they measure, hence we have so many pointless UI changes in what was perfectly fine software.
Re: (Score:2)
I'd mod you up, but I can't find where they put the +1 insightful button.
FAKE article? (Score:1)
When was the data collected? (Score:2)
Wasn't there stories that Facebook, Google, Microsoft and others were hiring up programmers and such so that other companies didn't have access to them?
It's possible that even those that had 'work' to do were really just make-work, and completely useless as well.
(but I've had that co-worker... they hired someone to take load off me, and it didn't work. I reduced my hours to keep from burning out and free up money for ANOTHER person to take load off me. The first one did next to nothing, while the other di
Stanford researchers (Score:2)
A study of Stanford researchers by Stanford found that all of them to extremely important work and not only should have significant raises but should never be questioned in the future.
Re: Stanford researchers (Score:2)
There are a number of problems with studies like t (Score:2)
I'd still fire 80% of marketing first (Score:2)