You need a limited budget, limited timeline, limited capabilities in team and software tools+systems, and you need to be on the hook for support, maintenance and long term extensibility.

Software engineering is an optimization problem balancing all of the above and much more. There is no one answer to any problem, but more of a general sweet-ish spot (or more like region than spot) of balancing the competing priorities.

I have some checkboxes on articles and a couple manual buttons to trigger movement between groups when I'm ready.

Groups:

New - Not seen by my utility yet

Like Group A - Definitely want to come back to it later (maybe didn't complete, or has interesting comments still active)

Like Group B - Maybe want to come back to it later (maybe it's done, or maybe I'm only partially interested)

Old Group A - Most recent group of links pushed from New - separate from Old Group B to reduce volume of stuff to wade through if I change my mind about something

Old Group B - Older/definitely no longer interested stuff

I think a better question is: what is the criteria those countries use to determine if someone can use the engineer title?

In general the software industry is still in an early confused state about standards, approaches, skills, etc.

Should we be using functional techniques? Object? Both? Relational? Column store? Push? Pull? etc.

The number of ways to build a working system is enormous and we have a fad-of-the-month every 5 years which starts as a silver bullet and always settles down to be just another option for another set of use cases.

I think that is one aspect but not the biggest issue.

The specific shape of data and shape of functionality gets built around for decades due to incompleteness of any system, expanding dependencies and changing business needs.

Decades of building around the system results in a mountain of work when trying to replace the system, typically a larger body of work than implementing the base system itself.

AI/ML yes, LLM's no (unless someone is naively using LLM's for forecasting)

It wasn't exactly the shift from ETL to ELT, it was the stated goal of putting "T" on read with no intermediate schema.

In my experience, it's always (since way before data lakes) been a multi-step process and I don't know how it's even possible to do the data lake strategy without re-creating a ton of transforms over and over:

1-Extract

2-Possibly do some transforms early due to specific operational/technical reasons

3-Load - even before "ELT" became a term, load without transform was happening due to constraints, like the transforms requiring data from separate operational systems to even be possible

4-Transform 1 - Foundational stuff like converting unique operational schemas (due to technical or functional reasons) into more natural schemas, easier processing in later steps

5-Transform 2 - Unifying core data that spans multiple operational systems (e.g. order fulfillment txn appears naturally in different systems but for different/overlapping business reasons and with some differences in identifiers and attributes)

6-Transform 3 - First pass at foundational target state

7-Transform 4 - Possibly more, or possibly not

8-Consume valuable data

Pragmatic approach: generally end up with an average of around 2.72 normalization across all tables.

I really think it was just one persons opinion that got published. I started in the 80's and at each software company I worked at they had standard styles that I think we're very clean and organized without being overly dogmatic in any one direction.

1-Stability: The as400 is the most robust/stable environment I've ever worked on for business applications. Many of our customers had no IT staff, just the accounting staff that would put in backup tapes, and the machines would run unattended for years until an OS version upgrade.

You're right that the underlying stuff that made it robust was not really visible or accessible to the developer, but it was the foundation that created a solid environment.

2-OS foundational capabilities: The integrated database, job scheduler, message queues, 5250 terminals with some nice capabilities (e.g. "subfiles" that are basically data tables), control language, etc. all combined to make a nice foundation for creating ERP style business apps.

3-RPG: I worked in RPG after coming from assembly language (video games) and my observation to the guys at the company was "hey, it's just like assembly, an opcode and a couple operands". It was a primitive language but because of the foundational items in #2, it only needed to move data, validate data and sometimes complex calcs, so productivity was good.

4-Non-ERP/CRUD backoffice apps: When the internet arrived and our customers wanted to sell online it became clear that the as400 was a square peg and the internet was a round hole. The foundational elements were designed for a different style of workload and interaction.

5-Openness (lack of): There were definitely times when the limits of the language and workload assumptions were different from the problem at hand (beyond just the internet/ecom stuff). There were times when we really felt like our hands were tied and couldn't just do what was needed for problem X, either using different languages or utilities.

One example was a pro basketball team ticketing/seat reservation system. Game packages could be different number of games (e.g. 10, 20, entire season) and number of seats in group could vary, and various other variables created a challenging search problem. We succeeded by getting creative with the DB and indexing and our code, but we felt boxed in while doing it.

Funny timing for this comment, just last week I was running slowly on the treadmill and was counting my steps due to curiosity about steps vs time, and decided to count using images. It definitely takes more effort but I think it's because I hadn't tried it before.

I would hold the tens digit image static and repaint the ones digit until it rolled to the next tens digit, which meant very limited effort was required to retain the tens digit image and most effort was transitioning the ones digit.

The ones digit would not just instantly flash in place, it took a small amount of time and some noticeable deliberate effort for the process to complete, and then it was just in maintenance mode until the next transition.

I think it's not as bad as a snake oil salesman that knew their product was not good.

In reality, most software design and dev advice is well intentioned but is just based on personal opinion, they don't really have much science behind them.

This is not to say they should be completely ignored, it means there should be a healthy does of using your own brain and experience on any of this stuff.

Are you thinking that the term "internal monologue" is being interpreted too literally and that any system of organized thought, even one without the apparent usage of words, could still be considered an internal monologue?

When I'm working through complex software design issues it's almost all abstract images/conceptual.

Testing different design approaches and options are all non-verbal, I imagine the system using abstract imagery that represents the different concepts.

Why would you choose internal monologue as the default position and no internal monologue needs to be proved?

It seems the natural position for an unknown would be to assume it is not the case unless there is evidence for it.

MS SQL?

We've had to set MAXDOP 1 on some specific queries for a long time.

I don't think it makes sense to try to compare our brains to ANN's, they are apples and oranges.

A synapse's weight is dynamically modulated by the astrocyte on multiple time scales (millisecond, sub-second, minutes), and the astrocyte itself is receiving inputs and performing computation (in addition to impacting the neural network).

As complexity grows, the value of those artifacts reaches significant limits that are typically dealt with through brute-force mental effort of the people involved.