How to Stay Relevant as a Web Developer

I disagree with this. It could only be true for a very small subset of web developers (freelancers who are working in a variety of languages for many clients), and even then it smacks more of post-hoc justifications for activity like reading blogs and doing 'research' rather than concrete need. What advantages does reading industry blogs each day really give you? What disadvantages does it have (less time for real work)? There is a strange confusion here between work and play, and the silly illustrations accompanying the post don't help its credibility. Given the hyperbole and excited ignorance that passes for insight on most blogs, I'd say it has negative value to read them every day. Once a month would easily work if you want to keep up to date with current trends, but learning a new language each month as a requirement to stay employed is absurd.

There are many kinds of web developer, but just to take a few examples of those who have no need to heavily invest in learning new languages every month:

The majority of web developers work in-house at a firm where the technology in use is mandated, and only changes slowly (and rightly so), because the business depends on it not breaking. They are not threatened at all by the rise of new technologies, and certainly not on the timescale of months.

Then there are many small web developers who make a good living installing, customising, and maintaining CMS systems like wordpress for a wide variety of clients. They don't need to change technologies every month, and frankly it's the last thing their customers want - these developers have chosen a specialisation and will probably stick with it for decades before changing.

Finally there are freelance developers who work on lots of different projects for lots of different clients. They have to stay a little bit more up to date, but the rate of change is measured in years, not months, and there is plenty of time (years) to shift to another platform if the one you have specialised in is not growing but shrinking in usage. The above statement is incorrect even for the developers to whom he expects it to apply.

Now if the timescale were years or decades, I'd agree that a web developer has to be willing to adapt and completely change the tools they are using, but this is hardly a surprise in a fast moving industry. The industry does not change much on the timescale of months though.

Instead , I would prefer to learn something about "hard" computer science or something from a related non-CS discipline such as Math, Statistics , Psychology and find some way to apply that knowledge.

- Javascript, Javascript, Javascript

- Frontend: Backbone / Angular/ whatever MV* framework takes your fancy

- Backend: restful web services, good APIs. MVCs like Rails/Django if you can't push that stuff to the client.

- CSS pre-processors (SASS, Less, etc). Using classes instead of IDs, for modular, re-usable css. OOCSS ideals and methodologies.

- Dependency management via AMD / requireJS.

- Templating (underscore, dust, hogan, etc.) be it client or server-side.

- Page performance (PageSpeed Insights, Chrome Dev tools, etc) - to get content on the page ASAP, in seconds. On that note, to keep up with the Velocity web perf conference.

- Monitoring and Analytics - Real User Monitoring, Synthetic Benchmarks, A/B testing, Dashboards

- Fast development pipelines through something like Mimosa

SEO: You don't need to know any more here than what you have needed to know in the past. Just make sure that you are sticking with your part of the basic webmaster guidelines.

Design in general: Nobody is going to ask a developer who can't design to do design work. That includes UI / UX design. That would be quite silly. Though the developer should probably be able to code the front-end plumbing in addition to the back-end.

HTML / CSS: You should know all of this, but back-end developers generally don't have to do most of the heavy lifting here. It's very easy to hire someone to turn your PSD's into HTML / CSS and then the back-end devs can take it from there.

Build or join an open source project: There are a certain number of people who can benefit from this (you get paid for it by a company which benefits from the work or you are planning to offer paid support for your product) but I believe that projects outside of paid work should pull (or at least try) their own weight in paying for time that went into building that project. This could be money back or it could be utilities which make life easier for you.

Fast moving industry: Not really. Technology in general moves fast, but web development is painfully slow. Part of this has been browsers (and probably the standards groups) holding things back. We can't outrun the caboose.

Lots of people willing to take your job: Really? Where are they? We are supposedly competing on a global level (outsourcing) but I just don't see it. Even when I do have to compete with much lower cost developers, those developers are usually invisible and I never have to worry about them. I live in the Philippines and there is very little web development talent here (partially because all anyone cares about is sending texts.) I imagine much of the rest of the developing world is like that as well.

There are a lot of barriers to entry. Freelancing is difficult on the BUSINESS end, not the technical end. Good English and writing skills go a long way. Much of the technical side you can pick up quickly, but the really be functional enough to be worth much to a team requires a lot of time.

Most important is that you really only have to be good enough to stay a bit ahead of the masses. That's not hard.

One great way to nail all of this stuff is to build an app on the side and ship it. Monetize it, do the SEO, get traffic, etc. You will learn a lot from this process, and you will cover almost everything you need to know as a web developer. You might also make some money from it.

This isn't true in any other field of software development. Has the author not wondered why web development is in such a state of flux? The answer is that the whole concept is a hack - using a document markup system to deliver applications was a poor reinvention of the old thin client idea. Any programmer worth his salt could see this, and so all the early tech like PHP was 'designed' by people who couldn't design. Since then smarter people have tried to fix it, but it's still layer upon layer of hacks, which is why it requires entirely new hacks every year.

I'm pretty sure I could have written the same thing in 2002 except that the list of technologies would have looked different.

You can get along just fine if you are in it for the money for a long time to come. You may be miserable with your work, but if you can perform competently you will have a job for the next 10-15 years minimum.

That said, these are certainly good practices to be following.

If you do that, the other stuff will come naturally. I hate learning new tools. That hasn't stopped me from hitting every single bullet on his list and my list of technologies I worked with is probably bigger than his ... but I learned in response to challenges I faced, not because I feared that I'm no longer relevant (what an awkward notion btw). I couldn't give a damn about what the popular du-jour tools are - I only read about them in passing, then later if I have a concrete problem, maybe I'll remember something about tool X and then I'll go check out if it solves my problem or not.

So basically I consider it far more valuable being able to recognize pain-points, being able to say "this sucks, I need something better" and then act on it. Being able to say NO to certain tools, paradigms and platforms is also a valuable trait. I'm pretty sure that right now developers that worked with and invested time in learning ASP (the original) regret making that choice, especially since far healthier alternatives were available and that are still relevant today. Common sense and good taste should reign supreme (not mentioning a general preference for open-source, but that's another topic for another day).

And that's the healthy attitude. Learning tools and protocols for staying relevant will ensure that you will end up outdated, while the developers that focus on learning about algorithms, design and business will be with us for a really long time.

So what you're saying is, to stay relevant, I have to learn PHP and ASP.net? I'm not sure that qualifies as polyglot programming.

I would think of polyglot as someone who can be effective in a systems language, an interpreted language, a DOM language, and probably shell. I.e. something like C, Python, Javascript, or maybe C++/Java, Perl, Postscript, although that's a pretty wacky combo.

Right now I'm young, single and almost no responsibilities. I love doing what the article suggests, keep learning new stuff, etc., but I'm not too sure I can keep it up for the next X+ years.

And within that time my life could get much more complicated, not to mention the whole industry would keep on changing faster than I can manage, and add to that the unfortunate side-effects of aging.

The older I get, the harder I have to work to remain relevant.

But more and more often, I have been ask to help on project for cleaning the mess.. Not that the tech team is bad but without real expertise in backend, frontend, db or operation.

I love doing the full stack and never stop to learn is great advice. But getting specialised and learning few things very well matter a lot as well otherwise you end been average in loads of things and don't have real value on the market.

Now it s matter of what you are building, web apps become much more complex but it's still a small part of web market.. Where website or webcampain still rules as main business but I m personnaly not interrest to build that.

Accuracy doesn't appear to be important.