Ask HN: Was GitHub responsible for today's high Skill Obsolescence Rate?

I think part of the problem you describe comes from confusing “skills” and “tools,” where tools can refer to languages, frameworks, APIs, etc.

Employers may have exacerbated the problem, but it seems to me that programmers have mostly done it to themselves. Ignore fundamental knowledge and focus on narrow expertise with a framework for long enough and you will feel obsolete.

The original post concludes with mentioning React and Rails — tools, not skills. Understanding web development in terms of HTTP, HTMl, CSS, Javascript, server-side languages, relational databases, and so on describes “skills” to me.

By analogy, I have learned the skills required to drive a car and ride a motorcycle. Those skills transfer to almost every car and motorcycle. I don’t call myself a BMW rider or Toyota driver, and then ignore all other brands. Why do programmers pigeonhole themselves and specialize so narrowly they constantly risk obsolescence?

In any case I don’t see how Github contributes to the problem. No one has to follow every fad and fashion. The fundamentals of software development don’t change very fast, but new frills and coats of paint come out every day.

No, it's not Github's fault.

If you grasp the root force that is driving this constant release of new tech and new libraries you will be able to escape the hustle of keeping up with it.

Parameter 1: Software and web development is historically very young. In this context it is very natural that humanity has to do some trial amd error to figure it out. For instance, operating systems programming has matured more since it has had many nore decades to grow than web app development.

Parameter 2: Web development has grown to be very highly abstracted. Abstraction, by definition, hides lower level knowledge. When a developer learns to code using the highest level of abstractions available (eg react, next) then they haven't grasped the basics of the platform. This means that 1) they do not trully grasp what problem react or Next actually solve 2) when a technical problem arises, they only think of the solution only within the context of that abstraction (releasing even more abstracted sister libraries)

Parameter 3: Libraries are built to solve problem based on some assumptions. As technology progresses, these assumptions keep changing. This leads to akward evolution in some libraries to address yhe changing assumptions or the creation of new libraries that leverage the new assumptions. For instance check how vite has been built on top of a modern javascript stack that didn't exist when webpack came out.

Put all these together and you have an exploding coctail of change as you described it. What should you do?

Basics - Basics - Basics

The more you try to understand the base platform, the more you will understand it's progress, the reason libraries exist, you will judge them better on whether they do a good job or not. Then, "knowing" a new library will be a matter of reading it's docs and saying to your employer "Yeah, it's fine, I have played with it, not super experiemced but i can handle it and will learn it pretty quick". I always learn new libs on the job, never in my free time.

In my free time (and i suggest it for you) read the rfcs. Read http rfc, read html spec, read C, read the js apis, etc, etc