RaftPeople

Some thoughts:

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.

Your analysis is exactly correct.

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

> You were the exception.

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've listened to the noise on local TV news where they went to the location (here's a youtube link: https://www.youtube.com/watch?v=9wDr2dec474)

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

> Some of the least comprehensible functions I’ve deciphered had quite low cyclomatic complexities.

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/

I was thinking in terms of a broad usage of "design" which tends to match what you wrote about architecture.

> I've never experienced a situation where a software design document meaningfully improved the overall process.

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?

Reminds me of SNL Happy Fun Ball:

"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."

I've reverted to an actual paper notepad.

> nothing was fixed

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

> like literally too, 20k films at let's say 30m average is 400+ continuous, unbroken days worth of content

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.

I don't think you can learn without doing the actual work where normal constraints apply so you can test and see the pros and cons of different approaches to different aspects of the problem(s).

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 built a little front end that allows me to group stuff easily so I can visit the site for short durations during the day without having to repeat sorting through items.

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

> In which countries are Software Engineers not allowed to call themselves engineers unless they are professionally qualified engineers?

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.

> It’s well known that the moat of system of record is how difficult it is to extract your data into another system.

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.

> forecasting-type activities

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

> The paradigm shift from ETL to ELT is what went wrong with Data Lakes.

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

> See also: DB table normalization.

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

> I would charitably say that it’s a function of a different time and place in programming.

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.

Re-route all phone traffic to Comcast Customer Service.

I worked on as400's for about 15 years so I can give you some thoughts:

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.

> I discovered I could count and sing at the same time by visualising the number in my head, instead of using my inner monologue. But it requires more focus to maintain.

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.

> Uncle Bob is a snake oil salesman

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.

> I still think it's far more likely that people aren't describing the same thing. People are very, very bad at interpreting and experiencing their mind's inner workings.

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?

> Have you ever reasoned through a complex coding or maths problem? Tell me, how did you do that without words?

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.

> I'm very reluctant to believe people when they say they don't have an internal monologue.

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.

> I recently encountered a query that deadlocked on itself because it used a parallel execution plan and updated multiple indexes in a manner that the different threads could conflict with each other.

MS SQL?

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

> A biological synapse's weight takes effect whenever its input changes.

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).

Ya, I just started using them in File Explorer recently and I really like them because I frequently had multiple windows open within the same tree, this is much cleaner. I can't believe it took me so long to actually click the "+" and try it.

Those example are exactly the problem that has not been solved yet. They are the best we can do so far but are pretty inadequate to communicate complex designs in a way that a person can easily absorb all of that info and then reason about whether the resulting system is adequate.

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.