Ask HN: How quickly do web dev skills become obsolete?

Good engineers are good engineers, regardless of how "rusty" they may be with particular technologies. I'd take skilled developers with a breadth of experience in unrelated tech over someone who's only worked with the exact set of technologies I'm aiming to use.

In other words, if I'm building an Electron app I'd prefer a solid engineer who has never written a line of Typescript to someone who only knows Electron.

I would say if an web developer does not follow updates for 3 months he/she is a bit outdated, in 6 months out of web development and you try to make an comeback you will find it very difficult to catch up. 1year or more out there are entirly new stacks, new libraries, new versions, new ways of building things etc.

It not necessary to keep writing stuff following trends you just have to follow updates, newsletters, articles, so you dont struggle when you reenter the market.

As a marketer and more front-end, I occasionally spot when a website is done by someone that has been out of the game >5 years. I see this via design style and toolset used. Several clients with 'new' websites I've been preparing to promote, when asked about the dev given quality concerns it has been clear they are returning to development from a significant break. This has happened on a handful of occasions and its always been greater than 5 years out of the game. That said there could have been plenty that have returned after a gap and I dont notice.

There are fundamental engineering skills that don't change very quickly, and then there's technology stacks. Having a good set of skills in the former category is critical to being a good engineer.

As far as technology stacks go:

* Some domains change faster than others. E.g. front end web dev has rapid change, with new JavaScript frameworks coming out every 6 months. Back end web dev is much more stable.

* Even when change happens, it mostly affects new projects. For example, while C++14 may be fundamentally different, most C++ projects were started years ago. Project I worked on back in 2004-2005 was started in 2000 and is still going strong. So while it's modernized somewhat as the language and compilers and libraries changed, I'm sure it's not at bleeding edge in terms of features.

Thus there are many many places you can work that aren't using the newest/trendiest technology.

Practical advice that results from this:

1. Focusing on fundamental skills that transcend particular technology is more useful than specific technical skills in the long run. (E.g. learning big picture thinking: https://codewithoutrules.com/2016/08/25/the-01x-programmer/).

2. It's good to change projects or companies every once in a while, existing projects are always on older technologies and you get out of touch with latest tech.

3. It's good to keep an eye out on new technologies so you know they exist and can use them when necessary. Doesn't require being an expert or even learning how to use them, just being aware they exist and what they're good for. Since many new technologies are gone after a year this also means you don't overinvest in something - you only pick it up if it's actually useful for the job at hand. (More at https://codewithoutrules.com/2016/10/07/growing-your-toolbox...).

Depends on how concrete they are.

I'm a front-end developer.

I learned the CSS box model and how to write HTML once and use this knowledge for over 10 years now. CSS got a few new selectors since then, but the core stayed the same. Just this month I had to learn Flexbox for React-Native purposes, which felt like learning a whole new CSS, but other than that not much changed.

2011 I learned JavaScript in depth, with all the books, Pro JavaScript Techniques, JavaScript: The Good Parts, etc. Till ES2015 I didn't have to learn much new and all of that is still valid knowledge, I just don't use some of it anymore, because better ES2015 alternatives.

Some people say, there are new frameworks every month and I can't argue much with that. On the other hand, no one forces you to use a new framework every now and then. I used ExtJS, Ember and React in production. I could have learned on of them and used them till now. They're all still maintained and updated. Went away from ExtJS to Ember, because Ember is free and ExtJS rather expensive. Ember didn't have as much out-of-the box as ExtJS, but the stuff made with Ember felt "more web" to me. Also some of the concepts were easier than in ExtJS. Then I switched from Ember to React, because it had even less concepts that were also easier than Ember. Also React seemed to be much more than a simple "web framework" because of things like React-Native or ReactXP.

I almost scored a ExtJS project this year and the lead dev said, I could use most of my ExtJS4 skills, I acquired 2011, in the current version of ExtJS.

So...

Is Web development changing fast? Probably.

Is it changing fundamentally? Probably not.

I partially disagree with what has been said here. Fundamental engineering skills are things you learn at school. Theory over reality, by default, we're all good engineers with a CS degree right? In my opinion you have to implement that theory in real life in order to complete your courses, which is when stacks come into the picture.

Learning a new stack is extremely important for an engineer because it exposes you to a lot of new problems. Things you've never heard of, unless you already got your hands dirty. I'm talking about reading poor API documentations doing reverse engineering work, understanding how to implement a concept and the large gaps between paper and code, how to pick up the right tools for your needs which will save you time and money moving forward, how to integrate, etc. Integration is about %70 of our work today. If you haven't used at least 2 different stacks in your life, you ain't know about integration problems.

So, yes, engineering is a lot more than a set of concepts. I would value someone who jumped into a bunch of different stacks rather than a google-like engineer who doesn't even know how to right HTML (which is a real joke between ex-googlers, we say we didn't even know how to write an HTML page when we left google).

There are two sides to this coin. You can be good as in, you know fundamentals very well and can make connections with familiar concepts, or good as in, readily employable because your skill sets check the right boxes of keywords and names for a recruiter or HR person.

The former doesn't necessarily guarantee the latter. I'm gonna answer with the path less traveled in this thread with regards to your question. When you mention competitiveness, do you actually mean in terms of the job market? If so, unfortunately most people that are your first eyes to your resume when you hit that submit button are not as technically inclined as a programmer. Which is why it's often better to directly reach out to a team lead of the programmer department. Fundamental concepts don't work with 3rd party recruiters either, as most of them are not very language agnostic when it comes to matching you with job opportunities. The exception is with the largest of companies. They'll value fundamental skills more highly because they can absorb the risk of hiring someone to ramp them up with their work environment. Most medium to smaller companies can't afford much ramp up time. From my experience they want you to hit the ground running (seems to be a popular phrase with them) in whatever web framework they use.

So for your benefit, you will look more appealing to hire by applying to larger companies. Smaller companies tend to interview more in concrete framework trivia while the large ones tend to test you on algorithms and other language agnostic concepts.