Programming

But then it is the developers fault, never management

Do the old devops folks get made into glue or something?

If i interpreted the "trend" correctly, "devops" was bastardized away from its original meaning to now mean "sysadmin", at least in most cases.

"Devops" original intent meant you don't have a separate "operations" department separate from teams "developing" your product / software due to competing incentives. "Dev" wants to push new stuff out faster; "ops" wants to keep things stable. Or "dev" needs more resources; but "ops" blocks or doesn't scale the same. The idea was to combine both "dev" and "ops" people onto projects to balance these incentives.

Then managers and cloud clowns repurposed it to apply to every person in a project so now every member is expected to perform both roles (badly). Or even more overloaded to somehow refer to "developer infrastructure" teams.

Depends on the work load. The company should make time for that and you should get paid for it.

Use overestimation padding, eh?

oh no...

was told we'd do it in excel/vba instead, still unhappy.

I just threw up in my mouth a little. Fifteen years ago, "I'll stick to Excel" was a (bad, but) defensible position in data automation. Today that's just insanity.

Every job lately seems to have been infected by Meta/google “data driven” leadership. Its so painful and wasteful sometimes.

It's cargo cult mentality. They look at FANGs and see them as success stories, and thus they try to be successful by mimicking visible aspects of FANG's way of doing things, regardless of having the same context or even making sense.

I once interviewed for a big name non-FANG web-scale service provider whose recruiter bragged about their 7-round interview process. When I asked why on earth they need 7 rounds of interviews, the recruiter said they optimized the process down from the 12 rounds of interviews they did in the past, and they do it because that's what FANGs do. Except FANGs do typically 4, with the last being an on-site.

But they did 7, because FANGs. Disregard "why".

20 years ago it was the people who worshipped Jack Welch, not realizing (or not caring) that he was running GE into the ground.

80% seems too high, but the US Surgeon General declared a loneliness epidemic https://www.hhs.gov/sites/default/files/surgeon-general-social-connection-advisory.pdf

And Gallup claims that 29% of Americans have been diagnosed with depression at one point: https://news.gallup.com/poll/505745/depression-rates-reach-new-highs.aspx

So... That is not good. It is almost like humans evolved to live in tight knit, walkable communities.

Business fails, next business pops up.

If you had to hire 100 professional programmers in the past, but then AI makes programmers 10% more efficient than previously, then you can do the same work with 91 programmers.

You've nailed to root of the misunderstanding by non-programmers. We're already optimized past that target.

Some people think we type all day. We don't. We stare at our screen saying "what the fuck?!" for most of the day. Those is especially true for the best programmers doing really interesting work.

There's maybe three living humans who actually know how to correctly build a Windows installer. One of those three is paid to sell software to automate the task for everyone else. The other two retired already. (One is hiding out as a bar tender and claims to not speak any English if recognized from their MSI days.)

Pick an interesting topic in programming, and you'll find similarly ludicrous optimization.

There's a few hundred programmers building all banking automation, selling it to millions of bank employees.

It's possible that AI will force a dozen people to stop doing banking automation. It's a lot more likely that the backlog of unmet banking automation need will instead just get very slightly smaller.

Now, the reality of the economics won't stop CIOs from laying off staff and betting that AI will magically expand to fill the gap. We're seeing that now. That's called the "fuck around" phase.

But we've seen "this revolutionary technology will make us not need more programmers" before (several times). The outcomes, when the dust settles are:

1. The job is now genuinely easier to do, at least for beginners. (Senior professionals had access to equivalent solutions, before everyone else got excited.)
2. More people are now programmers. (We laid a bunch of them off, and we meant to not hire any back, but it turned out that our backlog of cool/revolutionary/necessary ideas was more important to leadership than pinching pennies.)
3. A lot of work that was previously ignored completely now gets done, but done very badly by brand new programmers. (We asked the senior developers to do it, but they said "Fuck you, that's not important, make the new kid do it." I think they're just still cranky that we spent three years laying off staff instead of training...)
4. The average quality of all software is now a bit worse, but there's a lot more variety of (worse) software now available.

To add on this, this doesn't necessarily mean that there are fewer programing jobs in total. If people work 10% more efficently, that means that the cost of labor is only 91% of what it was before meaning that people might be able to afford to finance more programing projects. One thing that does matter is for example things like entry level jobs disappearing or the nature of the work changing. Doing less boring gruntwork can make the job more fun, but otoh digitization sometimes results in the worker having less agency in what they do since they have to fit everything into a possibly inflexible digital system.

Yeah management is totally backwards there; it's like the building manager on a construction project going "all electrical needs to be done in X weeks", but realistically they have no direct control over that deadline being met by declaring an arbitrary deadline. The unfortunate difference is that if you do a shitty job wiring a building, you'll fail inspection and have to spend more time and money fixing it. Software can often hobble along; there aren't strict enforcements for quality that the business can legally ignore, so you'll always have sad defeated devs go "okay boss, we'll skip the things we need to get this done faster for you (I hate this job and don't care about the product's long term success)". Having a steady supply of those people will slowly kill a software company.

In the past, I've dealt with estimate pushback not by explaining what necessary work can be removed like tests, documentation, or refactoring, but by talking through ways to divide the project more effectively to get more people involved (up to a point, a la mythical man month). That seems to go more proactively. Then we look at nixing optional requirements. But, I've also usually dealt with mostly competent engineering management.

Yes, this! I rarely ask for permission on that sort of thing. I’ll just do it as part of my work and see if anyone calls me out on it.