There are a lot of terms in software development that have been co-opted from other disciplines and misrepresent a lot of development work, including 'engineering' and 'architecture'.

I think it's helpful to think of engineering as a _process_ instead of a role, and the reality is that a lot of development work doesn't necessarily rely on the strong engineering methodology (e.g. measurement, material properties, tolerances, modelling, etc.) that the people developing the software might imagine just based on the number of job adverts for 'engineers'.

This isn't a bad thing. There are hundreds or thousands of different but equally valid solutions to getting a program to do a thing, but not recognising that most code writing is somewhere between a art and engineering and is neither a purely artistic discipline but also rarely a purely engineering one is useful.

The kinds of engineering and architecture that people think of in software development only really represent common practices and shared language (e.g. design patterns, architectural patterns) and not a strong engineering practice or any kind of truth about how software actually runs.

(Unless you're writing software for launching rockets, in which case the engineering _process_ porbably should be strong).

> the reality is that a lot of development work doesn't necessarily rely on the strong engineering methodology (e.g. measurement, material properties, tolerances, modelling, etc.)

It's probably true that a lot of development work doesn't rely on those. It's probably also true that the work other kinds of engineers do also don't.

That said, when engineering software systems, those are very important. Measurement: resource sizing, observability; tolerances: backoffs, back pressure, queues, topics, buffers; modelling: types, syntax, data analytics...

There's a whole class of developers out there that are not aware or very good at those. And that's fine. There's a place for them in the market. You don't need an engineer to work on your floor joists or your plumbing. Sure you can have one, but you can also hire a builder or DIY it all yourself.

So true and it makes me feel better to have this mental model. I find it useful for simple things that are perhaps just beyond search and copy paste but sometimes wonder if the more technical stuff is not even quite right as it is possible to sort of brainwash yourself into not thinking clearly when nagging an llm into being reasonable on something it has a hard time with.

Completely agree. If anything LLMs have just made this completely transparent and are revealing that actual engineering in software is limited to rare cases.

All of theses middling developers who are so excited about these tools don't seem to realize that they are perfectly primed to eventually eliminate precisely the kind of worker responsible for hooking up existing APIs for solved problems into a web app, the kind of work the market hitherto greatly over esteemed and overpaid for isn't my going to be so esteemed or highly valued anymore. The only real work that will remain is actual hard engineering work (solving novel technical modeling problems, not just plugging apis together). All of these lazy devs are hyped for precisely the automation that's goin. to significantly reduce their pay and labor prospects in the long term lol. I'm shocked at times at how people can fail to see the writing on the wall when it's been written in gargantuan red ink

Software engineering work never ends, so they'll just work faster.

Right yes, I imagine most people who program are in companies that have nothing to do with high tech, writing SQL or scripts or CRUD apps. LLMs are probably amazing here.

Writing SQL in the context of 20 years old application with 2500 stored procedures just inside one of many databases is not so easy for LLM.