[SamuelAdams]

Listen I would love to learn about fundamentals and hyper threading and sys internals. But I’ve never needed to, because the interfaces I interact with every day (programming languages) do a great job of abstracting that complexity away and handling it well enough that there are never problems I’m aware of.

Isn’t that the natural order of generations? Kids today don’t need to install drivers off floppy disks, instead Apple and Google send devices that are already installed and configured. I don’t need to know how my 50 year old plumbing works, just how to work the faucet. Because the likelihood of an underlying system having a problem is slim to none.

Pair this with the direction this industry is going. Each SWE is expected to produce more with an ever increasing cocktail of tools. It’s no longer good enough to make a memory efficient app that runs on Debian Linux x86. You need to be on desktops and laptops and mobile and half a dozen operating systems. If you build web apps then ok it’s not enough to just have it work in the three web browsers (which change every month now) - you need failover and multi region and cached all across the globe.

Our industry doesn’t incentivize deep understanding. The current goal is delivering more capabilities. Until those incentives change I don’t see why interviewing has to remain as rigid as it usually is.

[CyberDildonics]

I would love to learn about fundamentals

Good, that's a big part of programming.

hyper threading

That's a term from intel for having multiple logical cores in a single real cpu core, it doesn't have anything to do with threaded programming

sys internals

A file system isn't system internals

Kids today don’t need to install drivers off floppy disks, instead Apple and Google send devices that are already installed and configured.

You are talking about refined products, which has nothing to do with creating software.

I don’t need to know how my 50 year old plumbing works

You should if you're going to fix anything or make any changes to your house. It isn't that complicated and it won't be very different from what would be in new construction.

Because the likelihood of an underlying system having a problem is slim to none.

If you put the wrong things down your drain, it will clog. It would be better to understand your plumbing before breaking it.

It’s no longer good enough to make a memory efficient app

I don't think anyone is doing that any more at all.

Our industry doesn’t incentivize deep understanding.

Anyone who uses your work will appreciate you having deep understanding of what you're doing.

[Apocryphon]

> Anyone who uses your work will appreciate you having deep understanding of what you're doing.

But do they really? Do either consumers or investors really care?

[Rury]

Just because there are never problems that you are aware of, doesn't mean there aren't any problems all. You're just choosing to remain ignorant.

BTW, this is also the reason why history tends to repeat itself: subsequent generations disregarding the knowledge their ancestors came to know. You may end up re-inventing the wheel, and not even know that your ancestors made a better one.

[mhss]

I mean c'mon I also enjoy learning about the full stack (have written software at pretty much all layers, embedded, device drivers, middleware, web apps, frontend/backend, distributed systems, databases, etc); but I think that's because I started my career almost 20yrs ago when software was simpler and I've moved on along with the industry. Someone starting their career in the last 5yrs is unlikely to need to follow the same path. At some point there are enough abstractions that you hit diminishing returns in learning it all and there's just so much time for you to do it. I don't blame them.

I never really learned assembly properly for example beyond toying with a few programs early on my career.