Stanford Research Reveals 9.5% of Software Engineers 'Do Virtually Nothing' (x.com) 211
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:4, Interesting)
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:3)
Also, could we agre
Re:Replace managers with AI (Score:4, Funny)
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:3)
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:Replace managers with AI (Score:5, Insightful)
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 get replacement headcount, maybe an employee that has 50% the bug close rate of the average employee be better then not having that employee at all!)
There is also the possibility that the employees with low close rates are assigned much harder bugs because they can close them while other employees can’t. Or they are assigned less coding assignments and more design and/or documentation, or have some other set of not reflected in the git tree work.
Long ago I worked at Apple, and I didn’t have a huge amount of kernel experience, but I was half of the team implementing sandboxing, so we had some pretty far reaching kernel changes. I ended up committing a lot of bad bugs. I fixed basically all of them. It gave me a fantastic P2 fix rate. I got an award for it (and a free wheel of cheese!). I don’t think it was actually a good year for productivity. I committed a lot of bad code, and patched it all up again. Most of the time I commit a lot of reasonable code and it doesn’t need as much bug fixing, or at least it’s bug fixing isn’t critical panic fixes. Stats wise committing sub par code and fixing it was much better for me (the wheel of cheese also came with a monetary bonus, or at least that year’s bonus was much bigger then many other years at Apple). So I’m not wild about trusting automated stats for real evaluations. It is possible the low-commit-rate employees are slackers. It is also possible that they commit better then average code and have fewer bugs to fix, and also that the features they commit they do in smaller and less complex amounts of code because they think it through better.
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 /?
Re: Replace managers with AI (Score:3)
Re: (Score:3)
Eh, not quite.
I think if these companies decided to suddenly fire all those engineers, they would quickly find the servers or software down because their job has literately been "press the button every X hours"
https://lostpedia.fandom.com/wiki/Pushing_the_button
I know so, because my 'job' is like that. Every time I take a day off, or go to a wedding or a funeral, something business-damaging starts happening because I'm not monitoring things.
I had chaos happen and I had not even been on the road for 20 minut
Re:Managers often know the under performers (Score:4, Interesting)
I had a developer on my team that was very mediocre and all he could do was write reports. But he was happy doing it. When layoffs came, he got let go and then the remaining (higher performing) developers had to take over writing reports. One by one they got bored and quit. The company lost a couple rock star developers because they fired the underperformer.
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:3)
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:Ads (Score:4, Informative)
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:3)
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:4, Funny)
TPS reports don't show up in code commits!
Re: (Score:2)
Not just software engineers (Score:5, Informative)
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.
Who knew? (Score:4, Insightful)
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)
A more subtle kind of non-productivity in engineering jobs is "scratching the itch" too much
We're talking about nerds, not jocks!
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:5, 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)
Roles (Score:3)
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 to adjust roles etc, so it is for an individual in a job... work has ups and downs so sometimes you have slow periods (or are doing busywork, whether or not you know it).
Re: (Score:3)
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:5, Interesting)
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...
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:4, Funny)
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:3)
Another: legacy code. Did you search the FULL history...including the deleted files? If not, my most senior teammates in tech lead roles would
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:5, 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:The corporate process at work. (Score:5, Insightful)
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:4, Insightful)
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 doing what is asked of them in minimal time and the rest is free time.
In either place, it's not on the employees to simply "look" busy. it's on the company to ensure the employee is utilized to their potential and not burned out with too much work, there needs to be some slack for a system to work efficiently. To blame them for the company being incompetent is focusing the blame in the wrong direction. But then again, shit always rolls down in corporate.
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:5, Interesting)
Basically, there's is NOTHING new under the sun in terms of software for many years now... what chumps see is just a rearrangement of the deck chairs to give the illusion of progress and improvement... explaining why a good chunk of software developers, really don't know their tradecraft, and underperform. I have read in these pages from others still in the thick of things in SV, that the biggest companies have been hiring "defensively" for years, just to keep (supposedly) qualified people away from each other.
Coupled with lower and lower educational standards, DEI policies, lowering the bar for entrants in education and at the Big Co's, you get stagnation. Make work projects for underqualified people... Who probably thought IT was a meal ticket and weren't suited for it in the first place.
LLM's are marketed to billionaires and hedge funds as a place to place money, and the "benefits" to chumps is near nil. The flooding of the internets with generated propaganda and new automated criminal activity, the main use case of this crap is to impersonate someone else. You can impersonate another person with 1 facial photograph, or <30 seconds of audio.
Software stopped improving 15 years ago. Core functionality is swamped with garbage, illusions, and surveillance.
Let the downvotes begin!
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:3)
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 listen or learn and every 7 or so years some bright new spark tries and fails again.
I bet those UI changes count as productive (Score:3)
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.
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:3)
Re: (Score:3)
Indeed. I'm just a dev, but I have weeks with no real output code wise because I'm being called into or scheduled for 30 minute meetings every hour or so. So actually getting into the IDE and starting to write code without being interrupted for the next meeting/call so I have time to actually write some code and get some stuff done is kinda tough at times.
But since my boss and his boss are the ones calling me or having me join these meetings, etc. they know about it and it isn't an issue (usually. Kinda
I'd still fire 80% of marketing first (Score:2)
You can bust your ass.... (Score:4, Interesting)
Git commits != work done (Score:3)
Some of the worst engineers I know will vomit out code non-stop. But, it is just that. Vomit.
The engineers who are building quality code tend to take a bit more time on their work. They test it. They find the bugs before they make a pull request.
Additionally different teams have different models of how they do pull requests. I know several teams who branch code at the start of a sprint and won't make a pull request until the end of the sprint. That is two weeks in which they may be making a lot of local changes without the activity showing up in git. I prefer to make smaller stories so my engineers have more frequency of activity, and each pull request is smaller and more readable. So the engineers on my team tend to have more git activity.
Also, as a lead engineer I spend a considerable amount of time doing analysis, reviewing pull requests, writing up stories for work to be done, and coaching the team. That means my productivity as measured in git commits will bounce up and down a lot over time. Sometimes I even just pair program with my more junior engineers and they get all the git credit for the commits made because I want them to learn and grow so they are more productive.
Ultimately speaking managers and lead engineers simply need to understand the work being done and be able to speak to it and justify it. If they cannot enumerate the work being done or justify it then there is a problem. If you're going to sit there and try and measure work done by git commits you're going to miss the mark hugely.
Define "minimal" (Score:3)
How do they define minimal? What most people don't understand is that it's perfectly normal to see an engineer with their head on their desk because they are thinking about how to solve a problem. They also don't understand that the number of lines of code produced is well documented and it's a very low number. By contrast, I have seen non-technical employees do nothing but spend an entire day updating their day planner.
Meh... IBM is no great example here (Score:3)
IBM, in my opinion, has got to be one the biggest management failures on the planet, despite somehow staying alive and even occasionally relevant.
I mean, we're talking about the company that built the only commercial OS for a standard PC that truly provided competition with Microsoft Windows while even retaining Windows app compatibility. OS/2 should have been a home run for IBM, but instead? They did everything wrong to make it fail, including selling a line of desktops that came pre-loaded with Windows NT *and* weren't even OS/2 compatible!
This is also the business that created the Thinkpad laptop, considered the industry standard for business use. So what do that do? Sell the whole thing off to the Chinese, for Lenovo to make them.
Let's not even talk about things like them having the world-leading spreadsheet product with Lotus 1-2-3 and allowing Excel to take their entire customer base away from them on that one.
The claim they've got some non-zero percentage of remote devs not doing much work seems incredibly predictable and obvious ....
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