[weego]

Maybe I'll burn some Internet points here but

How the computer works, from electrons to transistors, to CPU, assembly, and high-level programming languages.

How the internet/network works, how you send some information from one computer to another, all OSI 7 Layers.

Engineers who fixate on this kind of detail are useless to most businesses most of the time.

If you structure everything on reducing, and value people only on their ability to reduce, everything to first principles of how electricity works then you're wasting everyone's time.

I want senior engineers to:

Be up to date but pragmatic about patterns and solutions Be able to, within minutes of being asked, map that knowledge to new business needs, explain that thinking across non-technical stakeholders through to junior devs Be able to lead and execute a plan with a level of pragmatism that reflects the fact that businesses aren't playgrounds for indulging in their own fixations

If they're more worried about NAND gates then not only are they failing in their duties, the industry has failed in providing meaningful abstractions so that smart people aren't bogged down in cruft.

[neon_electro]

Can you elaborate on "within minutes of being asked"? Is "I need a few hours to chew on this" unacceptable?

[thdc]

I think this is a perfect example of why "We don't have Senior Engineers anymore".

It's hard to show the thinking process to others, so the person who says an answer faster is assumed to be better/more senior.

[sibeliuss]

It's very easy to spot those who are intuitively correct based on past experience, even if they can't necessarily explain. Those people are clearly very senior, and are the folks you want around providing feedback on technical decisions.

[neon_electro]

Yes, but how long should that feedback take? OP mentioned "minutes"; is "hours" unacceptable?

[hansvm]

> If they're more worried about NAND gates then not only are they failing in their duties, the industry has failed in providing meaningful abstractions so that smart people aren't bogged down in cruft.

That is the premise isn't it? Most abstractions have significant failings, and when those failings matter you need to understand what's going on a layer or two down.

Maybe that doesn't line up with the label "senior engineer" at your org, but if you don't have somebody who knows what's going on you're going to have problems. If you're lucky, they're just performance and cost issues and your business has high enough margins to not care. In my experience though, orgs are rarely that lucky. It's embarassingly easy to pick up a 100x performance win in expensive enough applications that it was worth the engineering time, and much of the time you'll knock out a swathe of correctness bugs in the process.

A brief recent example: The way some dev was calling into a given black box implied the black box had to manage arbitrary contention with low max latency and zero bugs. Most devs are bad at handling contention without bugs, most devs are bad at bounding latency, and most devs are bad at handling performance of any kind under contended loads. That's not an expectation you want to put on your black box (it _might_ be up to the task, but why chance it?), and thinking just one layer down strongly suggests you should write your application literally any other way. In practice, the other way had 10x less code, was dead simple to prove correct at the application level, and it solved the performance and correctness bugs we were previously surfacing from the black box.

Do you specifically need to know electrons, transistors, OSI 7, and all that? Eh, maybe. You'll probably need to know some particular subset that looks too low-level now though, and it can be hard to predict which subset that'll be.

[red_admiral]

If we are going to learn everything from the ground up, then I'm going to nitpick and say computers these days run the IETF network stack, not the OSI one. There are not, in fact, exactly 7 layers.