I can't believe this is a real statistic...

[@benheidemann3836]

Hey Theo, I’m a little disappointed that you haven’t gone any deeper than surface level on this. Here’s some really important nuances I think you missed in your analysis. 1) The Stanford paper this analysis is based on is looking at how effectively a random forest model can match expert evaluation of commits, not at productivity 2) The algorithm is trained on only 70 commits 3) These commits, which were selected from a larger data set, were all around the same size, and all in Java codebases 4) The methodology used to avoid overfitting seems to be flawed, as it *seems* to have been evaluated on the same commits it was trained on 5) The productivity graphics were derived from applying the model to a much larger and more varied data set 6) The methodology for applying this to a larger dataset is not made public (productivity data is disclosed via a tweet, not a published paper) 7) The productivity data does not adjust for other forms of productivity e.g. I’ve worked with many tech leads and senior engineers who manage only a small number of commits due to meeting commitments, peer review, writing documentation and mentoring/pair programming etc. It’s unclear how much this skews the data set, and this should be adjusted for (as well as other factors). I really think your style of reaction content could benefit developers a lot more if you demonstrated and encouraged critical thinking, and in this case critically evaluating the primary sources, rather than taking secondary/tertiary sources as gospel.

[@masterp2k6]

💯

[@kassios]

He is a victim both to confirmation bias and click baity content.

[@inasuma8180]

Commenting for visibility. This was a really disappointing video.

[@joaovaporto]

Great analysis!

[@robydoby3882]

Wow so disappointed that you just confirmed your biased without looking at all at the context and content of the "paper". So many things wrong with this one. Do hope you'll remove the vid :((

[@tauraamui]

They haven't published their paper, but from their description their metric was derived from analysis of total lines of code written, and "syntaxitcal quality" of code, not real work measured.

[@cole5981]

This should be higher up. Forget measuring the "actual productivity/value" or "time being put in", it's literally just LOC and "code quality". The good managers are catching strays with this one as well. Hell, what ever happened to "less code is better"?

[@JohnKerbaugh]

So code churn is good. More bugs more betterer!

[@joranmulderij]

Remember that this is research. Employees are not going to change their behavior based on how these metrics are collected. Sure these ways of measuring are terrible for managers to implements since it is going to effect output, but this is independent research which makes it a lot less of a problem.

[@ok_comment9085]

yeah, i agree with theo in his point. but theres alot of work done outside of coding

[@JohnKerbaugh]

Some of the most important work is what's not implemented, after having lengthy discussions. Building unsupportable code inside elements that need refactoring can be damaging to the team and organization.

[@togelian]

You really dropped the ball on this one. It's one article that happens fit the narrative of the tech companies. There's more to creating software than writing code. 90% of my job is making sure we actually deliver what the customer expect us to deliver. That means communication, planning and testing. None of which needs code, but are necessary all the same

[@Jonteponte71]

All of that "boring shit" outside of actually writing code is the majority of the work. It seems like people who actually codes should know this. Especially testing. If you do testing right, a truly insane amount of work goes into this. Most of which does not result in code commits....

[@soviut303]

This is a dangerous thing to be spreading considering how it was measured. They're using "number of commits" which is basically the same as measuring developer performance by "lines of code written". The headline is total management bait, giving another excuse for them to do layoffs. In reality, if there were really that many "ghost developers" then it'd be management's fault for letting it happen in the first place so management is the real ghost! The ghost fish rots from the ghost head.

[@CottidaeSEA]

Yeah, yesterday I wrote probably like 50 lines of code at most, but if you ask my colleagues they'd probably say I do too much. All my work can't be measured in lines of code or commits.

[@Jonteponte71]

I worked at a developer once. I would have been fucking extatic if I would have been able to spend most of my time actually coding. But that was not the case and was one of the reasons I moved on to DevOps. Now I spend most of my time helping developers become more effective so they can get back to actually coding and not have to deal with a long laundry list of tasks that does not actually result in code commits in the end...

[@jabbruh]

So true sorry but that's a L of Theo

[@knob-n2c]

"dangerous"? NO honest developer would consider boat anchors being fired a bad thing. Even if a manager fails at their job, if that results in a dev quiet quitting, they still 100% deserve to be fired. It is so disgusting to hear defenses for lazy people as someone who musters up the motivation to actually care about the task at hand if I get hired to do said task. Have some self respect!

[@CottidaeSEA]

@knob-n2c I think the big issue is that far too many of us have such nonsense statistics used against us, not so much that we're defending lazy developers. I dislike lazy employees in general, but measuring their effectiveness by number of commits or line of code is just stupid. I already have bullshit metrics I have to achieve but with no reasonable means of doing so just because of my workload. I am tasked with far too many things that require me to work outside of code. Statistics shouldn't be the goal, but articles like these tend to promote such thinking which is dangerous. If someone is intentionally not doing their job then that's the problem, not the lines of code or commits. Those are at best indicators which mean the management needs to look into what that person is actually working on.

[@putnam120]

You need to read the actual "research" paper by the mba. Pretty low quality approach they took

[@csYouTube19]

@@putnam120 I’m not sure if I trust the specifics considering the source, but this is a problem. Developers get put into teams by managers and those of us who actually do our jobs have to work twice as hard to get things done half as fast because of devs who do not do their work

[@tvujtatata]

@@csKZbin19 you gotta know your value then

[@guacattack9132]

This paper is anti-remote corporate propaganda. How would you possibly have employees that do nothing yet you have no visibility on this? The real story, if one exists at all, is extreme management failure.

[@m12652]

😂😂😂 Come to the UK, our public sector is full of people that do nothing...

[@soverain]

@@m12652 Same thing in France, at this point it's a competition to be the worst employee.

[@m12652]

@@soverain it's so sad... it's like mother nature is telling us to abandon government, politics and the public sector. Both are considered essential due to needs but neither deliver the benefits that satisfy the needs. It's the default behaviour of most humans to do nothing, to take rather than earn and lie rather than learn... I.e. people in large groups can only ever be toxic, regardless...

[@m12652]

@@soverain in fact... I saw this yesterday on another channel "britain has developed a new missile. It's called "the civil servant", it doesn't work and it can't be fired" 😀

[@PhantomGanhdi]

*How would you possibly have employees that do nothing yet you have no visibility on this?* In my prior role we didn't submit frequent code/tech reviews. It's mainly only submitted at the end once everything is done or varying gaps. So, managers wouldn't really know if an employee is working or not until the various project milestones/or deadline for launch was missed. Added onto this, with people working remote the managers wouldn't easily be able to walk over or casually check to see what the employee was doing. Now, for the other roles at my job they submit code reviews more frequently, so it's a bit easier to see since reviews are submitted more frequently.

[@jacobswiney9977]

This is common at every job ive had, it's not exclusive to programming.

[@EliasJackson]

Yeah it really doesn't seem as surprising as theo's reaction tbh. People have been slacking and freeloading since the beginning of time

[@tima1301]

+

[@JackFate76]

Only in companies with more than 10 people.

[@huntermacias2023]

@@EliasJackson theo can be a bit dramatic with most of his takes. He almost seems unaware of the world outside tech

[@assombranceanderson6175]

Sure, but remote work is most common in IT (right?)

[@Bokbind]

It might be a "real statistic", but as the saying goes,:"There' lies, damned lies, and statistics". If you look up the word done behind this study, it's currently not published and not peer-reviewable. You can't see their methodology or the data they used. They say they study people who code, but the X thread doesn't say how they differentiate between e.g. a developer and a tech lead position. It might feel interesting to look at this data and draw inferences, but without a good review of their methods, you just let your biases show one way or the other.

[@montgomerymontgomery]

I think that you should look at where they got the data since it seems like it doesn't actually showcase realistic work. This is just being used to justify layoffs and not necessarily actually measuring anything.

[@leulgirma]

it seems like they adjusted the research perfectly to justify return to office and to fill office spaces with ppl

[@gabrielbianchi2246]

Theo, watch Alberta's video on this. She made a long-form video, not a short.

[@jscul]

What if the software engineers are doing work outside of repositories for a bit, then switch back when their work is done. How does this quantify things like "spikes", or "DB data patches", or writing docs. I feel like using code as the sole output is not accurate. But maybe I'm misunderstanding the evidence they provide.

[@Frostbytedigital]

I know 3 engineers right now who haven't touched code in 2 years because of the documentation, planning and approval process of the project they are working on.. it seems like this kind of report is just more likely to push the rto initiatives instead of being accurate data

[@AlucardNoir]

​@@Frostbytedigitalhonestly? They either need to be fired since they haven't quit already, or the entire project needs to be shut down and everybody fired. If you keep 3 full time, highly qualified employees doing nothing for 3 years because of planing and permissions there are a lot of people that need to get fired over there.

[@Frostbytedigital]

@AlucardNoir people do get fired and projects scrapped all the time. Big corporate tech waste a ton of time and money on things like this. This same project has had its team laid off and the project restarted by a different team 4 times in my 7 years here. If I didn't work on a small team that has much less red tape and oversight I'd have left long ago

[@gamer-gw9iy]

You know who did this study? Some stanford mba. This is just pushing RTO

[@csYouTube19]

You know who posted this comment? Someone who relies on WFH to get away with not doing their work

[@gamer-gw9iy]

@csKZbin19 Sounds like someone is sucking too much manager.

[@ibrahimkayikci2146]

@@csKZbin19 There are a lot of assumptions used to fill in the "unkown unknowns" in this study. At least the way this guy summarized it. Productive according to what and whom? What's the standard for high quality code? I see people write hundreds of lines of code, written in months, which can be replaced with code written clean and readable, reduced at least to half its size, finished in a single sprint. According to the criteria described in the video, the prior devs are more productive. Because they wrote more code, spent more time writing it, and it works. While the latter is less productive. Because he worked half day, produced less code (even if it does a better job than the prior). The thing is, the new hires after the latter dev leaves the company will also spend less time understanding his code before they start adding more work on it, because it's clean and readable. This will save a lot of time and energy for the company. But if we're talking about time spent working, this is bad. When you look into some of these studies with an experts eyes, there are serious logic errors. When people reference these studies because of the brand, it leads to errors on high-impact policies. WFH is definitely more productive. It lets people get more work done and waste less time and energy on unnecessary bs. It lets them take care of their of their children, family. They can take a mid day nap to eliminate brain fatigue, rather than overdosing on caffeine and nicotine. It has its cons but the benefits outweigh those by a ton.

[@igotballs1]

@@csKZbin19 ok boomer

[@csYouTube19]

@@igotballs1 I’m probably younger than you but if this is the cope you have to resort to, I won’t stop you

[@simonabunker]

Spoken as a true manager. The data used for this report seems like it was picked because it was easy to measure, not necessarily that it measures the correct thing.

[@igotballs1]

love how Theo only likes the comments that agrees with his bias narratives

[@ohLyln]

I work with one of these guys. He’s a “senior” and I’m just “mid level / level 2”. We do pair programming and I worked with him on a Jupyter notebook. I did 90% of the work (grab data, parse feed to llm etc etc) we just needed to batch the work (read in multiple data files and loop over them) was the day before thanksgiving. He couldn’t figure out how to loop over the files in directory. He thought “with” did the same thing as a “for” in python. He feed it to GPT 5 times and it spewed out the answer hidden, nested in the code output. He couldn’t figure out which part he needed to get ours to work. At the end he said “this is starting to feel like an after thanksgiving problem”. I pulled dev, made the change and pushed it in 5 minutes.

[@igotballs1]

i used to be just like you, heck i look down on people that are slow, lazy and can't get their work fast but after becoming a senior engineer, i realized that these engineers has wisdom knowing that there is always work tomorrow and there is no rush to get them done.

[@MadsterV]

I used to be just like you, then I discovered that the companies I was working for were garbage. I both found a better employer and made sure that they would see the value I'm bringing. I'm not waiting a whole week over something I can do in 5 damn minutes, I'll do it myself and make sure my manager knows I saved them days. I'll also make sure they keep my hours flexible and they don't demand more than what's reasonable of me.

[@jjcbvg]

@@igotballs1 hmmm…not sure on this take…I can understand your perspective. But, this is definitely not a “I’ll handle that tomorrow style case” OPs case is very obviously one where the senior dev - again, SENIOR. DEV. - should have been able to parse through gpt response if anything…and in the best case know the language he’s senior in… If it were a technology/language they aren’t senior in then…ok…maybe they get a pass. I think what you are alluding to is when the work item is v complex or requires heavier problem solving time/weight thrown at it…sure in that case it makes sense

[@soviut303]

Only a fool does someone else's work for them; that's why you're level 2. You're literally playing into the hands of your employer by pitting yourself against your colleagues; working harder for no extra benefit. You have no idea what that person is going through personally, if they have a sick kid and didn't get any sleep the night before, or any number of things they're not telling you. Remember, a rising tide lifts all boats. If you wind up getting your colleague fired, it's just going to be more work heaped on your shoulders.

[@soviut303]

@@jjcbvg Sometimes people become leads because they're good at, you know, leading. Saying "let's solve this later" is good advice that the OP couldn't handle because they're not as experienced. A lot of younger developers burn themselves out this way.

[@efrenUtube]

There is something you are not considering but critical for this analysis, contributing in huge codebases is way harder than greenfield project for many reasons, some of them: legacy code, more verbose file architecture, more complex setup (multiple services), more bureaucratic processes, focus more on stability vs productivity. More than blaming the ones that are not so productive, I think we should recognize the ones that despite all of these challenges keep themselves productive, that''s the real miracle if you ask me. Any monkey coder can be productive in a small team greenfield project, the real challenges comes when the complexity blow up.

[@Jonteponte71]

Exactly. I just quit from a global US tech company. Most of my time was spent sitting in meetings, navigating opaque processes, managing relationships with severely understaffed support groups all over the world who's help I needed to get anything at all done. In the end it was a fucking nightmare of stress. My current employer has been a revelation. Properly staffed teams, clear processes on how to get shit done and a happy team that are productive together. I was in global Financial IT. I should have left it years ago.

[@igotballs1]

Speaking like a manager at a startup where all the benefits are awarded to only the higher-ups and not the regular employees.

[@Provokant]

Hey dev from germany here. Over here you often times just don't have enough devs so the extreme under performer can't hide that good. But boy do we have a lot of useless managers over here :D

[@gageracer]

Measuring productivity with commits. The best way lol.

[@csYouTube19]

@@gageracer it’s a terrible metric but the issue discussed in the video is a real issue. I’ve worked as a software engineer for multiple companies and every team I’ve ever been apart of was severely held back by 1-2 people who just simply didn’t do their job

[@AshesWake-sf7uw]

​@@csKZbin19 it might be close to real, but you cannot disagree it was written in that way for the article to get a lot clout...

[@krishsroy201]

​@@csKZbin19 maybe you haven't worked at "good" companies. After all, there are so many companies that hire mediocre engineers and need mediocre engineers only. Try getting a job at a big one (not necessarily "big tech" but any good product company), or a proper engineering company that pays well. But... that'd require skills. That part would possibly be difficult for you.

[@ruannascimento5732]

All of this is so weird. The paper the author cites on the thread has none of the data presented on the thread, instead it presents the model of which apparently made the conclusions. Except the model does not seem to really evaluate productivity, rather it has ~80% accuracy on assessing the complexity and time to complete the task, it does not seem to clearly explain how do they use these metrics to actually measure developer's performance. If I understood correctly, the only data they actually have is the github repository, so I'm not really sure how they're able to get productivity metrics from the commits alone. And about the "Might work multiple jobs" statement, It doesn't seem to have any evidence, just a hypothesis based by the fact they have low productity and work from home. If someone understood differently from me or noticed I might have skipped some information that made things make more sense, feel free to point it out, because I'm currently unable to see this as anything more than an inflamatory statement trying to bandwagon in a somewhat related hot topic with the goal of giving more publicity for his research that is not really related to the subject at hand.

[@rafaelbordoni516]

This is just a corporate weapon to justify attacking us. First of all, having a team with people that do all the work with a few coasters is nothing new in any field. You see these when you're a little kid in school, in competitive games/sports, in literally every profession ever and of course, managers. Even if this research is true, presenting it like this leads us to wrong conclusions. Look how much mental gymnastics they made to explain how they're "measuring productivity", here is a much more objective and easy metric to measure CEO productivity: how much money their company made/lost. If they did that, they would probably find even more damning results, with the folks at the biggest techs raking it in while a lot unicorn start ups and even literal fraudsters would make them look absurdly worse than us. They could have done that, presented all of this data and not even write any narrative, let people take their conclusions but noooo, let's just do it with programmers alone and not provide any other profession to give a point of reference, let's even give the coasters a name and estimate how much money they cost. My dude, Sam Bankman-Fried alone costed more than 10 bi, we're nothing compared to CEOs. Even if we remove the fraudsters, we're still left with pillagers like that board that pillaged Unity, the guy at Embracer and Ubisoft and even those that caused the 2008 crash. This paper is like "lying by telling the truth". At the end of the day, CEOs and investors don't really care about how productive we are, they're just scapegoating and looking for excuses to do more lay-offs, lower our salaries and take away our rights so they can stuff their pockets even more. They're the ones that are holding back progress, not us.

[@SpeakChinglish]

Imagine designing and architecting a project, then have others implement it. Only to find you are now a ghost engineer lol

[@Jonteponte71]

Well. You added no value. Sorry about that :)

[@d3stinYwOw]

@@Jonteponte71 Thing is - value was created, but without code. Code is not the only value, y'know?

[@Jonteponte71]

@@d3stinYwOw That was my point :)

[@ronjobs2359]

99% of Managers do literally nothing, next recent study.

[@akshat_tamrakar]

That's just a fact at this point

[@BryantSuiskens]

It's even worse, if you get surveys of manager opinion and actual correlations of productivity and employee retention, the average manager is essentialy a paid saboteur just there to ensure everyone is less productive and is constantly bleeding talent just so that the manager above them has a reliable yes-man who won't scream at them that their plans are unworkable and that there are about 6 billion people on earth who meet the qualifications of being "idea guys" with them easily in the bottom 5%, like any good senior engineer would

[@design.Engineered]

isn’t the dude that made the study trying to make a product to sell to big companies so they can justify their next round of layoffs?

[@inasuma8180]

no link?

[@padonker]

This is "normal" human behavior and not just in IT. And you can vilify the employee, but some hard questions remain for managers. All over the world there are employees that have been sidelined, shoved out, crapped on, etc. And there are profiteurs. For both groups working from home is a blessing. I wish the researchers would dig deeper and find out why this is happening. But that's hard over 50K respondents. I wonder how many real profiteurs are in this system vs people who've been pushed aside or otherwise sidelined. Especially large bureaucratic places of work can be killing. What if your work is being sabotaged by another department? Do you expect these people to just up and quit and forfeit their income? I'm guessing the problem outlined in this video is much smaller in startups because it's hard to be anonymous and keep getting your paycheck.

[@TheAtticus82]

Those numbers seem way, wayyyy higher than they should be. I’ve worked at 2 Fortune 100s and several very successful startups and never seen a person who did what the study is describing who wasn’t promptly fired.

[@tobiabidoye7548]

lmaoo advocating for more layoffs is insane in this market unreal

[@nwsome]

Laying off useless devs leads to more opportunities for good engineers

[@kiikoh]

​@@nwsome💯💯

[@jabbruh]

Yess omg 😂

[@Whatthetrash]

Its interesting that the metric is literally git commits. Is there nothing else to do to contribute at a company? A lack of git commits is a lack of work? Wow. Just... wow.

[@AlucardNoir]

If you're hired as a software engineer but haven't had to write a line of code in months you should probably consider wtf you're still employed. Imagine you got a job as a manager but had noone to manage or as a sales clerk in a store that had no clients. If you're hired as a programmer but your job does not entail coding... maybe someone else should be doing it?

[@warmbowski]

If they are counting Junior Employees, I can see this happening for remote Juniors at companies that don't mentor them. I feel that Juniors can't thrive without being directed and helped. Pair-programming would be great for remote Juniors.

[@arghya_333]

Watching this video after Primegen tweeted that "Statistics are used to lie" (paraphrased here but he said something similar)

[@Zuranthus]

sounds like a management issue

[@tauraamui]

Someone says something Theo: "This is TERRIFYING"

[@maccsguitar]

My take to this: I have been hopping to a new project every other month and there's a different stack in each project. Undocumented builds can take anything from a couple of minutes to couple of weeks to get running = no commits, learn the stack = minimal commits, learn the basics of the field the project is working in = minimal commits and a lot of talking, and then a while of productive work before the next small project. Commits do not tell anything about the work in question. Code reviewers would probably tell it was not that difficult without knowing I just hopped into the project. It's a whole lot different to work the same stack and similar projects than to switch everything constantly. If I was measured by those projects, I would probably be a "ghost engineer". If I was measured by hobby projects, I'd be looking a lot different.

[@Mempler]

I do lots of work... unless i need to wait for the pipeline because it's dead for an entire day and my MRs can not be merged ...

[@jpravetz]

1. It is suspicious that all the companies listed had similar ghost % 2. Where's the stats on the half life of a ghost engineer at the company. 3. Lots of places do regular bottom 5% pruning each year. 4. Between #2 and #3 I bet the story is not as sensational 5. I like the productivity measuring discussion. Measuring by numbers rather than contribution pairs well with scrums and jira mindlessness. 6. The problem isn't ghost engineers: it's the people who manage them. If they have ghost engineers then they deserve them. But unfortunately this demotivates those that "care", and jumping ship shouldn't have to be a solution.

[@soviut303]

It's because these companies don't know how to identify that "bottom 5%". If you've got people who are literally doing nothing that's a failure of management, not the developer.

[@jpravetz]

​@@soviut303i just remembered (because it's been awhile), but bad performers take a lot of time and effort if you want to weed them out. You and your good performers are sailing along, highly engaged, putting all your effort into making product. The bad performer takes so much effort to monitor. Or at least they can.

[@nekoill]

I'm sorry, but 1) how did they analyze private repos? Did they get permission from the repo's owner? It makes little sense to me, like who would willingly give access to their private repos knowing there's nothing to show there? 2) was Stanford the one in the middle of a research data faking scandal, or was it the one with tons of plagiarism? Kinda makes me personally take everything they claim with a fistful of salt

[@xevious4142]

Theo after listening to this video, and all the readiness to level judgment at your peers, you might think you got a warning from hr because you work too hard but I'm pretty sure you got warned because you're a jerk. Everyone has a life outside of work. You have no idea what people are dealing with whether that's illness, mental health challenges, kids, divorce, whatever. Seriously disappointed by your views on this.

[@jessemeyer3052]

What would be interesting to see is if these "ghost engineers" cluster under certain managers or departments. I would not be surprised if some of these ghost engineers are more indicative of a management or department culture problem. I've been at places with poor communication, lots of heavy business procedures, and poor meeting skills that make simple changes take a long time. Not to mention places where avoiding errors is more important than producing more. Even if a 3x engineer makes 50% less mistakes than a 1x engineer per line of code, they are still making 150% of the mistakes of the 1x engineer. While if a 0.1x engineer makes 50% more mistakes than a 1x engineer per line of code, they are only making 20% of the mistakes of a 1x engineer. Company culture can be very important.

[@toppojaiwant]

Welcome to the cruel reign of highly efficient algorithms! They decide how much lines of code have we written or how much sales have we made. This paper is a slap to all the managers. They're the reason for those ghost engineers. Simple principles like pair programming and extreme programming should be able to tackle this situation. Also I don't understand If my manager is an engineering manager with 16+ yrs of experience who doesn't write much code but contributes more to architecture/system design and delegates the programming part to us lead engineers. Does she come in those 10% of those ghost engineers?

[@AlucardNoir]

Honestly, I think it's a matter of what's written in her employments contract. Is she still counted as an engineer, or is she a manager? Imagine the manager of a fast food joint Vs that of a restaurant. In one case the "manager" is expected to still work the counter, in another the manager might be the head chef or they might be someone who just manages the restaurant financially, no cooking or serving involved. Is she supposed to be an engineer because she's both part of the team and the team lead? Then she's not pulling her weight. Is she supposed to be an engineer so she can actually understand what the team is doing but her role is purely managerial? She's doesn't have to write even 1 line of code. But is she did write just 1 line she'd probably make the list the video is all about...

[@masterp2k6]

Sorry but this is really superficial First off: What is considered an „engineer“? DEV/devops/architect/data-scientist/QA/data-engineer/db admin? In the real world there is no role clear role distinction! (See fullstack) What is considered „work“? Diagrams, configuration, pocs, prototypes, setup, commits, documentation? In the real world Not every dev Work Results in a commit! Also it depends on the Type of Work! I have Seen one character Commits in Security libs Taking long time vs. Tons of copy-pasta Code in Little time Also the Engineering world has way more Tools than just git… This whole thing is so useless Like discussing religion… An example Copy Paste Produces Bigger commits than Setting up a repository with a pipeline and make code reuse! We are brain workers! Not code monkeys! Sorry for the upper cases, I am writing with German autocomplete Fullstack is autocompleted to Superstar 😂

[@bvdlio]

Funny how a ghost writer does all the work, but a ghost engineer/programmer does no work.

[@bezimeni2000]

This is a fail from theo side. He didn't look at this critically at all

[@connorskudlarek8598]

TBF, if a reputable source like Stanford publishes, you expect them to not miss the ball so hard. Would be good to get a follow up vid to correct the mistakes. We all read something and misunderstand (and trust) what we're reading.

[@collinswisher6566]

​@connorskudlarek8598 This wasn't published by Stanford. In fact, the study hasn't even been published. All we have is the researchers tweet.

[@AshesWake-sf7uw]

Ah, so some MBA dude said it to gain clout for his article. No wonder

[@ianprice4460]

I don't blame the ghost engineers, I blame their managers. How on earth do the managers not know that someone is not working, be it office or remote worker

[@Jonteponte71]

This whole thing is based on the notion that *all* software engineers main task every day, seven days a week is to commit code. I haven't worked anywhere (yet) where that has been true. There is a long list of things that software engineers are responsible for outside of actually committing code. I feel that this is being completely lost here.

[@AlucardNoir]

The number of people in this comment section that seems to think it's ok to not write code as s software engineer is absurd. Yes, there are other things besides writing code, but that's like saying there's more to being a chef that cooking. Of course there is, but cooking is the core thing that's expected of you. The same for software engineer. The core of the job is solving problems using code. There's at least one person here that claims he knows 3 software engineers that haven't had to write any code in years because of documentation and planning. If you spend all your time washing dishes, maybe you should be the dish washer and not the chef?

[@gamer-gw9iy]

Be careful what messages you platform

[@Maxjoker98]

I can't agree more. I don't get why Theo is on the sides of managers that literately just want to fire more workers to have more cash(and no remote work! You have to suffer at work! After all, they paid for the office!!11!one!). I certainly can't take Theo on issues like this seriously. He's either bought or naive beyond believe. I'm not an "AI hater", but this is so obviously just an AI grift - "Fire more people by pretending it's data science! They didn't do anything anyway!". MBAs love it!

[@csYouTube19]

@@gamer-gw9iy you are just spamming comments begging him not to point out that tons of developers don’t do their job. It almost seems to me like you are a developer who doesn’t do their job This kind of thing doesn’t only affect managers. It also affects your fellow coworkers who have to work harder to finish projects slower because you don’t do anything

[@csYouTube19]

@@Maxjoker98 he’s not on the side of managers. He’s on the side of devs who actually do their job and who are negatively affected by coworkers who don’t help the team. And the ghost devs being referenced in the video are raging in the comments because they got called out

[@gamer-gw9iy]

@@csKZbin19 blah blah blah I hate people

[@junkz0r]

how does that compare with the rest of the industry? I don't think this is a software engineering specific problem, in fact i think it will be much worse for other industries/roles if someone looked into it

[@erikvinicius5]

This is incredibly weird. How can the managers of the big companies not know that their engineers are not performing? It’s weird to have an outside company do research for you in that regard. I’d tell you what. If those engineers are doing nothing and are still employed… what are THEIR MANAGERS DOING?

[@mikequinn]

If engineers are getting away with doing less work when working remote then it always comes down to poor management. Why are managers not looking at their employees output and taking them to task for not pulling their weight. We've always had slackers whether in the office or, we are all remote now, working remote. All the devs know who the slackers are but management have never addressed the issues for decades. The onus should be on the managers to fix this, just getting back to the office doesn't fix it and penalises those of us who are good productive developers. Most of our managers are Peter Principle in action.

[@szirsp]

4:30 claim: "9.5% of of engineers do nothing" - Theo: wow evaluation algorithm is 85% accurate... Wouldn't that mean if 100% of the people actually worked then the evaluation would still come up with the result: 15% of workers do nothing?

[@planesrift]

Now look at the management. 😊

[@the_disco_option]

Could you give me a list of these companies that give you a paycheck without ever checking if you've committed any code? I need it so I can apply.. I mean avoid them.

[@slimslither]

As an IC who ended up on a ghost team(switching next month) I would be interested in seeing the distribution by team/org. Once a manager lets a team gets to this point I imagine it is a very hard argument to make to HR to fire people at large companies. No one is clearly under performing relative to their peers. In my previous orgs a single ghost worker would have been weeded out quickly. So I suspect there are hot spots within a company.

[@TenFeetDown]

You believe this bs, you can't see the wheels moving under the surface of this nonsense?

[@steve_jabz]

10% of devs are based

[@PotatoGodzilla]

There is also the opposite. There are people who do things but do things literally in the worst way you can do anything, not even using chat gpt (which sucks and it's not 100%) but how can you be worse than chat gpt?

[@MadsterV]

yup. Normal distribution. There's highly active and highly inactive people. There's high quality and there's low quality.

[@NicolasRuizX]

Literally one my jobs they still pay me because without me if something fails they are fuck. I was asked to do one new feature in this entire year that took me 2 hours to complete. Although I don't feel bad at all because they fired my team and they keep applying for financing and getting it just so the CEO and his cronies keep paying themselves big fat checks while our massive sales team are underpaid. And the reality is that the company doesn't even need financing we don't even have a real burn down chart because it has been profitable for years. From my experience if a worker is unmotivated is 90% the fault of shitty company policies and environment. Remember guys, that Theo is now an "entrepreneur". He’s in the management side. I'm starting by unsubscribing.

[@HolyMacaroni-i8e]

Isn't that an awesome position to be in

[@NicolasRuizX]

@@HolyMacaroni-i8e yeah I didn’t said it to brag or anything. I was just trying to make a point that you can get the same statistics about any type of job. Remote or not remote, and the reason is not always because the worker is lazy or whatever the fuck Theo point was

[@henryvaneyk3769]

Using commits as a measure of an engineer's productivity is stupid. Change my mind.

[@Jonteponte71]

It IS stupid. It is also very typical American. Yes, I have worked at American companies. Unless the SEE you working, you are not working at all. I.e no trust. Like at all.

[@igotballs1]

Now show the percentage of ghost jobs

[@szirsp]

5:25 Yeah, my experience is also that working form home is more productive. Which is not surprising to me. I have watched TED talks about this subject, how interruptions, office meetings destroy productivity and burn company money. This was before the lock-down and remote work was a privilege. So people kinda had to be more productive to justify working from home. I heard the quote that "Half the job is showing up". If you show up in the office, then managers just assume that you are going to work. If they can't see you they might wonder, have mistrust. So you have to work harder, because from a subjective perspective even if you do the same amount of work you will be judged more poorly on performance (even more so when the amount of work done is not easily quantifiable). But home office is not for everyone. (Besides the obvious that not every job can be done from home.) Some people need the office setting or have too many distractions at home (children...) I also heard from CEOs that even though they want people coming back to office the data actually shows that remote work is more productive. The 2 doesn't necessarily contradict each other. It is also possible that there are more people who don't do anything when working from home, but overall productivity is still higher. Maybe it better if those people don't work, because they produce negative value (more work for others to fix). Maybe seeing those people in the office brings down work moral for the people who actually doing the job... It's insane to me how many people can do nothing valuable in office. They treat the workplace as a social gathering event: chat, hang out with coworkers, read facebook... if they were home alone they might get bored and actually do some work ;)

[@Deli5150]

What happened to the video where you were going to talk to the ceo of the browser company about whats going on with arc?

[@Skenvy]

There's typically a few things I'd disagree with but understand the takes, in an average theo vlog. This feels like an AI wrote a script based on the most reactionary and uncritically thoughtout snippets of other theo vlogs, with a directive to just assume the truth of a graphic in a tweet that confirms his bias that he's better than a bunch of what he already thought were "0.1x engineers." It's so undercooked that I can only assume this was sponsored by the mba that did the "analysis." 5:15 he even comes close to realising this but nah.

[@pablobenitonunez4159]

I watched 2 influencers react to the same paper, theo goes on about assuming the paper was well done and that what it says its true, because it aligns with his experience, no follow up, no challenges, just believing. This is just the latest spin of "if you are not head down in your desk you are not working" discourse, and its old. Jumping from the paper to a blog referencing the same paper as if its more evidence is disgusting. There probably is a conversation to be had about the style, rythm, and overall contribution of remote workers but this isn't the place to have it.

[@stephan553]

9:20 The fish rots from the head down. After enough roles and companies and levels, all from plain programming to CTO, I'm 200% on that one. If you have devs at or below 50% median performance, your management is not just as bad, it's worse than that dev performance. Don't believe me? Provide me the company and an appropriate hourly rate and I'm more than happy to prove you wrong... _and_ make you much more productive as well!

[@Pocketkid2]

I'm a firmware engineer at the bottom of the totem pole and honestly I don't see any true ghost engineers at my company, because my particular field requires more specific/niche skillsets, and my company is also global and has many projects and moves people and teams from project to project on a regular basis which keeps people from stagnating. But for most software-only companies I would not be surprised about this at all.

[@Feenskee]

With every upload, his head is in higher resolution, and at this rate, it’s going to come out of the screen eventually

[@bouncy-penguin]

This exists in every profession not just engineering and is insane to use this to try to justify the layoffs, a lot of the in office work is as well meaningless work very doubtful this is not just cooperate propaganda, 100 companies is nothing, and the definition is problematic to begin with, how did they calculate 10% what is the 10% lots of this isn't so easily quantifiable

[@turc1656]

Haven't finished the video yet, but the opening immediately made me think of Price"s law which states that half of all the value in the company comes from the square root of the number of employees. So 10 people produce half the value of a 100 person company. Which is terrifying. When you get to 10,000 people, a mere 100 produce half the value. This is theoretically because some people are super productive. But also there are things like compliance, HR, etc. that don't necessarily produce end value.

[@josephgonzalez9342]

I can't tell if I'm a ghost engineer. I get work done but I go through it so fast that I'm idle a lot. Being on an agile team doesn't help we only allocate work so far into the year. Plus, they 100% allocate my time to the project even though there's not that much work. I do get tapped a lot from coworkers from else where to consult on their problems though - that's the highlight of my day.

[@Jojor11]

I had an experience where we had a negative manager that was always Esther ignoring us or making it worse so it was really hard to ship the work we did, up to the point of a project being cancelled due to not being good enough… because it was missing features that were done and waiting for him for months… did he try and defend the work we did? Nope, he just agreed to cancel it, then told us it was cancelled and when we told him again the actual status he went “well, now it’s too late “ (he really didn’t want to tell his boss that he messed up). Some time after that we got some internal changes and got a different manager, who at least was not a negative… then he set a ghost engineer as a lead for the team, which didn’t know shit about the projects and barely knew some programming, but he got away with it by knowing how to look cool when the manager was looking… I really struggled to care about the work I do until I burned out and finally left the company, and still took some time to be back to be as creative and performant as I used to. This kind of people really can set up a team for failure by not only slacking, but making everyone else do worst

[@pencilcheck]

ahh, paid research... I understand there are people who don't do shit, so 0.1 engineers exists, but at the same time, those research are usually are paid to make research one sided so it can help companies to push their agenda such as the CEO to go to office to work (or justify to fire people and keep the people they like and can control). They also target engineers because engineers is 1) easier to find faults with as their work assignment is clearly measured (in the wrong way usually, like loc), 2) easier to collect data from because they are easier to get hold of, 3) lower rank in the companies nowadays. Otherwise we should see research in other type of positions as well, middle managers, PM, artists, desk receptionist, board of directors, CEO, etc. This happens in health/food industry a lot, same with tabacco in the past. All paid research and all have a specific agenda in mind.

[@arcuscerebellumus8797]

I'm not a full-time dev, and I'm also not in the US, so the specifics may differ, but in my line of work I still think that there's a big overlap. With that in mind, the best of my output ever - I did while I wasn't thinking about how much I was paid. And, true, being in a shared environment with other people really helps with that. However, being paid well enough to NOT think about money helps a whole-lot more. That is IF you're not a "developer for fun", and can function well past average while being practically glued to your chair and on a diet of coffee and candy-bars, like most of the greatest are. It takes a rare kind of HFA to be like that, though... PS: Talking about non-marginal components here. People who are actually useless (on the other side of the curve from HFA savants) DO exist, but in my experience, their number is vanishingly low and is as much of a product of mismanagement as it is inherent to the particular person in question.

[@diadetediotedio6918]

10:38 I'm not convinced, tho, that this covers the majority of the situations and explains how engineers in general work. For example, how many of those remote workers were hybrids and how much it affected the range? How much is feasible to just make a cut in the range of developers like you did and automatically lose the good engineers that would otherwise be willing to work in your company for the sake of it being remote work? That data per se is not sufficient to draw those conclusions.

[@jamesigoe]

The average does not get at the different drivers for remote work. When everyone works remotely, slackers take advantage, but normally, the best developers prioritize quality of life (QoL). There are divergent drivers for remote.

[@SuperGreat23]

Just so you know this is NOT a peer reviewed or published study with literally no documented historical data or links to specific methodologies used to come up with this number. Also the datasets mentioned are estimates which use NO REAL COMPANY DATA and uses odd metrics such as code quality of non company data and commits that are not weighted with any real financial or industrial impact whatsover. This article is snakeoil in order to attempt to go virial for an MBA that doesnt work in any feild or company and only at a university to gain noteriaty - basiclaly he just made up a viral sounding term and made some slideshows with magic projections with no datasets to back it up, no strict or even validated methodologies, no underlying publicly assesible paper, no sources, no publication, and no university backing for the validity of his "study"

[@BryantSuiskens]

A lot of this is just catastrophic mismanagement. In my current job, I am currently nearing a 0.1x output level simply because they hired 3 devs at 38h, and had perhaps enough work for for 1 38h dev and 2 24h partimers. Luckily my bosses figured this out too and we agreed they can duck my end of year bonus by sending me on my way and paying the termination fee instead. And due to how SWE works, you tend to get "problem spaces" where familiarity with certain parts of the codebase make it simply sensible for a certain member to do that unless they are already overloaded; and if your parts of the codebase are pretty much done that means you are just on maintenance or polish duty. Which in a smaller codebase quite quickly becomes purely reactive. So you typically just go through devs in sequence of assigned project importance and see them take up about 80% capacity before they consider delegating tasks. Not enough problem spaces to go around? Well, someone is gonna have to eat scraps, and it sucks ass.

[@ee8s]

If managers are not catching inefficiency, then it's a management issue. I feel like this whole paper is only looking at code output. How many engineers do nothing but attend meetings?

[@MarkWalsh-gc]

For real take on this 'study' it's worth checking out Alberta Tech's video, she has a short on it, but also a more detailed longform vid. She makes some fantastic points that are very well articulated. This video just feels more like a pile on.

[@vitorfontoura5417]

I think that working mainly in startups that might be true, but in the "real world" we have a lot of legacy code, the big companies presented in the study are surely not an exception to this and managing to understand and solve problems in those legacy codebases is something that has less to do with commits and more with reading and understanding other people code. The majority of engineer positions today work with legacy code, and comparing it to startups and green fields just seem unfair

[@kocokan]

As a jobseeker, what can i do to make sure the job i apply consist of high performers who are not just idlying by?

[@hundvd_7]

12:44 _Definitely_ disagree with this. Basically half our team is a low performer. Including myself. But all of us watch videos like yours. We all like this profession. We care about it. But our _job_ is totally different. I have only ever used React and Angular at work, for example. And the backends I've tangentially touched have also only been old PHP and even older Java. There is no excitement in it. Just making/using a terrible API for an app you don't care about, for a user base that won't notice it, running on a server that's too slow for its own good, while fighting the company infrastructure every hour of every working day. But this is where the money is. And this is what 90% of software engineers do. _We don't work on startups._

[@Kamil-mw9jw]

Commits are not everything - it depends on the project, less people - less commits - this is what I observed, anyway 2-3 commits a month is still an extremely small number. I'm working remotely for the company in the US for $100k, ~9h/day, as a senior FS with over 15 years of experience and I'm shocked that people get 200-300k for doing nothing. That's sad...

[@haveboard]

couldnt this be similar to measuring lines of code written/committed. or the devs that are doing work in the background not as easy to measure?

[@heatwaveo8]

Other research I've come across has shown that many managers are "disoriented" when doing remote work. In other words - they don't know how to manage without people being there. So what happens? They don't know where to start, and the developers suffer for it. Then as the developers are asked to return to the office, this can lead to a perception that the manager is controlling, making them unhappy and less productive. That's partly why the chart is how it is. That said, I think a good portion your video is mostly baloney, especially about the reasons for the numbers. The responsibility for this falls on the business and the managers, for not accurately presenting how the job would actually be; or because they later learn that the manager wasn't the kind of person they presented themselves as. The 58% group are often people that are "asked" to fix bugs, i.e. complete maintanance. The reason for this is because they are working on projects that largely were completed already, or projects that were completed over 10 years ago by teams that didn't know what in the world they were doing while completing their code. And then there is the Senior Developer who won't take the time to pass along some of their work to the Junior or Mid-Level Developer. And yes, there are UX Designers who are very abstract at times, so asking for clarity on spec requirements is very common in the corporate world. Where I do agree, is that for these reasons, companies are often over-hiring. I also agree that letting workers go from these companies would provide a lot of opportunities to create new small businesses who do things right in the modern age, including great remote-capable leaders and managers who can provide more than enough work for remote developers. If the developers are given nothing to do, though, they can't be blamed for that, and some of the numbers stated here may include that.

[@Ratstail91]

Theory: Those who work best at home should be working at home, and vice versa.

[@SirCorrino]

I think some of it is also quality of your home setup. When I had a shitty home setup for working I got a lot less done than in the office. Now with a good setup with a proper home office I get a lot more done when I'm at home than I do in the office.

[@ColorNerdChris]

The follow-up to this study that I want to see: Correlation of 0.1X Devs to "Nobody wants to work anymore" managers and 5X Devs to "LFG" Managers.

[@BrennanFalknerDev]

I really need to find a 200k job. I write way more than 3 lines and make shit.

[@gsgregory2022]

I don't get why this is surprising. This is true in all industries and jobs and is the direct result of bad management. When I was a welder there were times when half my job was doing the work that should of been done or didn't get done correctly because we kept useless people on. My favorites were those that would nap in some corner of the shop. Being in devops now there are developers, various business people, managers and sometimes entire teams who occupy the list of absolute uselessness. My favorites are the ones who won't do anything unless forced to.

[@paulduffy9481]

Given the state of both Twitter and Tesla, maybe don’t rely on Musk’s actions to back up a theory. I mean, he slagged of the overwhelming majority of their revenue stream and ad revenue is projected to be halved by 2027. Meanwhile he shut off the copyrighted works detection system because he doesn’t know what anything does and got everyone locked out of the building by firing the people who kept security working. Both of these cases are a result of picking a number out of the air and nothing to do with performance. This is the guy who got a contract at PayPal that made him impossible to fire and somehow got fired in just 4 months; man's a ghost himself.

[@herranonym5725]

In my experience, engineers are usually much, much lower in this spectrum than many other jobs. I've had a previous job where I was the only one actually producing things and I had 3 managers arguing for over an hour about meaningless stuff like if a certain button should be blue or red and when asked about specific functionality they had no feedback. I've had like 1 good manager in my 12+ year career and honestly the bullshit job factor is high as fuck in todays society and that 's why stuff ain't working like it used to. There is bullshit everywhere but it's insane in the public sector and at large companies. I ventilated my feedback after attending a 2 day workshop of bullshit where I gave the feedback that is was meaningless and got fired shortly after that. Inefficient managers want yes-sayrers and if you try to change stuff you will possibly get the boot for it. I have been a 10x engineer and a 0.1 engineer multiple times and it is mostly about the environment. If you have a productive environment, I am productive but if I feel like no one else cares, there is little motivation for me to care. The funny thing is that the times I've been the least rewarded is the times I've been most productive. We have a society in the west that rewards inefficiency unless you are a small company.

[@noriller]

5:22 if the argument agains remote is that 14%, then what about the 6% on office and 9% hybrid? If they can't see those presencially, then what cause they have be them remote or not? I say this because, most likely, when it was all on office... those on-office numbers would be a lot higher... today, those same people just get it easier being remote. Even if they layoff 50% off all companies, the ones already overworked by those ghost will just have to pick up the slack and burn faster. Not to mention the many companies that hire a lot of people solely on leetcode skills.

[@stephenjames2951]

People who are self-driven are definitely going to thrive remotely as they get at minimum an extra hour a day not commuting. Where I work we have failed to adapt well to fully remote and our spread of productive vs. less productive developers is wide. For me this is a management issue as much as a developer issue. The need for accurate measures of productivity that are measureable, but less gameable are required. That is hard work and too often management is unable or unwilling to do that.

[@xliquidity3914]

The article is misleading. It was written by an MBA, not another developer. Measuring commits is not a way to judge a software developer. We aren't "coding monkeys".

[@nicejungle]

Only 10% ? I worked at some big companies where it's more like 50% Though most of the time, it's because of bad managers

[@dough-pizza]

I've been in an interview panel for my current and previous organisation and I'll say this hiring is tough man! After interviewing 10-15 people you'd maybe see 1 who has a glimmer of hope of performing well and I'd imagine less motivated interviewers just hiring anyone because after each rejection the pressure from management mounts to just hire somebody That said this goes in reverse as well. Since hiring is hard companies should think very hard in regards of who they're firing or they are in for a bad time

[@RoyaltyInTraining.]

If this number is true, it's mostly the fault of the companies. It's natural that if they treat their engineers like code-generation machines, they'll be miserable at the job and not want to do anything. I've seen the other extreme of the spectrum too though. The company I work at now gives their staff enough freedom to make solving problems seem fun, and I actually love working there.

[@cardboardmountain]

Raise your hand if you've spent 5+ days researching and troubleshooting an issue, only to realize it can be fixed by changing one line in a config file. Raise your hand if you have ever had/been a technical lead who works their ass off, but barely writes code any more. Even devOPs people can spend a month on a dozen lines of json changes. This is total management bait that does not even pass the smell test. Who are the people doing pull requests for commits where you change one character?

[@LuminousVoyage-o5g]

Sure do love Theo’s anecdotes presented as the “real world”

[@stephenjames2951]

Well done on identifying your bias in this area.

[@MSheepdog]

If 10% of your employees are doing nothing, you need to fire you're managers. That sort of inactivity should absolutely be noticed by someone within a few months.