1-We do have machinery that performs a resolution of next action/thought/belief (based on external input, current state, etc.) and we possibly just sense that action as "choice"

2-It seems pretty unlikely that the resolution process could be cleanly deterministic and repeatable given quantum stuff, meaning some step in the resolution process hovering on the edge of two options could go either way depending on the brain's electromagnetic soup's current state.

3-Our emotions are critical for our survival, driving choices that help us short and long term, and it seems that one of those core drivers is a sense of agency. Even if we don't have free will in the magic sense of causing electrons (or whatever) to suddenly turn left to support our choice, it would still be critical for us to have a sense that our actions and efforts all matter, so those feelings are probably built into the system.

Note: This assumes there is no special magic somewhere that defies our current understanding of the universe and it just hasn't been figured out yet.

1D barcode is like CSV, it's not going away, it's too simple/useful/cheap.

I was really surprised by the article, I assumed it was going to be the same as my experience which was amazement at having the ability to write instructions that caused the system to do stuff, like make dumb games initially in basic and then better games in assembly.

I would put the noise in the "fact" column.

In agreement with your post, this research that measures cognitive load via EEG and time spent shows that the metrics we use for complexity and readability are only partial matches to what is going on: https://pmc.ncbi.nlm.nih.gov/articles/PMC9942489/

If you don't have a document, then how do you make sure that internal team A and internal team B and internal team C and external vendor D and external vendor E all create the correct things so the entire system actually works?

"Announcer: Yes, it’s Happy Fun Ball! The toy sensation that’ssweeping the

nation! Only $14.95 at participating stores! Get one today!

Warning: Pregnant women, the elderly, and children under 10 should

avoid prolonged exposure to Happy Fun Ball.

Caution: Happy Fun Ball may suddenly accelerate to dangerous speeds.

Happy Fun Ball contains a liquid core, which, if exposed due to rupture,should

not be touched, inhaled, or looked at.

Do not use Happy Fun Ball on concrete.

Discontinue use of Happy Fun Ball if any of the following occurs:

itching

vertigo

dizziness

tingling in extremities

loss of balance or coordination

slurred speech

temporary blindness

profuse sweating

or heart palpitations.

If Happy Fun Ball begins to smoke, get away immediately. Seek shelterand cover head.

Happy Fun Ball may stick to certain types of skin.

When not in use, Happy Fun Ball should be returned to its special containerand kept under

refrigeration. Failure to do so relieves the makers of HappyFun Ball, Wacky Products

Incorporated, and its parent company, GlobalChemical Unlimited, of any and all liability.

Ingredients of Happy Fun Ball include an unknown glowing green substancewhich fell to

Earth, presumably from outer space.

Happy Fun Ball has been shipped to our troops in Saudi Arabia and is beingdropped by our

warplanes on Iraq.

Do not taunt Happy Fun Ball.

Happy Fun Ball comes with a lifetime warranty."

The issue was determined to be a documentation issue and was assigned to that group to add a knowledge base article with additional information.

You could run them in parallel, like a Zoom or Teams mtg, but with each square a different movie.

Would be more entertaining than the next status mtg.

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.