A mechanical engineer designing a new manufacturing technique or robot is most certainly using their field to automate their field. Most of computing exists because electronic engineers used their field to automate their field. Software is not unique in this respect.

Right, but let's be clear about our terminology here. Automation in mechanical/manufacturing isn't being done by CS grads with skills in RoR employed as software developers. It's being done by MechEng graduates armed with FORTRAN compilers who write a lot of code but don't consider themselves to be developers at all.

How different is a MechEng writing FORTRAN for mechanical engineering from a MechEng writing RoR for trendy widget bean button SV startup?

I'd argue they're both programming, which is sufficient to reap some of the benefits of automation. Software engineering can be described as applying engineering to programming. Any company that benefits from programming would also benefit from the increases in efficiency, reliability, performance, etc. software engineering would bring to programming.

Because in scenario A the main skill being applied is mechanical engineering and in scenario B the main skill being applied is RoR.

If everyone who ever writes a line of code is a "software developer" would you include an Excel VBA 10-liner writer? Probably not, and nor would that person include themselves, they're an accountant (or whatever).

I think of work like FFTW and the Tensor Algebra COmpiler (TACO) as software engineering.

Mechanical engineering didn't have its Lisp. We do.

The steam engine was more of a productivity multiplier than Lisp could ever dream of.

Tool A should modify itself to become Tool B. And Tool B should modify itself to become Tool C and so on...

I think you misunderstood the O-ring explanation by citing that idea as an example. It doesn't mean building AI. It applies to any of those fields you mentioned. Good people in field X work together with other good people in field X in top firms -> multiplicative productivity.

Package managers, that used to be hard to do by hand.

Bundlers and linkers, that stuff used to need skilled engineers.

Many other examples

Most dedicated software engineers exist because this new basic skill hasn’t yet gained widespread adoption as a basic skill in other disciplines. But with time it will, and the number of dedicated software engineers required will decline.

You can create basic good looking iOS or web or android app without all those years and be extremely useful. Many jobs and positions don't require years of study with mentors. Many self taught programmers started like that.

You can do basic data analytics and write selects without years or study too.

There is huge amount of positions that don't require years of study.

We obviously have differing definitions of the word 'useful'.

All of the company's ads (thousands of different line items at any given time) had been entered by hand in to Dart. Things like "make every add weight-based-bulk with weight 100", etc.

I wrote a craptacular Java app using Swing and the Dart API to get a handle on them. I mean - this thing was AWFUL. "Paste your username and password in to this box and type the name of the site you want to work with in that box and click something in this row of 14 buttons" level stuff. They used it to fix their waterfall.

The first month it was an extra 80 grand or so in revenue. The next month I had a new job.

This is based on what I learned in a few months of tinkering as a kid, and a few months of a Java course at Ohlone College in the east bay.

Perhaps you can provide your own, more helpful, definition of useful? Most of what's "useful" is taking something that was a pile of godawful spreadsheets and making it manageable; not something meant for consumers.

An application, in my mind, is truly useful when it not only fulfils a user requirement, but is also dependable, scaleable and maintainable. It's not best practice for a business to base a process around some jury rigged POS that will be thrown away in horror when an experienced developer eventually gets a look at it.

But hey, we can agree to differ on this.

"It's not best practice for a business to base a process around some jury rigged POS "

I suspect you'll find plenty of businesses jury-rig a POS first, and then only fix what needs fixing. Turns out most stuff doesn't need it.

It is ok to throw away things and not everything needs to be scalable.

It is also not best practice to base everything on the idea that everybody must be experienced senior to do anything. Many tasks are suitable for inexperienced juniors, because that is enough and it is small enough to throw it away if it goes bad.

The things that were most useful for people I worked for were not the things that were most difficult to create.

This is absolutely untrue.

There are many many jobs that are effective people doing data analysis in excel spreadsheets.

The people doing this data analysis by hand can greatly improve their ability to do their jobs through simple things like learning how excel macros work. This is programming!

There are tons of low handing fruit in the world, where basic tasks that are being done by hand, could easily be automated by the people doing it, through very simple, easy, "toy" solutions.

I think programming is on the same trajectory. We might not even recognize many of the tools as “programming” (they might look more like spreadsheets). But I think general up take of programming skill will increase.

So you're contending that few people can fluently read or write their own native language?

Similarly I’m suggesting software engineering will be part of many people’s professional work, but will be the sole professional work of few.

The stagnant bog of billing hours to captive (e.g. internal) customers for example does not lend itself very well to a toolmaking microsingularity. Bimodality of pay is at least as much about the task as it about the one one executing.

There is of course still a lot of correlation between ability and high value positions, but that's a natural consequence of matchmaking: both high value positions and high value developers get disproportional choice relative to their lesser peers.