Ask HN: Was GitHub responsible for today's high Skill Obsolescence Rate? | Hacker News Reader

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

4 pointsArlenBales2 comments

Perhaps not be the best term to describe this phenomenon.. Another one often expressed is "Half-Life of Skills" or "Half-Life of Knowledge".

In other words: The rate that your learned skills become obsolete relative to technological advancements in your field. e.g. new libraries, frameworks, etc.

Employers require engineers to outpace this Skill Obsolescence Rate through reskilling, often on our own dime and time. This endless pressure to evolve our skills can be exhausting, especially when it consumes our free time outside work and degrades our work/life balance. I don't feel like other similarly paid professions have as short a skills half-life as we do.

I wondered what caused this weird landscape of the last 15 years. It wasn't like this in the 2000s. I feel like it's mostly Github? Don't get me wrong, Github is amazing. Yet, from the very beginning its fostered a very ego-driven environment amongst unicorn developers to prove their new wheel is better than the last wheel. We've been stuck in wheel factories where every wheel is a different design -- sometimes better, sometimes worse, sometimes a wash -- when the wheels we had from 5 years ago could have built the wagon of today just fine. I don't even think upper management is the problem, I don't think they care what wheel we use, but engineering leads want shiny new things.

I'm currently in a React job that's had a few stressful migrations just in 2024, and I'm tempted to find a Rails job. Its wheel factory is tiny in comparison.

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

Reply on news.ycombinator.com