9 ms·

I have been in the workforce for almost 30 years now and I believe that everybody is getting more squeezed so they don’t have the time or energy to do a proper

I have been in the workforce for almost 30 years now and I believe that everybody is getting more squeezed so they don’t have the time or energy to do a proper job. The expectation is to get it done as quickly as possible and not do more unless told so. In SW development in the 90s I had much more time for experimentation to figure things out. In the last years you often have some manager where you basically have to justify every thing you do and always a huge pile of work that never gets smaller. So you just hurry through your tasks. I think google had it right for a while with their 20% time where people could do wanted to do. As far as I know that’s over. People need some slack if you want to see good work. They aren’t machines that can run constantly on 100% utilization.

Avicebron 1y ago
The article addresses the fact that it's more of the "job" that the software company provides as an extension of their services isn't really a "job" a la "SW development in the 90s" It's the after effect of companies not being penalized for using the exploitation dragnet approach to use people in desperate situations to generate more profits while providing nothing in return.
kunzhi 1y ago
Only 20 years for me, but this is my observation also.
temporallobe 1y ago
This is my experience as well. In the late 90s/early 2000s I had the luxury of a lot of time to deeply and learn Unix, Perl, Java, web development, etc., and it was all self-directed. Now with Agile, literally every hour is accounted for, though we of course have other ways of wasting time by overestimating tasks and creating unnecessary do-nothing stories in order to inflate metrics and justify dead space in the sprint.
- TuringNYC 1y ago
  >> literally every hour is accounted for I saw one company where early-career BA/PMs (often offshore) would sit alongside developers and "keep them company" almost all day via zoom.
  - AtheistOfFail 1y ago
    Yep, that would be my own personal hell.
  - latentsea 1y ago
    I would just terminate the call. Like... hell no.
  - AnimalMuppet 1y ago
    Everyone's complaining about that as a developer, and rightly so. But that can't be easy for the PMs, either, trying to find a way to "add value" when they have no idea what's going on. I'd expect there to be some "unexpected network outages" regularly in that kind of situation...
  - MikeTheGreat 1y ago
    Twice the billable hours! /s
  - dyauspitr 1y ago
    This is kind of cool as an alternative process to develop apps with. Literally product in a zoom window telling you what to build as you go along. No standups, no refinement, no retros etc. Just a PM that really knows what the customer needs and the developer just building those as you go along.
    - PessimalDecimal 1y ago
      No. It's just awful.
    - arvinsim 1y ago
      No developer wants to being treated as a code monkey and I bet no PM would want to waste time watching someone type out code that they don't understand.
- ecocentrik 1y ago
  If you're creating nothing stories to justify work life balance and avoid burnout your organization has a problem. Look into Extreme Programming and Sustainable Pace.
  - RobRivera 1y ago
    I think thats the observation being made. Most people respond to the organizational problem with the only tools they have, which manifests as that. Usually management knows and doesnt care about the problem
    - ecocentrik 1y ago
      ---
- singpolyma3 1y ago
  And yet well over half of professional developers have productivity so low that if they get laid off the term gets the same amount done...
the_cat_kittles 1y ago
sounds like bit of a death spiral
mschuster91 1y ago
> In SW development in the 90s I had much more time for experimentation to figure things out. In the last years you often have some manager where you basically have to justify every thing you do and always a huge pile of work that never gets smaller. Software development for a long time had the benefit that managers didn't get tech. They had no chance of verifying if what the nerds told them actually made sense. Nowadays there's not just Agile, "business dashboards" (Power BI and the likes) and other forms of making tech "accountable" to clueless managers, but an awful lot of developers got bought off to C-level and turned into class traitors, forgetting where they came from.
- potato3732842 1y ago
  I commend you for having an opinion so bad I can't tell if you're satirizing marxists or not. Let me ask you this, would you rather be managed by a hierarchy made up of people who don't understand what you do? Because I assure you it is far worse than being managed by "class traitors".
  - bryanrasmussen 1y ago
    well, not the original poster, but I have been managed by both kinds, and the best manager I ever had was not a former techie and the worst was a former programmer. The worst manager did often say things that were sort of valuable and correct in a general way, like "well you don't actually know that because it hasn't been tested" which was of course true, but he also seemed to think he could tell people what the correct way to do something was without knowing the technology and the codebase. This often meant that I had to go to junior developers later, after a meeting, and say "concerning ticket X, T. didn't consider these things(listing the things), so that while it is true that we should in principle do what T. said, it will not be adequate, you will also need to do this - look at the code for this function here, it should be abstracted out in some way probably, this was my crappy way of handling the problem in desperation Y months ago." Trying to explain to him why he was wrong was impossible in itself, he was a tech genius evidently, and you just had to give it up after a bit, and figure that at some time in the future the decisions would be reversed after "we learned" something.¨ on edit: in the example I give the manager as I said was correct in what he wanted done, but as I said it was inadequate as the bug would keep recurring if only that was done, so more things had to be done that were not as pretty or as pure as what he wanted.
p1necone 1y ago
> In the last years you often have some manager where you basically have to justify every thing you do and always a huge pile of work that never gets smaller. So you just hurry through your tasks. This has been my exact experience. Absolutely everything is tracked as a work item with estimates. Anything you think should be done needs to be justified and tracked the same way. If anything ever takes longer than the estimate that was invariably just pulled out of someones ass (because it's impossible to accurately estimate development unless you're already ~75% of the way through doing it, and even then it's a crapshoot) you need to justify that in a morning standup too. The end result of all of this is every project getting bogged down by being stuck on the first version of whatever architecture was thought up right at the beginning and there being piles of tech debt that never gets fixed because nobody who actually understands what needs to be done has the political capital to get past the aforementioned justification filter.
- marginalia_nu 1y ago
  It's fascinating that you end up sort of doing the work twice, you build an excel (or jira) model of the work work along with the actual work to be done. Often this extends to the entire organization, where you have like this parallel dimension of spreadsheets and planning existing on top of everything. Eats resources like crazy to uphold.
  - pjot 1y ago
    This compounds with each _team_ modeling the work in jira/excel too!
  - squiggleblaz 1y ago
    Yes but metrics! How can the CEO look like they know what's happening without understanding anything if they don't have everyone producing numbers?
  - spudlyo 1y ago
    Jira is already almost like "productivity theater" where engineers chart the work for the benefit of managers, and managers of managers only. Many programmers already really resent having to deal with it. Soon it will be a total farce, as engineers using MCP Jira servers have LLMs chart the "work" and manage the tickets for them, as managers do the same in reverse, instructing LLMs to summarize the work being done in Jira. It'll be nothing but LLMs talking to other LLMs under the guise of organizational productivity in which the only one deriving any value from this effort is the companies charging for the input and output tokens. Except, they are likely operating at a loss...
Sparkyte 1y ago
Definitely squeezed. They say AI, but AI isn't eliminating programming. I've wrote a few applications with AI assistance. It probably would've been faster if I wrote it myself. The problem is that it doesn't have context and wildly assumes what your intentions are and cheats outcomes. It will replace juniors for that one liner, it won't replace a senior developer who knows how to write code.
- NERD_ALERT 1y ago
  I felt this way with Github Copilot but I started using Cursor this week and it genuinely feels like a competent pair programmer.
  - deleted 1y ago
    [deleted]
  - Retric 1y ago
    What work are you doing the last few days? My experience is for a very narrow range of tasks, like getting the basics of a common but new to me API working, they are moderately useful. But the overwhelming majority of the time they are useless.
  - jdcasale 1y ago
    I recently tried Cursor for about a week and I was disappointed. It was useful for generating code that someone else has definitely written before (boilerplate etc), but any time I tried to do something nontrivial, it failed no matter how much poking, prodding, and thoughtful prompting I tried. Even when I tried to ask it for stuff like refactoring a relatively simple rust file to be more idiomatic or organized, it consistently generated code that did not compile and was unable to fix the compile errors on 5 or 6 repromptings. For what it's worth, a lot of SWE work technically trivial -- it makes this much quicker so there's obviously some value there, but if we're comparing it to a pair programmer, I would definitely fire a dev who had this sort of extremely limited complexity ceiling. It really feels to me (just vibes, obviously not scientific) like it is good at interpolating between things in its training set, but is not really able to do anything more than that. Presumably this will get better over time.
golergka 1y ago
How much more expensive is your time for the company now vs the 90s?
- bryanrasmussen 1y ago
  counting in cost of living increases? Probably about the same.
dwattttt 1y ago
> People ... aren’t machines that can run constantly on 100% utilization. You also can't run machines at 100% utilisation & expect quality results. That's when you see tail latencies blow out, hash maps lose their performance, physical machines wear supra-linearly... The list goes on.
- dehrmann 1y ago
  The standard rule for CPU-bound RPC server utilization is 80%. Any less and you could use fewer machines; any more and latency starts to take a hit. This is when you're optimizing for latency. Throughput is different.
  - pdhborges 1y ago
    Doesn't this depend on the number of servers, crash rates and recovery times? I wouldn't feel confident running 3 servers running at 80% capacity in ultra low latency scenarios. A single crash would overwhelm the other 2 servers in no time.
    - dehrmann 1y ago
      Right; this is only for large pools of servers.
- namaria 1y ago
  Difference is machines break and that costs lots of money. People just quit, some businesses consider it a better outcome.
zombiwoof 1y ago
Same. What's crazier now is nobody in management seems to want to take a risk, when the risks are so much lower. We have better information, blogs, posts on how others solved issue, yet managers are still like "we can't risk changing our backend from dog shit to postgres". . . .when in the 90s you would literally be figuring it all out yourself, making a gut call and you'd be supported to venture into the unknown. now it's all RSU, Stock Prices, FAANG ego stroking and mad dashes for the acquihire exit pushing out as much garbage as possible while managers shine it up like AI goodness
m463 1y ago
I've always thought if I gave better estimates about how long things would take, my schedule would support a decent job. But black swans seem to be more common than anticipated. (I also wonder - over your career, do you naturally move up to jobs with higher salaries and higher expectations?)
dustingetz 1y ago
as tech gets commoditized the companies are worse, more funding but worse
wormius 1y ago
It's almost as if people don't understand what the word "productivity" means. That's all it is, if you hear "x increase in productivity" and it sounds great, it really means : you, the worker, work harder after we fire other people and thus are "more productive" because you did the same out put that 2 people did. Sucker. And we all eat this shit up.
giantg2 1y ago
I've even seen this and it seems to have accelerated in the last 10 years or so. I'm seeing roles be combined, deadlines get tighter, and quality go down. Documentation has also gotten worse. This all seems pretty odd when you consider the tools to develop, test, and even document have mostly gotten more powerful/better/faster.
- joquarky 1y ago
  What documentation?
joquarky 1y ago
You can’t brute-force insight. I'm often reminded of that Futurama episode “A Pharaoh to Remember” (S04E07), where Bender is whipping the architects/engineers in an attempt to make them solve problems faster.
atrettel 1y ago
I was about to post largely the same thing. There is a saying in design: "Good, fast, cheap --- pick two." The default choice always seems to be fast and cheap nowadays. I find myself telling other people to take their time, but I too have worked jobs where the workloads were far too great to do a decent job. So this is what we get.
lumost 1y ago
People have to care about outcomes in order to get good outcomes. Its pretty difficult to get someone to work extra time, or care about the small stuff if there is a good chance that they will be gone in 6 months. Alternatively, if leadership is going to cycle over in 6 months - then no one will remember the details.
3abiton 1y ago
I totally agree, it was a stark contrast between phd life and purely sw engineer life, in terms of doing things the way i wanted.
giancarlostoro 1y ago
I think letting devs 2 hours a day, that they can flex so if they wanna use it on Fridays its fine, for personal projects, whether internal or otherwise. Just think of all the random tech debt that could be resolved if devs had 2 hours a day to code anything, including new projects that benefit everyone. Most people can only squeeze out about 6 hours worth of real work anyway. You burn up by the end of the day.
- fsckboy 1y ago
  >Just think of all the random tech debt that could be resolved if devs had 2 hours a day to code anything, including new projects that benefit everyone. regardless of the potential benefits of this plan, zero tech debt would get erased. imho net tech debt would increase by the 80 20 rule, meaning that you're not going to get more than 80% of the side projects fully wrapped in the 20% of the time that you've allotted to them.
  - touisteur 1y ago
    I guess tech debt could even be increased in some cases. Some people shouldn't have too much time available :-)
rukuu001 1y ago
Have we learnt nothing? 100% utilisation of practically any resource will result in problems with either quality or schedules. What, as an industry, do we need to do to learn this lesson?
- Clubber 1y ago
  It needs to be reflected faster in quarterly results. When the effect takes a year or two, nobody notices and there are too many other variables/externalities to place blame.
svilen_dobrev 1y ago
> People need some slack Definitely. If you tighten a bearing up-to 100% - to zero "play", it will stop rotating easy.. and start wearing. Which is.. in people-terms, called burnout. Or as article below says, (too much) Efficiency is the Enemy.. https://fs.blog/slack/ https://fs.blog/slack/
saghm 1y ago
One time during a 1:1 with who I consider the best manager I ever had, in the context of asking now urgent something needed to get done, I said something along the llines of how I tend to throttle to around 60% of my "maximum power" to avoid burnout but I could push a bit harder if the task we were discussing was essential with to warrant it. He said that it wasn't necessary but also stressed that any time in the future that I did push myself further, I should always return to 60% power as soon as I could (even if the "turbo boost" wasn't enough to finish whatever I was working on. To this day, I'm equally amazed at both how his main concern with the idea of me only working at 60% most of the time was that I didn't let myself get pressured into doing more than that and the fact that there are probably very few managers out there who would react well to my stating the obvious truth that this is necessary
motorest 1y ago
> I have been in the workforce for almost 30 years now and I believe that everybody is getting more squeezed so they don’t have the time or energy to do a proper job. The expectation is to get it done as quickly as possible and not do more unless told so. That's my impression as well, but I'd stress that this push is not implicit or driven by metrics or Jira. This push is sold as the main trait of software projects, and what differentiates software engineering from any other engineering field. Software projects are considered adaptable, and all projects value minimizing time to market. This means that on paper there is no requirement to eliminate the need to redesign or reimplement whole systems or features. Therefore, if you can live with a MVP that does 70% of your requirements list but can be hacked together in a few weeks, most would not opt to spend more man months only to get minor increments. You'd be even less inclined to pay all those extra man months upfront if you can quickly get that 70% in a few weeks and from that point onward gradually build up features.
dumbledoren 1y ago
Capitalism eventually ends up in those with capital making those without capital work until they drop. We are in that eventuality right now.
hellotheretoday 1y ago
There are fields of study that agree with you. It is evidence based that treating your workers well, having reasonable quotas and expectations for work life balance, good wages and reinforcement for effort, etc creates conditions where workers perform more efficiently and last longer But many organizations reject this. Why wouldn’t they? There is a surplus of workers and consumers accept substandard products. Skimp on training, put out crap. Throw workers into the fire, demand everything from them, get furious if they don’t prioritize the company above everything in their life, burn them out, cut them loose, pick another from the stack of resumes I was talking to someone who works for a startup recently. A colleague died and it was announced on a Friday. They were expected to finish the day. On Monday their replacement started and the team was told to bring this person up to speed asap. No space to grieve, no time to process. Soulless and inhuman. Disgusting and sociopathic behavior

Avicebron 1y ago

The article addresses the fact that it's more of the "job" that the software company provides as an extension of their services isn't really a "job" a la "SW development in the 90s" It's the after effect of companies not being penalized for using the exploitation dragnet approach to use people in desperate situations to generate more profits while providing nothing in return.

kunzhi 1y ago

Only 20 years for me, but this is my observation also.

temporallobe 1y ago

This is my experience as well. In the late 90s/early 2000s I had the luxury of a lot of time to deeply and learn Unix, Perl, Java, web development, etc., and it was all self-directed. Now with Agile, literally every hour is accounted for, though we of course have other ways of wasting time by overestimating tasks and creating unnecessary do-nothing stories in order to inflate metrics and justify dead space in the sprint.

TuringNYC 1y ago
>> literally every hour is accounted for I saw one company where early-career BA/PMs (often offshore) would sit alongside developers and "keep them company" almost all day via zoom.
- AtheistOfFail 1y ago
  Yep, that would be my own personal hell.
- latentsea 1y ago
  I would just terminate the call. Like... hell no.
- AnimalMuppet 1y ago
  Everyone's complaining about that as a developer, and rightly so. But that can't be easy for the PMs, either, trying to find a way to "add value" when they have no idea what's going on. I'd expect there to be some "unexpected network outages" regularly in that kind of situation...
- MikeTheGreat 1y ago
  Twice the billable hours! /s
- dyauspitr 1y ago
  This is kind of cool as an alternative process to develop apps with. Literally product in a zoom window telling you what to build as you go along. No standups, no refinement, no retros etc. Just a PM that really knows what the customer needs and the developer just building those as you go along.
  - PessimalDecimal 1y ago
    No. It's just awful.
  - arvinsim 1y ago
    No developer wants to being treated as a code monkey and I bet no PM would want to waste time watching someone type out code that they don't understand.
ecocentrik 1y ago
If you're creating nothing stories to justify work life balance and avoid burnout your organization has a problem. Look into Extreme Programming and Sustainable Pace.
- RobRivera 1y ago
  I think thats the observation being made. Most people respond to the organizational problem with the only tools they have, which manifests as that. Usually management knows and doesnt care about the problem
  - ecocentrik 1y ago
    ---
singpolyma3 1y ago
And yet well over half of professional developers have productivity so low that if they get laid off the term gets the same amount done...

the_cat_kittles 1y ago

sounds like bit of a death spiral

mschuster91 1y ago

> In SW development in the 90s I had much more time for experimentation to figure things out. In the last years you often have some manager where you basically have to justify every thing you do and always a huge pile of work that never gets smaller. Software development for a long time had the benefit that managers didn't get tech. They had no chance of verifying if what the nerds told them actually made sense. Nowadays there's not just Agile, "business dashboards" (Power BI and the likes) and other forms of making tech "accountable" to clueless managers, but an awful lot of developers got bought off to C-level and turned into class traitors, forgetting where they came from.

potato3732842 1y ago
I commend you for having an opinion so bad I can't tell if you're satirizing marxists or not. Let me ask you this, would you rather be managed by a hierarchy made up of people who don't understand what you do? Because I assure you it is far worse than being managed by "class traitors".
- bryanrasmussen 1y ago
  well, not the original poster, but I have been managed by both kinds, and the best manager I ever had was not a former techie and the worst was a former programmer. The worst manager did often say things that were sort of valuable and correct in a general way, like "well you don't actually know that because it hasn't been tested" which was of course true, but he also seemed to think he could tell people what the correct way to do something was without knowing the technology and the codebase. This often meant that I had to go to junior developers later, after a meeting, and say "concerning ticket X, T. didn't consider these things(listing the things), so that while it is true that we should in principle do what T. said, it will not be adequate, you will also need to do this - look at the code for this function here, it should be abstracted out in some way probably, this was my crappy way of handling the problem in desperation Y months ago." Trying to explain to him why he was wrong was impossible in itself, he was a tech genius evidently, and you just had to give it up after a bit, and figure that at some time in the future the decisions would be reversed after "we learned" something.¨ on edit: in the example I give the manager as I said was correct in what he wanted done, but as I said it was inadequate as the bug would keep recurring if only that was done, so more things had to be done that were not as pretty or as pure as what he wanted.

p1necone 1y ago

> In the last years you often have some manager where you basically have to justify every thing you do and always a huge pile of work that never gets smaller. So you just hurry through your tasks. This has been my exact experience. Absolutely everything is tracked as a work item with estimates. Anything you think should be done needs to be justified and tracked the same way. If anything ever takes longer than the estimate that was invariably just pulled out of someones ass (because it's impossible to accurately estimate development unless you're already ~75% of the way through doing it, and even then it's a crapshoot) you need to justify that in a morning standup too. The end result of all of this is every project getting bogged down by being stuck on the first version of whatever architecture was thought up right at the beginning and there being piles of tech debt that never gets fixed because nobody who actually understands what needs to be done has the political capital to get past the aforementioned justification filter.

marginalia_nu 1y ago
It's fascinating that you end up sort of doing the work twice, you build an excel (or jira) model of the work work along with the actual work to be done. Often this extends to the entire organization, where you have like this parallel dimension of spreadsheets and planning existing on top of everything. Eats resources like crazy to uphold.
- pjot 1y ago
  This compounds with each _team_ modeling the work in jira/excel too!
- squiggleblaz 1y ago
  Yes but metrics! How can the CEO look like they know what's happening without understanding anything if they don't have everyone producing numbers?
- spudlyo 1y ago
  Jira is already almost like "productivity theater" where engineers chart the work for the benefit of managers, and managers of managers only. Many programmers already really resent having to deal with it. Soon it will be a total farce, as engineers using MCP Jira servers have LLMs chart the "work" and manage the tickets for them, as managers do the same in reverse, instructing LLMs to summarize the work being done in Jira. It'll be nothing but LLMs talking to other LLMs under the guise of organizational productivity in which the only one deriving any value from this effort is the companies charging for the input and output tokens. Except, they are likely operating at a loss...

Sparkyte 1y ago

Definitely squeezed. They say AI, but AI isn't eliminating programming. I've wrote a few applications with AI assistance. It probably would've been faster if I wrote it myself. The problem is that it doesn't have context and wildly assumes what your intentions are and cheats outcomes. It will replace juniors for that one liner, it won't replace a senior developer who knows how to write code.

NERD_ALERT 1y ago
I felt this way with Github Copilot but I started using Cursor this week and it genuinely feels like a competent pair programmer.
- deleted 1y ago
  [deleted]
- Retric 1y ago
  What work are you doing the last few days? My experience is for a very narrow range of tasks, like getting the basics of a common but new to me API working, they are moderately useful. But the overwhelming majority of the time they are useless.
- jdcasale 1y ago
  I recently tried Cursor for about a week and I was disappointed. It was useful for generating code that someone else has definitely written before (boilerplate etc), but any time I tried to do something nontrivial, it failed no matter how much poking, prodding, and thoughtful prompting I tried. Even when I tried to ask it for stuff like refactoring a relatively simple rust file to be more idiomatic or organized, it consistently generated code that did not compile and was unable to fix the compile errors on 5 or 6 repromptings. For what it's worth, a lot of SWE work technically trivial -- it makes this much quicker so there's obviously some value there, but if we're comparing it to a pair programmer, I would definitely fire a dev who had this sort of extremely limited complexity ceiling. It really feels to me (just vibes, obviously not scientific) like it is good at interpolating between things in its training set, but is not really able to do anything more than that. Presumably this will get better over time.

golergka 1y ago

How much more expensive is your time for the company now vs the 90s?

bryanrasmussen 1y ago
counting in cost of living increases? Probably about the same.

dwattttt 1y ago

> People ... aren’t machines that can run constantly on 100% utilization. You also can't run machines at 100% utilisation & expect quality results. That's when you see tail latencies blow out, hash maps lose their performance, physical machines wear supra-linearly... The list goes on.

dehrmann 1y ago
The standard rule for CPU-bound RPC server utilization is 80%. Any less and you could use fewer machines; any more and latency starts to take a hit. This is when you're optimizing for latency. Throughput is different.
- pdhborges 1y ago
  Doesn't this depend on the number of servers, crash rates and recovery times? I wouldn't feel confident running 3 servers running at 80% capacity in ultra low latency scenarios. A single crash would overwhelm the other 2 servers in no time.
  - dehrmann 1y ago
    Right; this is only for large pools of servers.
namaria 1y ago
Difference is machines break and that costs lots of money. People just quit, some businesses consider it a better outcome.

zombiwoof 1y ago

Same. What's crazier now is nobody in management seems to want to take a risk, when the risks are so much lower. We have better information, blogs, posts on how others solved issue, yet managers are still like "we can't risk changing our backend from dog shit to postgres". . . .when in the 90s you would literally be figuring it all out yourself, making a gut call and you'd be supported to venture into the unknown. now it's all RSU, Stock Prices, FAANG ego stroking and mad dashes for the acquihire exit pushing out as much garbage as possible while managers shine it up like AI goodness

m463 1y ago

I've always thought if I gave better estimates about how long things would take, my schedule would support a decent job. But black swans seem to be more common than anticipated. (I also wonder - over your career, do you naturally move up to jobs with higher salaries and higher expectations?)

dustingetz 1y ago

as tech gets commoditized the companies are worse, more funding but worse

wormius 1y ago

It's almost as if people don't understand what the word "productivity" means. That's all it is, if you hear "x increase in productivity" and it sounds great, it really means : you, the worker, work harder after we fire other people and thus are "more productive" because you did the same out put that 2 people did. Sucker. And we all eat this shit up.

giantg2 1y ago

I've even seen this and it seems to have accelerated in the last 10 years or so. I'm seeing roles be combined, deadlines get tighter, and quality go down. Documentation has also gotten worse. This all seems pretty odd when you consider the tools to develop, test, and even document have mostly gotten more powerful/better/faster.

joquarky 1y ago
What documentation?

joquarky 1y ago

You can’t brute-force insight. I'm often reminded of that Futurama episode “A Pharaoh to Remember” (S04E07), where Bender is whipping the architects/engineers in an attempt to make them solve problems faster.

atrettel 1y ago

I was about to post largely the same thing. There is a saying in design: "Good, fast, cheap --- pick two." The default choice always seems to be fast and cheap nowadays. I find myself telling other people to take their time, but I too have worked jobs where the workloads were far too great to do a decent job. So this is what we get.

lumost 1y ago

People have to care about outcomes in order to get good outcomes. Its pretty difficult to get someone to work extra time, or care about the small stuff if there is a good chance that they will be gone in 6 months. Alternatively, if leadership is going to cycle over in 6 months - then no one will remember the details.

3abiton 1y ago

I totally agree, it was a stark contrast between phd life and purely sw engineer life, in terms of doing things the way i wanted.

giancarlostoro 1y ago

I think letting devs 2 hours a day, that they can flex so if they wanna use it on Fridays its fine, for personal projects, whether internal or otherwise. Just think of all the random tech debt that could be resolved if devs had 2 hours a day to code anything, including new projects that benefit everyone. Most people can only squeeze out about 6 hours worth of real work anyway. You burn up by the end of the day.

fsckboy 1y ago
>Just think of all the random tech debt that could be resolved if devs had 2 hours a day to code anything, including new projects that benefit everyone. regardless of the potential benefits of this plan, zero tech debt would get erased. imho net tech debt would increase by the 80 20 rule, meaning that you're not going to get more than 80% of the side projects fully wrapped in the 20% of the time that you've allotted to them.
- touisteur 1y ago
  I guess tech debt could even be increased in some cases. Some people shouldn't have too much time available :-)

rukuu001 1y ago

Have we learnt nothing? 100% utilisation of practically any resource will result in problems with either quality or schedules. What, as an industry, do we need to do to learn this lesson?

Clubber 1y ago
It needs to be reflected faster in quarterly results. When the effect takes a year or two, nobody notices and there are too many other variables/externalities to place blame.

svilen_dobrev 1y ago

> People need some slack Definitely. If you tighten a bearing up-to 100% - to zero "play", it will stop rotating easy.. and start wearing. Which is.. in people-terms, called burnout. Or as article below says, (too much) Efficiency is the Enemy.. https://fs.blog/slack/ https://fs.blog/slack/

saghm 1y ago

One time during a 1:1 with who I consider the best manager I ever had, in the context of asking now urgent something needed to get done, I said something along the llines of how I tend to throttle to around 60% of my "maximum power" to avoid burnout but I could push a bit harder if the task we were discussing was essential with to warrant it. He said that it wasn't necessary but also stressed that any time in the future that I did push myself further, I should always return to 60% power as soon as I could (even if the "turbo boost" wasn't enough to finish whatever I was working on. To this day, I'm equally amazed at both how his main concern with the idea of me only working at 60% most of the time was that I didn't let myself get pressured into doing more than that and the fact that there are probably very few managers out there who would react well to my stating the obvious truth that this is necessary

motorest 1y ago

> I have been in the workforce for almost 30 years now and I believe that everybody is getting more squeezed so they don’t have the time or energy to do a proper job. The expectation is to get it done as quickly as possible and not do more unless told so. That's my impression as well, but I'd stress that this push is not implicit or driven by metrics or Jira. This push is sold as the main trait of software projects, and what differentiates software engineering from any other engineering field. Software projects are considered adaptable, and all projects value minimizing time to market. This means that on paper there is no requirement to eliminate the need to redesign or reimplement whole systems or features. Therefore, if you can live with a MVP that does 70% of your requirements list but can be hacked together in a few weeks, most would not opt to spend more man months only to get minor increments. You'd be even less inclined to pay all those extra man months upfront if you can quickly get that 70% in a few weeks and from that point onward gradually build up features.

dumbledoren 1y ago

Capitalism eventually ends up in those with capital making those without capital work until they drop. We are in that eventuality right now.

hellotheretoday 1y ago

There are fields of study that agree with you. It is evidence based that treating your workers well, having reasonable quotas and expectations for work life balance, good wages and reinforcement for effort, etc creates conditions where workers perform more efficiently and last longer But many organizations reject this. Why wouldn’t they? There is a surplus of workers and consumers accept substandard products. Skimp on training, put out crap. Throw workers into the fire, demand everything from them, get furious if they don’t prioritize the company above everything in their life, burn them out, cut them loose, pick another from the stack of resumes I was talking to someone who works for a startup recently. A colleague died and it was announced on a Friday. They were expected to finish the day. On Monday their replacement started and the team was told to bring this person up to speed asap. No space to grieve, no time to process. Soulless and inhuman. Disgusting and sociopathic behavior