The death spiral becomes visible, really. The gun had already been fired, the body just hadn’t hit the ground yet.

I must say these failure modes are much worse than the ones I’ve experienced, which maybe I should be grateful for, I’d have to think about this. Generally I’ve seen a slower burn, where the remaining fiscal year plays out with soothing tones and promises of not changing things, and if money doesn’t magically appear in their accounts, which why would it? Then they don’t give you money for some of the things you usually do and while they technically didn’t tell you not to do them, if there’s no money you don’t get to do them.

I don’t know which business school teaches people to say “ah can you smell that fresh mountain air” while they have their hands wrapped tightly around your neck but that’s some gaslighting BS that I hope nobody experiences, but I know people have. Best I can do is tell them to watch out for it. Some places you’re safe until FY+1, and things don’t go fully absurd until FY+2.

It’s all of them and the higher you get into management the more apparent it is. They sell a system of meritocracy where those who work the hardest get the rewards. Then you get into management and working side by side with people whose first job out of college was as a VP, who explain to you how they are forcing the newly hired manager to fire someone at random to “make sure they have a backbone”

Software engineers have been tricked into thinking they are part of the in club because they are paid well enough to have the lifestyle that the middle class had between ww2 and the 80s, but we are being systematically stripped of the value we bring.

If this wasn’t true then we wouldn’t be able to point towards recent events like jobs setting up a hiring cartel to depress our wages

This, and additionally we've been tricked into feeling guilty about it as well.

Maybe in the future we will have to unionize. Definitely not now and not in Europe. And this is not a matter of pay, e.g. airline pilots are paid more than programmers here yet they are heavily unionized.

Right now management will be off-guard, not expecting any unionisation push and will be a little bit unprepared as to how to counter it (that is, if they even try). Employees will likely feel comfortable openly discussing unions knowing that they probably won't feel any reprisals (and if they do, well the job market is still pretty good for the moment). The tough part would be convincing someone on $1x0,000/year that they might benefit from a union.

Education still doesn't prevent us from falling in particular traps.

Spend your money/energy on lobbying.

This is naive. Any ticket tracking system can be used to track productivity. And if you don’t have a ticket tracking system to organize work, that’s a miserable environment to work in.

- as you said, productivity tracking through arbitrary means (in our case it was an arbitrary "story points completed per developer per month" measurement used to rank us)

- expectations around overtime (it was common to be asked to work evenings and weekends, you were remunerated at 1.5x or 2x but expected to do so if asked and singled out if you didn't)

- developers being frozen out of the requirements process (senior devs were begging to be allowed to spend time with the analysts, but prevented from doing so by someone in the management hierarchy, I think someone in charge of analysts)

- work-from-home (this was pre-covid, but there was an expectation that you'd be in the office unless you had an extremely good reason to and it was begrudgingly permitted)

Fighting for improvements in these areas individually is near-futile, but when you've organized yourselves management have to decide whether some very minor things are really worth pissing their entire, expensive-to-hire development team for.

I’m trying to figure out if you’re opposed to terrible approximations of productivity or to making performance distinctions among engineers.

A middle manager is not allowed to use git?

I have had numerous jobs in IT, and software development is by far the worst. Ticket grinding bullshit.

The sad part is that developers think this is how software development is so they can't even demand better. Clueless.

I can't work out what "this" is that does not happen to unionised workers? Unionised workers can switch jobs to get more pay too.

So does that mean, when the headlines say "Amazon workers (from a particular warehouse) vote to unionize", it's really about bringing that warehouse under the umbrella of an existing union?

Having universal or near universal union membership for a certain profession is limited to certain jobs, things like warehouse workers or retail employees aren't anywhere near that.

Is it not stressful when switching jobs? - from paperwork, interviews, new colleagues, friendships, on-boarding, new place politics - especially for brain.

If I got fired tomorrow it would result in a vacation, probably followed by a raise. When you get to that place it isn't scary at all.

I hate it with all my heart but if I have to, I'll do it 50 times more. I am never allowing myself be held hostage.

So, you navigate this quagmire begrudgingly, yet don't favour unionisation?

Hmm, but is this really the case?

I know it's how it's sold, but does it actually work like that?

My job is not to do underground mafia wars. If the employers want to fight dirty I'll just move to someplace else. Eventually they'll be stuck with the people who are OK with being slaves -- but won't be creative or efficient.

I wish them luck. They are hurting themselves, not me or the other worthy programmers.

Unpopular opinion: unionization is like democracy: people think it works but in reality there are a lot of shady deals under the table and the system hasn't worked as it is supposed to, for a long long time.

It seems a stretch to say the union interfered with her 'mobility', any more than you can't do plumbing on a public building without having a license etc.

I am saying that when enough money are in danger [of having to be spent by big companies] that unionization gets under attack with very questionable and shady techniques.

I wasn't aware that I have to remind HN of the recent articles, published right on this forum, of evidence that Amazon sabotaged unionization efforts by hiring people who deliberately derail discourse and pump outrage. But alas, apparently people believe only what they want to believe.

I mean...yes, at the macro level, that's part of the point of unionizing.

But software development can be stressful on its own: you have endless pointless meetings which serve no purpose but you have to attend them, you have mandatory corporate team-building shite which you must attend or you lose the "software engineer SENIOR" job title and you have to show leadership skills to HR people and your managers during pointless "funny" "games" during the team-buildings, you can't be involved in illegal activities (e.g. rage-type murder of your manager is a major no-no which can ruin your career for good). You also have to learn new things constantly in your free time because your employer is reluctant to pay for courses. The list goes on. My previous job was applied research and especially the university professors who did the actual research treated us like a piece of shite. I can't even count the number of times I heard something like "you can't understand anything because you have only Master's".

The stress-level of switching to a new job is generally comparable to normal activities. You need to grow some thick skin.

As a counter-example to this specific point, the Screen Actors Guild does a tremendous amount of work to raise the pay and conditions of the median earning actors, without preventing the highest performing members from negotiating compensation in line with their ability to contribute to the success of a project. We can have our cake (collective negotiation) and eat it too (million dollar+/yr IC roles).

Other notable examples; State bar associations (lawyers) and the American Medical Association (doctors).

Also professional sports unions.

The Bar Associations and the AMA are not quite unions though they certainly advocate and lobby strongly on behalf of their professions.

For the Bar there may be confusion because of the names of licensing agencies. In California, the state agency is the State Bar of California, but that has nothing to do with various bar associations.

The last 15 years have also been a relentless boom market, longer than most.

It won't always be that way!

The best time to prep for bad times is when the going is still good.

[Citation needed]

* https://centreforaviation.com/news/pilot-union-accepts-emplo...

* https://www.flightglobal.com/strategy/klm-clears-path-to-bai...

VNV is the pilots union of KLM, the Dutch national airline. IIRC they were the very last of the unions to sign up to the 'commitment clause' the Dutch gov required as part of their bail-out during Covid. Not a union without teeth.

I was contesting that pilots are paid more than developers. If you have data that supports that, please share. It seems like an absurd claim.

My country: https://www.platy.cz/platy/doprava-spedice-logistika/pilot https://www.platy.cz/platy/informacni-technologie/programato...

Average is CZK per calendar month gross (which is some 25-30% higher than net).

Pilots 38k - 132k Programmers 36k - 86k

as employees. If you work as a freelancer programmer (i.e. you have your own trade license) you can easily earn twice as much but if you count-in all the employee benefits granted by the Work law it's usually not worth it if you already have a family (which I have, therefore I switched from freelancing to being an employee).

And of course, Ryanair/EasyJet pilots are not counted in the statistics. The same goes to students - programmers which kludge together a Wordpress site and "sell" it.

I think part of the push-back against programmer unions from American programmers is that there's such a wide range of skills, and at the moment the market allocates compensation more-or-less according to capability. In many important ways, a programmer earning $500,000 per year at Google is in a different industry than a programmer earning $50,000 per year at General Motors.

[0] $52,000 per year according to https://www.indeed.com/career/pilot/salaries

Ironically, as Ryanair pays pilots significantly more than the range in the GP's comments (at below the low-end and high-end), including them would support their argument.

The only way to make the claim that pilots earn more than developers stick is to ignore all but the high-end of pilot salaries at major airlines and include all developers. A fairer comparison would either be to include all pilots (including the low end piston engine pilots at skydiving DZs and other utility roles) or to only include the top-earning professional developers (maybe MAGMA).

https://fr.glassdoor.be/Salaries/airfrance-pilot-salary-SRCH...

https://www.payscale.com/research/FR/Job=Software_Engineer_%...

The answer is obviously not - do you have any salary data?

I’m not saying they are perfect sources, but they do align with anecdotal datapoints.

> I’m not saying they are perfect sources, but they do align with anecdotal datapoints.

So you say, but that's definitely not true for me (who lives in the States and Ireland). In fact, it's an absurd claim to me.

> airline pilots are paid more than programmers here

(emphasis mine)

I just gave one geographical example where I believe that to be true. I don’t think it is true everywhere, nor do I think OP meant that.

also, for every engineer, there is one who will claim to be able to do the job cheaper. that is why we need unions. that, and to get rid of leetcode. people already went to college and that should be enough.

I don't like or do LC interviews, but even if (a big IF) college prepared you for programming, a LOT of professionals don't study development or even attend college. How would they get into the industry? Take 2 years off later in life and attend college?

any good college will require significant programming work, so by the time you graduate 4 years later you not only have CS theory subjects down but are able to write software and can pick up any language in a few days.

Would the stability and general level of working conditions have anything to do with the fact that most are unionized, and have been over a long time so they can do their job responsibly, perchance?

Maybe the parent wants the union to fight for the same conditions as Europeans now have? I wouldn't know. My experience from a Nordic union certainly wouldn't be a good take of what an union membership in Brazil, US or Japan would be like.

I think of this when managers come up with different requirements during the project. If the requirements seem to make the product better, I'm all for it. I like to work this way and they pat me on the head for being "agile". But I always end up kicking myself when they ask why the project is taking longer. I fall for it almost every time because I like to tinker.

I missed this, any details?

"former Apple CEO Steve Jobs, former Google CEO Eric Schmidt and top executives from [Intuit, Pixar and Lucasfilm] had reached "no-poaching" pacts prohibiting each other from trying to lure away each other's top workers with offers of higher-paying jobs."

These were the ones for whom DoJ had enough "smoking gun" proof, but Jobs and Schmidt had a lot of friends elsewhere (Larry Ellison...), so the cartel was likely much bigger.

What? How?

Company A buys company B for a product it believes in. Company A knows that company B was incapable of getting product to finish line, which is why they sold out. No problem though, company A has done this before…

The managers at company A are assigned to ship product, just like they have before. Managers can’t say “its all good, we’ll give them a couple more devs and leave them to it.” they were told to manage, changes will be expected, planning must happen.

The C level of company A just spent a bunch of money on company B. The product needs to hit positive revenue in 9 months, without positive revenue in 12 months the company will be out of cash. So management are told in no uncertain terms that they have to ship in 6 months.

The contracted developers sign on to a 6 month fixed timeframe and know there will be design tweaks by the new management.

At every stage everyone is doing their job. Everyone is trying to do the right thing for success and to not get fired. Everyone has a problem that can only be fixed by someone at a different level compromising on their quality of work or their personal happiness.

I’m not excusing bad management or execs who looking for a rapid cash-out. Trying to illustrate how a good company can hit the same pattern.

I think this hits the nail on the head.

A bunch of reasonably competent people went in with the best intentions, all in good faith and over time it became clear certain assumptions were either too optimistic or simply wrong.

While there is definitely blame to be apportioned, the frustration felt by all involved leads to a very human reaction of calling it malevolence or incompetence.

Then everyone pays for their mistakes, and the whole thing is a waste .

Optimism is essential in any endeavor, but it is no substitute for starting with accurate -in detail- assessments & provisioning of resources.

They (the Corp-A C-Levels) had one job here...

Companies make these decisions all the time, particularly in industries whose products are hit driven and then tail off.

Management panics when they realize they won't make the self imposed deadline and start throwing bodies at the problem.

In our case, we went from 2 teams to 8 over night. The very few engineers who actually were capable of shipping features became swamped dealing with the fallout.

To make things worse, they keep scheduling multi-day, 8hr "planning" sessions that all key devs must attend so they can better "understand the remaining work"

The better way is to have a smaller number of people work on requirements and figuring stuff out before a whole team lets rip. Some tasks just don’t parallelise well so a 9 person team isn’t good for everything.

I wonder where this comes from. Is it just hubris mixed with incompetence?

But, it take hubris and incompetence to get there.

Once they've shown they can do it once it's perfectly reasonable to bet the entire business on them doing it the next month.

Oh, and also, the diversity team have noticed we have hired a lot of young people so we're only hiring over-50s this year.

That's true. A team of 20 women can easily produce one baby a month.

Nine women can't, but the people who like to say "nine women can't produce a baby in a month" are almost never trying to tell you that you can fix your problem by expanding your team to the appropriate size.

The other day I had PM complaining how they were going to keep their team (which has somehow grown to 10 devs!) busy after the highly sequential work was blocked by a dependency on another team...

That would have allowed modules/components to operate independently ,reved on different schedules, and more, but evidently too much thought at the outset ,so they just didn't even bring it up ,or passed on the opportunity if it was brought up.

They think they can't spend the resources to get it right, but they'll magically have more resources to fix the problems.

Now everyone pays.

It was to partition the app into at least the primary segments that did different functions and had different behaviors, system resource load profiles, etc., and then mandate that those all run on separate machines (this was before everything was cloud-based), and that the relationship to entities was not 1:1. Defined clean interfaces up front. The primary goal was to be able to scale very rapidly for any big customer and/or upon discovering a scalability issue by temporarily throwing hardware at the problem, and secondarily to allow teams to rev different portions of the system on different schedules.

Both worked great, and it wasn't long before we were taking major customers away from competitors because they had scalability issues and we didn't. I'm in R&D and manufacturing now, but see no reason that this approach of fundamental modularity should not be relevant. Heck, I find high modularity to be a good approach relevant to designing industrial processes, or just setting up a shop... just keep everybody's fingers in their own pies, make the organization implement the best architecture, not make your architecture implement your org chart.

(see point about about the not understanding what is being built and constantly changing the scope)

and to save money they hire some newbies instead of experienced people. I have had it multiple times where the project got looded with people who had no experience or they were in India 12 hours away so onboarding was really hard. the result was always that the added people slowed the project down.

One place I was at had quarterly 3 day planning sessions. That was something else.

Team1: "Hey, we've launched a new initiative a few weeks back. Important for us to be able to add one field to the response of your internal billing API. Can we discuss what that would take?"

Team2: "Hey, probably a few hours of work. But, we just had our quarterly planning last week. In 12 weeks you can submit for Q2, and _maybe_ we will plan it somewhere in May or June."

Plus a planning every sprint and daily stand ups.

sigh

For the people doing planning, they were always busy playing ticket shuffle, asking random devs random questions all the time. But those two weeks was cray and anything not done by the end of the sprint had to be done by the end of the planning period, and you better have a good reason.

The place where I worked: the owner of the company was Bipolar (in the literal sense), and depending on what phase he was, he wanted different features, so every time he "switched", he changed all features, often going back and forth between two feature sets, after a while he got mad the apps were all late and not finished and fired everything and focused on his other business that was more successful.

Place I had a friend that worked there: Experienced (but small) movie studio decided to make games... My friend after a while started to complain of features changing non-stop, I made aquantance to a lot of other employees for various reasons and gathering up all their stories one thing was very clear: the owner new wife often hanged around in the office, and went around demanding new features, whenever employees resisted, she called her husband (the real owner), that then proceeded to agree to whatever she asked... Until they married the project was going well, as soon they married it tanked.

Second thing: you can change jobs as often as you want. I am for loyalty but you can’t know what a job will be like until you work it.

If you've had projects like this in the past you'll recognise the early warning signs (eg. hard deadline before (even rough draft) requirements are available).

You'll know it's time to start the job hunt early because there's no way it can work unless you work yourself 24/7 into the ground.

It's not about accepting defeat, it's about accepting you are worthy of something better.

Note that in this case there’s no way it can work period. The product is useless and worthless. The ring that beeps differently depending on the color of objects it hits? How much would you pay for it?

I personally know better not to judge people who are not.

A job doesn't deserve more from you than it gives you.

Today it's so incredibly common (and hiring processes are extremely strict compared to before), that most companies see having started multiple jobs as "validation" from other companies.

"Hey we don't really need to make any decision ever or even know what we are doing. That's the great thing about agile!"

This might be a controversial take but if you have an actual deadline -- "product must cross the threshold of not shippable to shippable" as opposed to a cutoff date "product is at all times shippable but we need a date to say we're done refining" then agile is probably not the way to go.

I've always structured projects like this as waterfall to your MVP then switch to agile. You have to get your PMs to agree to an (externally) unchanging design and feature set until you have something working to talk about and then you can ask what they want next.

Even without a deadline I still try to follow this model but define the "MVP" as a "hello world" app but with functioning prod-ready infrastructure and ci/cd. So then I can go to the design meeting and say, "I have a blank canvas, what do you want on it?"

The management in the company didn't plan anything and the meandering development process showed it.

Please don't underplan. It's awful for morale to throw away work because of bad planning.

If your morale is harmed by throwing away work, that's something you should work on.

If that doesn't kill your morale, I don't know what to say.

Meanwhile, by all means discover that no one likes typing numbers on a phone so you have to refocus on taking pictures of receipts and wage stubs and text recognizing them.

Although I should point out that 2/3 of the examples would not have been caught by a user, because they are compliance related.

Then all the unknown unknowns become known unknowns and you can actually create good solutions to it.

All planning is a waste if you don't even know where the speed humps will lie.

[1] https://en.wikipedia.org/wiki/Chesterton%27s_fence#Chesterto...

If that's the place where someone is, they should be conferring with someone else who knows something instead of trying to fly solo

Blindly going through problem spaces is how you waste your life taking wrong approaches

The promotion process explains way more of what I think you are getting at.

1) losing a critical mass of developers is the beginning of a death spiral

2) the critical mass is smaller than you think

3) you lose the developer months before you know you’ve lost the developer

----------------

The Advanced Automation System began, in concept, in 1981 and ended in 1994, “terminated for convenience” by the government. Billions of dollars were spent on it. It is hard to describe. You can’t learn anything from the name. You know it’s about air traffic control because I told you, or because you read about it in the papers. Maybe part of the problem was the name. It sounds like the system to end all systems.

...At $3.7 billion, the Advanced Automation System was one of the largest civilian computer contracts ever; maybe the largest. It was the largest single contract in IBM’s history. From the moment it was awarded, until near the project’s demise, IBM patted itself on the back. There was something for everyone, beginning with a great ball in Union Station, featuring Chubby Checker and “The Twist”.

...What I saw on the FAA’s Advanced Automation System would have made Sisyphus weep… Whatever commitment and discipline there was… was worn down by a battery of watchfulness that I can only ascribe to fear of failure. In spite of tens of millions of dollars spent on new computers for AAS, the most important piece of equipment on the project was the overhead projector. There were endless meetings attended by dozens of people – as if we were never quite sure about the whole thing. The people in charge simply lacked the confidence and the finesse of the space team: NASA, contractors, and astronaughts.

It has been noted by everyone from the New York Times to the Vice-President of the United States that the main problem on the Advanced Automation System was “changing requirements”. For those involved in large-scale computer systems, that is nothing new. No one can perfectly surmise the shape and feel of a system years in advance. Even replacing some aspect of a system you know by heart is not immune from thinking twice about it. … [But] the requirements churn (it was called) on the Advanced Automation System was not normal. It was the result of our enchantment with the computer-human interface, the CHI. The new controller workstation, fronted by a 20″ by 20″ color display, because it was capable of seemingly endles variety of presentations, mesmerized the population of AAS like the O.J. Simpson trial mesmerized the nation…

The project was handed over to human factor pundits, who then drove the design. Requirements became synonymous with preferences. Thousands of labor-months were spent designing, discussing, and demonstrating the possibilities: colors, fonts, overlays, reversals, serpentine lists, toggling, zooming, opaque windows, the list is huge. It was something to see. (Virtually all of the marketing brochures – produced prematurely and in large numbers – sparkled with some rendition or other of the new controller console.) It just wasn’t usable…

The cost of what turned out to be a 14-year human factors study did not pay off. Shortly before the project was terminated a controller on the CBS evening news said: “It takes me 12 commands to do what I used to do with one.” I believe he spoke for everyone with common sense.

Rummaging through one of the closets at the far end of the hall on the fifth floor one day, looking for some standards document, I found an envelope left by someone who left the company – as many did after so many years advancing against stone, while the wheels of commerce were accelerating on what everyone referred to as “the outside”. It contained “A Brief History Of The Advanced Automation System”. It was printed by hand and left, perhaps inadvertantly, or perhaps with the hope that some anthropologist might some day discover it and make a pronouncement. In every important way, it is the truth:

“A young man, recently hired, devotes years to a specification written to the bit level for programs that will never be coded. Another, to a specification that will be replaced. Programmers marry one another, then divorce and marry someone in another subsystem. Program designs are written to severe formats, then forgotten. The formats endure. A man decides to become a woman and succeeds before system testing starts. As testing approaches, she begins a second career on local television, hosting a show on witchcraft. An architect chases a new technology, then another, then changes his mind and goes into management. A veteran programmer writes the same program a dozen times, then transfers. The price of money increases eight times. Programmers sleep in the halls. Committees convene for years to discuss keystroking. An ambitious training manager builds an encyclopedia of manuals no one will ever use. Decisions are scheduled weeks in advance. Workers sit in the hallways. Notions of computing begin in the epoch of A, edge toward B, then come down hard on A + B. Human factors experts achieve Olympian status. The Berlin Wall collapses. The map of Europe is redrawn. Everything is counted. Quality becomes mixed with quantity. Morale is reduced to a quotient, then counted. Dozens of men and women argue for thousands of hours: What is a requirement? A generation of workers retire. The very mission changes and only a few notice. Programming theories come and go. Managers cling to expectations, like a child to a blanket. Presentations are polished to create an impression, then curbed to cut costs. Then they are studied. The work spikes and spikes again. Offices are changed a dozen times. Management retires and returns. The contractor is sold. Software is blamed. Executives are promoted. The years rip by with no end in sight. A company president gets an idea: make large small. Turn methods over to each programmer. Dress down. Count on the inscrutability of programming. Promote good news. Turn a leaf away from the sun. Maybe start over.”

http://www.smashcompany.com/business/the-worst-software-proj...

It's an immutable fact of life.