That's what I mean by "precious few".

I am continuously hiring new people, mostly senior devs and tech leads. Maybe one in a hundred has any understanding of what virtual memory is. Or why one process can't access memory of another process and, if you really want it, how to set it up.

Two decades ago that was common knowledge.

It went away just as the knowledge of how networking works. Currently, if they try to open a connection and it does not work they are pretty much at a complete loss to what happened, where and how to fix it. Aside maybe from a simple problem like DNS resolution error (and not even that -- most devs don't understand how DNS propagation works, for example).

So if those problems happen, they are mostly deferring to me as a guy who can solve every problem. I see no clear path to achieving a goal of having someone else to learn to do the same.

>It went away just as the knowledge of how networking works. Currently, if they try to open a connection and it does not work they are pretty much at a complete loss to what happened, where and how to fix it

also, devs seem to not understand that a computer network is basically a massive distributed system (on the routing level anyways), and that things inside this system can and do fail nearly constantly.

things like latency, endpoint connectivity and available bandwith is not a fixed given!.

So many devs in my experience seem to write code which assumes the network is always available with the same characteristics as the point in time in which they wrote the software.

Not to even mention devs are even entire companies building HA mechanisms which rely on ethernet connectivity to work, making it very hard if not impossible to stretch them properly across network segments/locations without stretching ethernet. (which brings its own set of problems).

The number of times people write code that immediately tries hitting the DB again upon failure - with no back off or jitter - is entirely too high.

Assume everything is broken, all the time.

Im from the new breed. I'd like to know all that but, where do I get the money? It's not like I can spend so much time tinkering without producing.

If at least was able to purchease a home I wouldnt have this pressure.

I guess in the US is different because people have higher salaries.

You have to have the time/resources to dive that deep. Or maybe it's your job, line some of the folks in a local company that work in hard problems.

But even they are not that well payed.

One little-appreciated fact is that many of the most accomplished and knowledgable engineers were tinkerers from an early age. If you start your computing journey at the age of 18 with a compsci degree, you might already be a decade behind some of your peers.

It’s not too different from pro tennis players, who typically start playing before the age of 8.

For those at the top of the game, computing is a calling as much as a job. They will do substantial learning on their own initiative.

You might be a decade behind, but there's still diminishing returns kicking in hard even just a few years in. That's disregarding inefficient learning and what else which may close the gap further.

Your latter point is far more important to the matter. Those who treat it as a passion more so than a job, are more likely to be the trendsetters. Growing up and being free from responsibilities makes it easier for that thing to become your passion.

And let's also not forget, a few decades ago, computers weren't exactly a cheap thing for parents with little understanding to let their kids tinker with at will. Being born in a family with enough wealth to get a computer, enough wealth / understanding to let a kid tinker with it, was an immense boon. A long with anything that type of family tends to have going for it alongside wealth. It's not that far-fetched an idea that it's the other things, rather than the early age interest of the kid itself, that got them into such a position later in life.

This is literally free knowledge spread across many MOOCS, YouTube videos and Unix man pages. You can tinker with it with a Raspberry Pi.

Finding time to learn if this is not your day job is another problem, but a solvable one if you're willing to learn.

I don't own a home or work in the US, but I had a computer when I grew up. I spent a bunch of time playing with it, and here we are

It's certainly much easier to find the time before you have to support yourself

Why do you need money to learn things? The internet exists. The library exists. Meetups exist. Go out and learn things you are interested in.

Not dying of hunger is a good motivator.

If you are dying of hunger I doubt you have the time to be posting about it on hacker news.

The thing is as someone who twenty plus years ago was able to write the webserver at socket level and so on, if you handed me a keyboard today I have forgotten all the context, the skills - they have pages out of my brain and now have redis and javascript and hadoop.

But you know those things exist and how things relate to each other and affect each other, or could affect each other, and you don't need to already have a mental text book in ram to solve a problem. I don't know you and yet I know this.

How often does a front-end developer need to know about /proc/pid/mem?

I think it's important to keep things in perspective here - when I took my first programming job the first week was setup. On my team, our onboarding has you branch, review and merge on your first day. Those abstractions allow for people to focus on the areas they're working on, and iterate there. A game developer doesn't need to understand the complexities around js type conversions, any more than a js developer needs to understands rendering thread latency in a browser.

On every team I've ever worked on, that headspace from the team would have been much better served by understanding the product and project, IMO.

"How often does a front-end developer need to know about /proc/pid/mem?"

It's not about any particular detail, obviously.

He himself does not ever have had to previously see /proc/pid/mem before in his life in order to solve a problem involving it.

However many times a day he gets a question of any kind, that's how often.

Great question - is their app deployed to a container? In that case, they should know about it, because buried deep under layers of abstraction are cgroups. Answering questions like “why did Node try to use 32 cores” is much easier when you understand this.

Unless they're working in that space they won't know it. And that's fine. There's enough to keep in our memory and tools and resources for us to look up information if we need it.