Hacker News Reader

Even with just the advances in better programming languages (and newer versions of old languages) and better IDEs we have achieved tremendous productivity increases in the last 30 years. It's just that so far the amount of work has grown to absorb the added productivity.

There are some parallels to induced demand in road construction: when you build a new road to ease traffic, traffic increases to use up that capacity. But that isn't a sign that demand is infinite, it's just that demand is limited by the available resources. If you keep building roads, at some point they will become emptier. Similarly, at some point development productivity will outpace demand, and we will start optimizing our own jobs away.

I'm not convinced. I think new abstractions beget new abstractions. There's so much left to explore in software. Imagine being in the first century of the printing press and imagining that the press is going to put all these poor monks out of business or that there's not much left to explore with writing. Speaking of writing, how much has our word processing technology succeeded in making authors obsolete?

I don't think word processors are the right analogy.

In your example programmers are the monks or the press makers. At some point we're not needed any more (at least at the same scale) since word processors have already been built.

Printers are actually a great analogy. Printing presses became more sophisticated, but the printing business grew even further, guaranteeing lots of jobs in the printing industry. But at some point we reached peak demand, but presses continued requiring fewer and fewer workers. Today there are still people manning the presses of publishing houses and newspapers, but in 200 years of improvement we made the job a much smaller niche.

I worked in the print industry when I was younger. The increase in Posters / bill boards / custom cardboard standing displays actually created so many more print jobs. From phd book binding to custom business print jobs to online demand printing there are so many more things we are printing now.

There are more newspapers but they are all owned by larger players which means different types of machines and parts.

A better example might have been blacksmiths. Although the amount of people making cars is a larger group.

Table 2 shows negative job growth in the printing industry in the last 10 years: https://collegegrad.com/industries/printing

That's too narrow of a group. What about 3-D printing.

If you read the whole article it shows a path to new jobs...

Digital printing has become the fastest growing industry segment as printers embrace this technology. Most commercial printers now do some form of digital printing.

Printing traditionally deals with 2D objects.

Manufacturing deals with making 3D objects.I think 3D printing belongs there.

The 3D printing revolution implies a fusion of manufacturing and printing. This just underscores my point though: abstractions beget new abstractions. 3D printing is an entirely new category that is just starting to come into maturity and reach mass adoption. Who knows what the implications of that are? It could cause a boom in custom made, limited run products. It could help to end our reliance on China for mass production. It's not obvious to me it will lead to less jobs in manufacturing.

There are more programmers coding word processors now than ever before.

> how much has our word processing technology succeeded in making authors obsolete?

makes more sense to think about GPT-2 like language models replacing authors, than word processors

presumably those models will be (are already being) incorporated into word processors?

Demand for the things we want _today_ will be met. But progress leads to new demands, and they are more complicated.

Anthropologists estimate that the work week was at 20 hrs at the end of the Stone Age. We have been inventing new problems in the vacuum created by our successes for, literally, millennia.

I think it was easier to build an acceptable GUI in 2000 with VB or Delphi than it is today with our web stacks.

I also think the standard of “what is acceptable?” was much lower back then.

I'm not sure that's true. Here's the UI hall of shame, highlighting the worst of the 90s: http://hallofshame.gp.co.at/shame.htm

Most of the stuff there would be just... normal now. It's quite unusual for SPAs to have a decent consistent UX. And the slowness would never have been tolerated back in the day.

the author of that page seems to believe that mouse hover feedback is bad, even when it's a simple highlight?!

I think that's mostly it. Design has a much larger role, and form-oriented development with common controls doesn't cut it. You couldn't imagine an app like Facebook in a forms-style UI, it's almost ludicrous to imagine.

Looked at retrospectively, forms were just one step above green screen applications on a terminal, transplanting one set of structural idioms to another, like for like.

If forms are essentially terminal apps, is FB much different from a teletype news service, with hyper-filtered content and an infinite set of data sources?

I see massive sea change in connectivity and immersiveness of today, but not really in what we're trying to achieve.

2001 was Mad OS X Cocoa. 2020 is JavaScript. The standard for UI was higher then, but was lost to the almighty god of cloud-based web apps.

or MS Access, or Hypercard - we've had productivity boosters, just never anything remotely close to eliminating the inherently hard act of "building software".

Yes, but that GUI was only doing local work, we have much higher requirements today.

The GUI was doing local work, but the database could be remote. Delphi's name is even a pun on Oracle.

I'm not saying they were halcyon days. I'm saying that the effort to do things is not necessarily less these days, in part because we have different expectations (not necessarily requirements) today.

It's even easier to do so with no-code, low-code tools.

In 2000 using VB, you can build a GUI, make a working Windows application using a minimum amount of code. Also the documentation (msdn) and the community was really nice.

20 years on MS Access has been one of the quickest lowest code way to build a functional application. What a mess everything is these days in comparison.

If you wanted to build a data entry / collection app with basic validation, querying, filtering etc. you could easily do that with no code in 2000-era Delphi.

With support of today's API's/datasets , you could build more complex apps with similar levels of effort.

Every hard problem gets a 90% working solution that's more than good enough for most companies.

I very much agree with your comment, but allow me a little nitpicking. Solutions aren't 90%, more like 50% or 20% or whatever. It may sound absurd to discuss a number there, since it's more like a way of speaking, just wanted to add that for most problems the solution is barely better than the default option.

In other words, there's still a lot of room for improvement, huge actually but, as you say, it might come in small pieces.

> 0 years ago making a GUI was hard, but VB changed that. Then making a web app was hard, but PHP changed that.

Fortunately, the SPA Plague made it very difficult again.

Plus kubernetes / autoscaling on the backend.....