This would require well defined tickets + work items with scope that is realistic, and an entire system behind the creation of these items which entails product + process understanding (not to mention designing tickets in a way which is minimally exploitable).

If this could happen we would advance the state of project management into the sci-fi era.

The number of devs is well on its way to exceeding available work, so none of what you stipulate is necessary

Employers can simply say : "this ticket is three hours of work and that is all that we will pay", and your choice will be take it or leave it

We are well on our way to most tech jobs becoming "McJobs", this is one more step...HN really has its collective head buried in the sand in this regard imho

I already see this at my employer (well known HW maker)...more and more dev work falls to QA staff who are poorly compensated and have no mobility....QA has just become code for "low end dev" and they do nothing but pull from JIRA (advice: never take a QA job in tech if you desire good pay or mobility)

> Employers can simply say : "this ticket is three hours of work and that is all that we will pay", and your choice will be take it or leave it

In a way, a more empowering choice than being simply ordered to do something impossible.

Employees can simply say: "Dear boss, I bet it will be more like ten hours of work, but if you stand by your estimate you can do it yourself or spend some time looking for an optimist".

If the clock is ticking, estimates aren't going to be very aggressive; when no competent person accepts tickets nothing gets done.

Our debt-saturated world means this is never an issue

Car payments, Klarna bills, student loans, credit card bills, rent...these are all the pitchforks prodding people to take the work...America has a massive pool of must-workers

This is a scary scenario and certainly possible, but on the other hand you can find people saying this was about to happen in the 90s and it really didn't. Some jobs can be done the way you describe, some can't and it's hard to know which kind you have without wasting money. If your business is profitable and relies on software, you are much better off having a programmer on staff.

It keeps turning out that there is more to programming than meets the eye, that we are very important to the success of the business, and that we need to be closely connected to the business to be able to deliver great solutions.

It's important to think about these dark possibilities and resist them, but it's also important to realize these scenarios have a history of failing to materialize.

He has a point, though.

The worldwide supply of programmers has increased 10 - 100 - 1000x since the 1990s. The world has changed.

Quantity has a quality all its own.

> The number of devs is well on its way to exceeding available work

Is this something you've read or that you made up?

Seems like BLS is projecting programmer jobs to decrease by 11% by 2032 [0]. This isn’t perfect, but seems like a pretty reputable source for employment trends.

Of course it also says median salary is $100k and I haven’t been able to hire a programmer at $100k in 20 years. So I think there’s a lot of variability.

[0] https://www.bls.gov/ooh/computer-and-information-technology/...

BLS also projects "Software Developer" jobs to increase by 25% by 2032 [0]. Without more detail on how these roles are categorized, hard to say if this is a valuable source of data.

[0] https://www.bls.gov/ooh/computer-and-information-technology/...

The latter seems to be the primary category, with 1,795,300 jobs vs 147,400 computer programmers.

And combining the -11% of 147K and +25% of 1.8M, BLS is projecting a net increase of over 400K jobs in the two categories.

But that includes QA and testers.

And the feature won't ever get completed to any satisfactory standard beyond the bare minimum.

Anything that requires more than three hours of effort or actual understanding of the product domain will remain the purview of smaller, more flexible entities, and the big creaky exploitative ticket machine will have it's lunch eaten by others that are more effective at execution.

> And the feature won't ever get completed to any satisfactory standard beyond the bare minimum.

so basically, just like today

The difference between working 32 hours a week and 40 is far, far less than the difference between working a fixed number of hours and a variable number that your employer dictates. What's more, the article supports even the 32 hour/week being an option.

Every employee has a certain amount of overhead per employee whether that is 1:1s, hr, benefits, forms, etc and your cost to employer is beyond salary which they are incentivized to minimize.

This is overly simple:

Let's make the incorrect assumption all hours are equal.

- 40 hours making $4000, at $100/hr, with $1000 overhead, for a total cost of $5000, or 125/hr.

- 32 hours making $3200, at 100/hr, with $1000 overhead is a total cost of $4200, 131/hr

So let's ballpark and say you need 10% increase in productivity to make the cost of an equally efficient worker working 80% time. I'm not sure I've worked at a company that can estimate individual performance with that margin.

Why do we need to increase productivity to make this work? When productivity increases by other means compensation doesn't increase nor do hours decrease. That productivity gain is happily eaten up by the company. This looks like a case of companies wanting to have their cake and eat it too.

I'm making a strawman actuarial argument; basically there is little incentive to the Company and they would need to see a productivity increase if pay is linear scaled to match hours due to the per employee overhead.