"Last week, a tweet by Stanford researcher Yegor Denisov-Blanch went viral within Silicon Valley. “We have data on the performance of >50k engineers from 100s of companies,” he tweeted. “~9.5% of software engineers do virtually nothing: Ghost Engineers.”
Denisov-Blanch said that tech companies have given his research team access to their internal code repositories (their internal, private Githubs, for example) and, for the last two years, he and his team have been running an algorithm against individual employees’ code. He said that this automated code review shows that nearly 10 percent of employees at the companies analyzed do essentially nothing, and are handsomely compensated for it. There are not many details about how his team’s review algorithm works in a paper about it, but it says that it attempts to answer the same questions a human reviewer might have about any specific segment of code, such as:
“How difficult is the problem that this commit solves?
How many hours would it take you to just write the code in this commit assuming you could fully focus on this task?
How well structured is this source code relative to the previous commits? Quartile within this list
How maintainable is this commit?”
Ghost Engineers, as determined by his algorithm, perform at less than 10 percent of the median software engineer (as in, they are measured as being 10 times worse/less productive than the median worker)."
https://www.404media.co/are-overemployed-ghost-engineers-making-six-figures-to-do-nothing/
#SoftwareDevelopment #GhostEngineers #Surveillance #Overemployment #Programming
They are probably senior engineers helping the rest of the team, going to meetings, organizing scrums, dealing with product, breaking down jira tickets into manageable tasks, dealing with vendors, doing production support, interviewing new candidates. There is more to engineering than just commits. 10% of the median does not mean you are a slacker.
Yeah, you’ve just described me.
I spend almost all of my time:
- Tracking in what specific way the test environment is borked this time so I can figure out what team to bitch at to fix their shit.
- Helping someone on my team figure out how to fix their local development environment or figure out how to make Spring do something that should be simple, but actually requires looking at the Spring source code to find some obscurely-named class or annotation or whatever.
- Maintaining the Jira board, doing sprint-related documentation (because the stakeholders are above looking at Jira, I guess?), running standups, plannings, retros,
reviews(don’t ask), having 1-on-1s with my team members. - Answering random questions from business, QA, other engineering teams, etc.
- Forwarding meeting invites.
- Logging my time like it’s 1999 and I’m an hourly-paid intern because my company still thinks the internet is a fad. (Exaggeration, but yeah.)
- Code review, though I definitely don’t get to that as much as would be optimal. I very much need to neglect some of the less important things above more to do more code review.
The way I think of it, much of what I do is unnecessary busywork made necessary only by the dumb rules invented by C-level people. The rest of what I do that actually contributes to the team’s success (I like the word “success” over “productivity”, but my employer doesn’t so much think in those terms) has, rather than an additive effect on velocity, a multiplicative effect. If I spend an hour helping someone else, it’s probably going to save them well more than an hour of banging their heads against a wall.
Yeah this is dumb
@remixtures@tldr.nettime.org The article talks about how they control for engineers who should be doing things other than just coding by talking to their managers, but I know a lot of managers who don’t actually know everything that goes on in their teams.
