Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Programming

Stanford Research Reveals 9.5% of Software Engineers 'Do Virtually Nothing' (x.com) 237

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.
This discussion has been archived. No new comments can be posted.

Stanford Research Reveals 9.5% of Software Engineers 'Do Virtually Nothing'

Comments Filter:
  • by drinkypoo ( 153816 ) <drink@hyperlogos.org> on Tuesday November 26, 2024 @09:03AM (#64973217) Homepage Journal

    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!

    • Lots of irony. I suggested years ago that the companies themselves... Google, Apple, Amazon, etc will BECOME SENTIENT at some time in the future. The implication is that the easiest jobs to automate would be the management functions. I'm still of the opinion that because programming, networking, security, system operations, etc, etc, require deep and specific technical multidomain knowledge that they will be the hardest, and take the most amount of time to truly automate away from humans.

      Also, could we agre
    • by Pieroxy ( 222434 )

      Wat metric would you have the LLM look for exactly to figure out automatically that someone is slacking off ?

      • 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.

      • 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.

    • 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.

    • 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.

      • 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.

      • by PPH ( 736903 )

        You don't really want to waste [wikipedia.org] a good programmer on management duties.

    • by stripes ( 3681 ) on Tuesday November 26, 2024 @10:05AM (#64973415) Homepage Journal

      Their managers don't seem to be able to figure out they are doing nothing

      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.

    • 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 /?

    • Number of commits, or number of lines committed does not indicate how valuable an engineer may be. There are so many times where after evaluating the issue that needed to be fixed I've removed hundreds or thousands of lines of code that code monkeys wrote to replace it with a short chunk of code that resolved the issue and is significantly more efficient.
    • by Kisai ( 213879 )

      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

  • Ads (Score:2, Informative)

    by Calydor ( 739835 )

    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?

    • yeah.
    • 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.

      • by Calydor ( 739835 )

        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.

        • 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.

          • by Calydor ( 739835 )

            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.

            • by Malc ( 1751 )

              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.

            • Ublock origin still works in Firefox :3
            • 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:5, Informative)

          by Bradac_55 ( 729235 ) on Tuesday November 26, 2024 @09:51AM (#64973375) Journal

          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.

    • by khchung ( 462899 )

      Yeah, my adblocker cannot block the new ads.

    • 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?

      Yup...just started here today...using Safari and Adblock.

      It sucks....ads are WAY too big and intrusive.

  • net nuetral (Score:5, Interesting)

    by kick6 ( 1081615 ) on Tuesday November 26, 2024 @09:05AM (#64973227) Homepage
    I wonder what the percentage of engineers who actually "do something" but their code is so shit that they're actually a net negative?
    • Approximately the same percentage that was outsourced to low cost countries.

    • by CAIMLAS ( 41445 )

      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.

    • They provide a valuable source of jira bug stories

  • TV (Score:5, Funny)

    by fluffernutter ( 1411889 ) on Tuesday November 26, 2024 @09:06AM (#64973229)
    That's why I insist on working from home. What's the point of doing virtually nothing if you can't watch TV?
  • by Joe_Dragon ( 2206452 ) on Tuesday November 26, 2024 @09:08AM (#64973239)

    I'd say in a given week, I probably only do about 15 minutes of real, actual work.

  • by Joe_Dragon ( 2206452 ) on Tuesday November 26, 2024 @09:09AM (#64973245)

    TPS reports don't show up in code commits!

  • by wokka1 ( 913473 ) on Tuesday November 26, 2024 @09:11AM (#64973249)

    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)

    by Ol Olsoc ( 1175323 ) on Tuesday November 26, 2024 @09:11AM (#64973251)
    That a significant number of people who aren't actively supervised are not working?

    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)

      by timeOday ( 582209 ) on Tuesday November 26, 2024 @09:29AM (#64973309)

      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.

      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.

      • 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.

        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.

      • There's a similar phenomenon at a higher level. It's called a migration. That's when everything works fine, but you have to spend six months rewriting it in a slightly different way and rediscover all the bugs that were fixed 3 years ago along the way. Management is usually on board with this.
      • A more subtle kind of non-productivity in engineering jobs is "scratching the itch" too much

        We're talking about nerds, not jocks!

    • by TWX ( 665546 )

      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

      • 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.

    • I can do nothing in the office just as easily.

  • by redmid17 ( 1217076 ) on Tuesday November 26, 2024 @09:12AM (#64973253)
    This is a shitty slashvertisement parading as legitimate research. They are using an LLM, which are not good at building or analyzing production level code, to replicate the work of 10 actual expert developers and are scraping public GitHub repos and trying to aggregate that data against publicly available emails and job titles.

    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]
    • I was surprised this is purported to be research from Stanford but when I click the link all I see is a cutely-formatted Tweet with no link to any paper?
    • by godrik ( 1287354 ) on Tuesday November 26, 2024 @09:34AM (#64973325)

      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.

      • "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.

        • 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.

          • "The result of all this was that it didn't look like we were working very hard at all. [blogspot.co.uk] I went home at 5.30pm, I never worked weekends, we didn't spend hours crowded around each other's desks throwing out guesses about what could be wrong with some failing production system. From the outside it must have looked like we'd been given a far easier task than the analogue TV guys. In truth, the requirements were very similar, we just had better designed and implemented software, and better supporting infrastructu

  • by timeOday ( 582209 ) on Tuesday November 26, 2024 @09:14AM (#64973259)
    It would be so interesting if they could follow up on about 100 of these to see what the story is.

    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).

    • by TWX ( 665546 )

      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.

  • by DarkOx ( 621550 ) on Tuesday November 26, 2024 @09:17AM (#64973267) Journal

    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)

    by Lavandera ( 7308312 ) on Tuesday November 26, 2024 @09:17AM (#64973269)

    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...

  • ...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.

    • by TWX ( 665546 )

      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.

  • 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)

    by ElizabethGreene ( 1185405 ) on Tuesday November 26, 2024 @09:32AM (#64973317)

    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.

    • Those are good points. Also, consider that the better I get at my job, the smaller my PRs become. As I learn more, I learn how to leverage existing libs more as well as get the same work done with smarter, tighter code. So the junior or shitty programmers have massive PRs with lots of poorly implemented code because they don't know how to use the APIs well.

      Another: legacy code. Did you search the FULL history...including the deleted files? If not, my most senior teammates in tech lead roles would
  • Either link to the study or this is to be presumed fake.
  • by CEC-P ( 10248912 ) on Tuesday November 26, 2024 @09:40AM (#64973339)
    First of all, it's an ad masquerading as news. But secondly, how is it even possible to have a corporate structure where you turn in no employee software capability surveys, change notes, patch notes, security-anything, write any code, and nobody notices. I do not believe this unless the company is a chaotic mess and they'll fail anyway if that's the case.
    • by Junta ( 36770 ) on Tuesday November 26, 2024 @10:21AM (#64973463)

      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.

  • 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?

    • by Baron_Yam ( 643147 ) on Tuesday November 26, 2024 @09:49AM (#64973371)

      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.

  • by Jayhawk0123 ( 8440955 ) on Tuesday November 26, 2024 @09:48AM (#64973367)

    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.

    • by Junta ( 36770 )

      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.

  • by Big Hairy Gorilla ( 9839972 ) on Tuesday November 26, 2024 @09:51AM (#64973377)
    Software stopped improving in terms of useful features around 10-15 years ago. Until that time improving core functionality was the priority. Approximately corresponding to the quick popularity of the iPhone, and the implementation of data gathering/surviellance as the most attractive business model. All the "upgrades" in the last, say, 7 years, have been additional surveillance functionality benefitting the data gatherer, not the end user. Forced upgrades every 3 months or less is now the norm, we all hate it, even regular chumps. Goo and App have figured out how to shove it on your device, literally, while you're asleep. (A/B partitions on Android for instance). Anyone who can still think, knows we don't need upgrades every 3 months. Look at the ballooning size of the binaries. My browser (fulguris) is about 5mb binary, Brave browser is >250mb... why is it 20x larger? YOU don't need the additional 95% of the code.

    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!
    • by JustNiz ( 692889 )

      >> 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

      • I'm listening.... LLM's are smoke and mirrors, imo, that sucked all the air out of the room. So where's the new stuff happening?
        Medicine? Astronomy? Seriously, I'm listening...
  • 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 than the ones who are actively screwing code by not understanding the problem they are solving or just not being able to code worth a damn. Over my career as a consultant I’ve more than once had to tell a customer I could fix a particularly bad piece of code with several days effort or just rewrite it properly from scratch in about 1/3 the amount of time.
  • by JustNiz ( 692889 ) on Tuesday November 26, 2024 @10:16AM (#64973445)

    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.

  • by khchung ( 462899 ) on Tuesday November 26, 2024 @10:23AM (#64973471) Journal

    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.

    • by PPH ( 736903 )

      I'd mod you up, but I can't find where they put the +1 insightful button.

  • 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

  • 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.

  • by Travco ( 1872216 ) on Tuesday November 26, 2024 @11:14AM (#64973619)
    Were their numbers day to day? week to week? year to year? I've known Engineers that did no work whatsoever and I've known Engineers that did what APPEARED to be a tiny bit of work but it was the work that kept everyone else out of trouble. And then there's the people who do a whole lot of work, that does nothing but cause problems. And of course the managers who are utterly incapable of telling the difference between these people.
    • 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

  • Do nothing is relative. Marketing wanks do less if they're the bad ones, which many are.
  • by AmazingRuss ( 555076 ) on Tuesday November 26, 2024 @11:56AM (#64973721)
    ... and make some rich prick a little more money, or you can slack, and the rich prick has to hire more engineers, who are then able to feed their families, and the rich prick gets less. Slacking is starting to look like a moral imperative.
  • by MNNorske ( 2651341 ) on Tuesday November 26, 2024 @12:40PM (#64973845)
    This is a horrible metric to measure. Git commits do not in fact equal work done in all circumstances. And, number or size of git commits most definitely does not equal quality of code.

    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.
  • by RogueWarrior65 ( 678876 ) on Tuesday November 26, 2024 @12:50PM (#64973867)

    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.

  • by King_TJ ( 85913 ) on Tuesday November 26, 2024 @01:30PM (#64973975) Journal

    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 ....

Hackers are just a migratory lifeform with a tropism for computers.

Working...