[a_c]

Some angles for me to see this phenomenon

- focus on the fundamentals rather than the particular brand of tools. HTTP, tcp, HTML, OS, CPU, filesystem, etc will almost certainly out last a language, framework and SaaS

- See beyond the assumptions. Solutions are based on assumptions of current problem. Solutions come and go but the fundamental problem of, for example, go from a place to another, rarely change. Try to distill THE problem.

- focus on outcome rather than action. Ask ourselves why such and such actions matter. Do we know why are we implementing a thing, or if a thing we implemented 6 months ago matter at all.

All of these demands consideration beyond do you know "dewalts" or "bosch"

[bawolff]

> focus on the fundamentals rather than the particular brand of tools. HTTP, tcp, HTML, OS, CPU, filesystem, etc will almost certainly out last a language, framework and SaaS

Umm, you are just picking survivorship bias tech things.

Focusing on html was a good choice. Focusing on xhtml2 or vrml would be a bad choice.

HTTP will serve you well. FTP or Gopher not so much.

TCP is a better choice than IPX or SCTP, etc.

Ultimately though, i think the point is to focus on the underlying ideas. You should understand transport protocols not tcp specificly, then you can easily apply that knowledge to QUIC or whatever.

[Robotbeat]

Lindy Principle

[leetrout]

For those curious

> The Lindy effect (also known as Lindy's Law) is a theorized phenomenon by which the future life expectancy of some non-perishable things, like a technology or an idea, is proportional to their current age. Thus, the Lindy effect proposes the longer a period something has survived to exist or be used in the present, the longer its remaining life expectancy.

https://en.wikipedia.org/wiki/Lindy_effect

[marcosdumay]

One really important issue with your first point is that everybody hiring is filtering by experience in SaaS, framework, and as a last resort, language. Nobody is searching for knowledge of the fundamentals.

But anyway, my take is that the problem the article is describing is caused by the existence of way too many fundamentals that can't all be practiced.

[7thaccount]

Both your comment and the parent you're replying to are awesome and match my experience in my area of electrical engineering (includes a lot of software, programming, database needs as well, so fairly relevant).

There are those that have resumes tailored to a single particular thing that if hot right now, will have 1000 recruiters after them to run certain grid studies. I'm more of a fundamentalist (need to think of a better term)for my field where I can tell you the underlying math behind most of the studies performed, familiar with the pro/cons of a dozen different application softwares, can code, use SQL, Linux whatever. I'm also a people person, which is helpful as there is a lot of stakeholder interaction. If you understand the equations/theory and how all the technical junk works....there aren't many roles in my industry I can't get up to speed on in very little time, while having a global understanding for how it fits as a cog in the bigger machine. This isn't true of most in my industry unfortunately. Many many only know a single role, have experience with one tool, don't understand the math behind the tools, can't code or do data analysis... etc.

I've found the broad/general experience to be very valuable, but it's harder to convey that to recruiters sometimes that are looking for "X". I sometimes have to tell them that what I have is highly transferable to "X" and that I have a bunch of other goodies their employer would be very interested in. Sometimes it works if they're communicating with the manager looking to fill the role and not HR. If I can actually talk to someone at the company.... usually not hard to arrange, then they've often offered to make a custom role as well. I know it always isn't the same for software shops or large companies with layers of beauracracy, but that's my experience.

[fluoridation]

>I'm more of a fundamentalist (need to think of a better term)

"I tend to focus more on the fundamentals".

[7thaccount]

Thanks!

[zaptheimpaler]

How do you arrange talking to someone at the company?

[7thaccount]

In my industry there are a lot of big, medium, and small companies. However, it's still somehow a small world. Go to enough major conferences and you meet enough people and start to recognize the faces and before you know it you've made friends with key people at a lot of companies. So it's not too hard to email someone or give them a call and talk about what you're interested in and if they're interested if that makes sense.

[Kranar]

>focus on the fundamentals rather than the particular brand of tools.

But you went on to list a bunch of tools. Sure today HTML, TCP, HTTP seem fundamental, but when they first came out?

CPU is very open ended, what do you mean focus on CPU? Do you mean x86 or do you just mean that there exists a concept called a central processing unit where bits go in and bits come out?

With that said all I have to say on this issue is that there are different strategies to learning, and for some people such as myself, I prefer learning things from the concrete and towards the abstract. I like starting from the actual tools and frameworks and very specific and particular things I can manipulate, and then abstracting from them and building up concepts, as opposed to what it seems many others like to do which is to start from high level concepts.

[starcraft2wol]

The real fundamentals are graphs, trees, stacks, recursion, dp, etc. in other words, computer science.

If someone understands trees they can understand html in one sentence.