The idea that a film artist doesn’t need to know how a camera works is laughable. And not just the camera, but different film stock, processing methods, lenses, lighting, and the interaction of all those as well as the subject being shot. The level of attention to detail in great films is wild.
"I need to figure out what brand of paints and brushes this painter used so I can paint like this."
Of course not! It's the painter that determines the quality of the painting and not the maker of the tools. A great painter (or filmmaker or cook or software engineer or ...) will understand the unique attributes of the tools available and leverage those to do great work, whether that's in oil or water, black & white or color, Python or Rust. A difference between experts and non-experts is that experts will find opportunity in the constraints of the tools they have available, and not only frustration.
I believe this extends to engineering managers. I want managers who are good at spotting the unique advantages of each person on the team and are good at structuring the roadmap and individual projects to let the team get the most out of those advantages. And I want them to spot where advantages and disadvantages can be paired to enable learning. All this helps teams see how valuable their teammates can be and how much they can learn from each other. I've seen it result in teams achieving remarkable outcomes while having a ton of fun doing it.
Scaling this up further... I want senior management that is in tune with the unique advantages of different parts of the org, and who then use that knowledge to make better decisions about direction. We can go in direction A, B, or C... that group over there is great at A, so let's pick that and give it to that group. Some see Conway's Law as a sort of "doom", but I've seen it used to the org's advantage with this kind of thinking.
This is something I'm pushing towards in our overall platform - I'm kind of trying to identify both related things, as well as things of similar necessary velocity or lack of velocity and try to put these into a team or into teams close together. If a team has a large mismatch of velocity between their topics, it tends to be straining, tbh.
For example, frontend teams or teams largely fronting AI features with little persistence to manage want to and need to be fast. These guys want to be able to throw stuff at a wall and see what it sticks, or they want to react to shifting trends very quickly. All good and well. It's valid practice in the right situation.
On the other hand, we're a team handling databases, long term archiving, hardware acquisition and management. Handling these correctly is a direct plug keeping customers lawyers down. Yet,sometimes lead time of hardware purchases, racking, configuration, qualification and full utilization can be a quarter of a year. Note that this doesn't apply to standard requests like restores, database provisioning and such. We can stand up necessary standard persistences for new applications within hours if necessary, or a day or two usually.
In the past, we had these different velocities mixed up in teams and it was a mess and frustration for everyone. We were in the middle of larger storage migrations that require some care, and suddenly there's a sales-project crashing in with an ASAP tag preempting everything else. Or a frontend dev suddenly had to do capacity planning for a CI cluster. Overall silly.
Now the projects requiring planning, capacity estimations, budgets and honestly, old-school project planning are in our court and the dev-teams can rely on that and run free and wild however they want. It's much more effective for both sides.
The Aliens documentary is really good for this. So much of the special effects on the film are in camera tricks.
Cameron is a really interesting person to study because he absolutely mastered every part of film making before deciding to go all in on Avatar and ubiquitous 3d effects.
All of life is “energy conversion”. All of programming is “translation”. All programming is “solving problems”. Etc.
Not all abstractions generalize (in an useful way).