Yegor Denisov-Blanch, a researcher at Stanford University, says that 10% of all software engineers are "ghosts" who basically do nothing. This is based on data he's collected on 50,000 engineers at hundreds of companies.
But the number varies with work arrangement. Only 6% of engineers who work at the office do nothing, compared to 14% of those who work from home.
Case closed, right? Bring 'em all back to the office! Not so fast:
The average productivity of engineers who work at home is indeed low. But the absolute tippy top ranks of engineers also work at home, where they're free of most distractions.
So is it worth it to accept some shirking from remote workers in return for getting higher performance from your stars? That's not necessarily an easy decision.
Of course, the best thing would be to identify all the ghosts regardless of where they work. I confess I don't quite get why this is hard. My experience is that programmers are generally given specific tasks as part of a larger project, and if they literally do nothing they'll get caught eventually when their chunk of the project never appears. There must be some piece of this that I'm missing.
I'm retired now, but I always got more done working from home due to the fewer distractions. In addition, I saved 30 minutes each way not riding the bus and I was living and working in SF so had about the easiest possible commute. That said, for companies that care about security, it doesn't really work unless you have a beast of a laptop and a large monitor at home or a gigabit connection to your desktop machine. Ideally, you have both.
This idiotic study counts code commits (and presumably lines of code) as its metric. It's garbage. The best engineers spend time planning, helping, and explaining, in order to get more actual stuff done. The person who commits the code might not even be who wrote it. More meaningless faff from people who want to force everyone back into offices.
Thank you!
Also, lines of code committed tells you nothing about the amount of work that went into finding the right line of code to change and the exact change that needed to me made, which in a large application can be monumental.
Writing a brand new piece of functionality of 500 lines can be a lot easier than finding a fixing 5 lines of code in my experience (and I've been a coder for 25 years).
I have said this before and I will probably say it again. When people on a work team are not contributing, that is a management problem. The workers can be at home or at the office, it really doesn't matter. The manager should know exactly who is reliable and getting stuff done and who is not. If a manager can't make a WFH team work efficiently, fire the manager.
And someone can do useless commits just to not get 'caught' whether in the office or not.
Open code file => format file => commit file
250 lines of code!!!
Exactly! Worked in the IT field for 50 years, and this study is garbage.
Often lost in the third party remote work evaluations, is the unique impact on new employees. I KNOW several firms struggle, in a remove only/mostly situation, to get new employees, especially folks just out of school, to integrate into a firm's norms and culture.
A new, remote only employee misses the casual lunches, overhearing folks in nearby cubes, and the friendships that are often developed in person. Seemingly, the aforementioned loses are not as significant for experienced employees.
I KNOW a firm's norms and culture (to the extent that they even matter) can be transmitted electronically and not just in meat space. It's a failure of management, not a failure of remote work.
Nearly all managers suck ass at being managers.
(I am a software engineer who manages them.)
The worst productivity killers aren't the net-zero folks, it is the ones who spend their time making their workload someone else's problem to solve. This happens in all sorts of ways, just like shirking in any industry. But it also tends to end up producing really bad output that just ends up being reworked by someone else or thrown away.
One place I worked we had a guy (who was eventually let go) who did "negative work" as we called it since invariably someone else would have to debug and fix his code. Months later after he was terminated we cussed it out under our breath whenever we were assigned a bug to investigate and it was in a program that his initials in a comment line at top.
There are superstar programmers who goof off playing games 60% of the time but when they're ready, from 8pm-2am, they create works of art. Forcing them to sit behind a desk at a certain time makes them unhappy. I know one who quit a well-paying job because the environment wasn't conducive to kicking off his shoes while working. Good teams identify and coddle them.
Where's the paper?
I mean it. There's a website, there's a Twitter thread, but where's the paper?
I only see a single publication by this author on arxiv, which doesn't look like what's being described here:
https://arxiv.org/search/cs?searchtype=author&query=Denisov-Blanch,+Y
Guy's an MBA student trying to start a developer productivity company. I, uh, think this may not be on the up and up.
https://finance.yahoo.com/news/middle-school-dropout-stanford-mba-171052527.html
Ha Ha! Never trust a reference to a study, right? Just last week I dug into a medical study and found it included only 30 participants.
There must be some piece of this that I'm missing.
Yeah, it's called having middle-management that demands results not excuses.
The is also a big problem in field Sales orgs now. I know several "account executives" who are double and triple dipping. They don't meet quotas but these days very few reps do, because "macro". Sales management doesn't want to let them go because 1) it makes them took bad and 2) it takes the slackers months to ramp up.
The experiences related by chumpchaser, different_name, and shamhatdeleon match my own.
Years ago, Joel Spolsky (of Stack Overflow fame) used to write a blog on software engineering, and of his many useful recommendations, two in particular are relevant here:
- Do you make candidates for new positions write code?
- Do you make sure your programmers have offices with doors that close?
The answer to both questions should be "yes." IOW:
a) yes, you really *can* separate the wheat from the chaff--provided you use the right, mostly qualitative standards (with commits or lines-of-code not necessarily being the right ones); and,
b) once you identify such high-contributing engineers, you need to make sure they're afforded a relatively low-distraction / task-switching free environment in which to get into & stay in the head space required to design good software.
That advice to give them offices with doors that close was a good one, but it flew in the face of the "open office environment" trend that was sweeping the industry over the past decade or two. Very popular with management, hated by the workers. Fortuitously the pandemic came along and sent everyone home to work so it stopped being an issue. Now, instead, we have "hoteling" where workers don't have any kind of permanent office at all. Good luck getting people to return to the office with that kind of setup.
I remember when I was regularly in an office cubicle and overhearing some sort of administrative workers on the phone, doing what sounded to me like needed work. Trouble was, it was still distracting, and the most sensible solution work have been to put them in an office, where they could do what they needed to do without bothering anyone else.
Trouble is, offices seem to be reserved not for those who most need to talk, but to those higher up on the hierarchy. 🙄
"open office environment"
Aaarrrrggghhh! This was the worst development in the work environment since child labor.
If you deem all of the low productivity workers unemployable...
don't they end up either homeless or stuck permanently on government safety net programs?
They go into management.
Several people have already pointed out problems with this study. I think there is also a problem with Kevin's interpretation of the chart: there are exactly two data points on the left that are higher than any of the data points on the right. My understanding of this chart is that this corresponds to exactly two individuals out of 50000. Statistically meaningless.
Re top performers, seems like the causation arrow might run backwards: top performers can say "I want to work from home." and make it stick, because if one employer doesn't allow that, they can always go elsewhere.
Re the legions of "ghost programmers", color me skeptical. As others have pointed out, the metrics used here are sketchy at best.
"Your employees are goofing off. Really, they're robbing you! Only our marvelous surveillance software can protect you." Yeah, right.
Okay, back to committing my requisite lines of code for the day.
In my programming days I don't think I ever knew anyone who didn't do the work assigned at all. Tolerating that really would be appallingly bad management. I did know a very few people who were bad at coding (see my comment elsewhere about "negative work") and they were a problem, but they did do the work assigned, just badly.
I retired from a position as an IT manager for the federal government. My experience was that working at home made the best workers even better and at least kept the least competent out of everyone else's way. Our overall productivity went up substantially.
In the government the process to fire people for incompetence may take years and usually results in placing the person in a different job that he may be able to do. So my experience may not be applicable to the private sector, but I suspect it is.
Who says that remote work produced both good and bad coders?
Maybe the coders were already bad and they just happen to be working remotely.
Maybe the good ones were already good and working remotely is a preference they can swing because they're so good, and maybe it makes them even better.
Also as pointed out in the comment threads, maybe this metric isn't really measuring skill at coding.
Back in my programming days I would log on from home or come into the office many Saturday mornings. In the latter situation it would be just me or maybe me at the QA tester there. I could get a lot more done than during regular hours because A) no meetings B) No office chit-chat C) no other distractions which were numerous.