On: Staff+ engineers, how do you learn new technologies at a new company?

>The fundamentals are things like files, sockets, TCP/IP, operating systems. Or said differently: things that have been with us since the 20th century. Wisdom I got many years ago from an old hand was to run this thought experiment:

* An HTTP request

* A business object

* A database transaction

That's web architecture, more or less.

I disagree, IMO the fundamentals are: Naming Things, Immutability, Idempotence, Behavior/Workflows/Transactions/Business Processes, Distributed Systems, Cryptography, Algorithms and Data structures, etc.

In addition to technical fundamentals, there are people fundamentals/soft-skills.

> Naming Things, Immutability, Idempotence, Behavior/Workflows/Transactions/Business Processes, Distributed Systems, Cryptography, Algorithms and Data structures, etc.

All of these things are footnotes and implementation details to what I wrote.

You got it the other way round. The things you listed are implementation details, the list you quoted consists of abstract concepts.

The only candidate to be fundamental that you mentioned is a business object (I guess you mean the same thing as an aggregate in DDD jargon).

HTTP request and database transaction[1] are examples of the specific protocols/technologies, and not the fundamentals.

--

1. I guess RDBMS/SQL transaction b/c that's what people usually mean by this term.

Funny, in my mind "business object" is the least important thing out of what I wrote. Imagine it's the 1990s and you are coding some hot thing to drop into cgi-bin. My list now changes to be:

* An HTTP request

* A perl script (or C binary)

* A database transaction

Things like DDD exist to assist humans, not computers.

EDIT: in place of "database transaction" we might also say "reading from persistent durable storage" (like a file system).

1. Your list of fundamentals is what was my level of understanding in the early 90s.

2. Everything exists to assist humans, even when assisting animals and inanimate objects;)

You just gave me PTSD; a coworker (another principal architect), who felt that my strategy was flawed, simply gave as his counter-point "I've been doing this since the early 90's, and I've failed with that strategy over and over in the past" instead of providing any answer to my 2 dozen points in support of my decision.

I'm not that rude. All I pointed out is that I also thought like the GP when I was a junior dev (even taking into account that I was programming since being a kid).

It was only relatively late in my career that I started to learn and think about the basics. The real world has an surprising amount of detail and the software tries to simulate the real world. First I studied the actor model, then agent-based modeling, then domain modeling.

I am not sure what argument you are trying to make or if you are just being snarky at this point. In any case, it seems we disagree and won't come to an understanding. So, wish you the best and take care.