It's a bit idealistic to suggest you must be passionate about web development to continue to be relevant.
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.
I think it's funny how the only place that languages that he personally doesn't know are referenced is in a single paragraph.
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.
Maybe I'm just a grumpy old developer, but the idea of learning yet another framework's opinion of exactly what the difference between a Model and Controller class should be, trying to fathom whateverissexy.js and working with yet another "awesome" HTML 5 framework where centering something on a page is still a mystery doesn't fill me with excitement at all.
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.
I don't think that contradicts the OP's position. Indeed learning a new framework's opinion is not exciting, but learning some "hard" CS is fun. For example I was a Ruby on Rails/GRails guy and I took up nodejs 8 months ago. That's a big - and fun - change.
Agreed. That's the difference between lateral and vertical movement. You can go from one framework to the next your whole life, or you can learn the hard stuff.
Companies will hire a guy to do the hard stuff, then hire a couple grunts to write the apps.
I'd say the best way to stay relevant is to complement your knowledge and learn something totally unrelated to web development, and then find a way to combine the two.
If spending an hour a day reading industry blogs and learning a new language or technology every month sounds like work to you, then it’s time to start thinking about an exit strategy.
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.
>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 [...]
I've done a little work in this space.
WP changes, plugins rise and fall, UA's come and go, devices spawn ever more variants, SEs adjust algos, design moves to a new focus, customer expectations alter. The technology changes constantly, if you sit still then offering a quality service becomes impossible.
The background is the commoditisation of web site creation using massive web hosts with automated installation and templating systems. Add in the availability of off-shoring of design and coding, eg via 99designs and similar systems. You have a price squeeze, massively increased competition and a continuously rolling variation in the tech.
Personally I don't think it's possible for a single dev to address all the necessary issues any more. Keeping pace with the changes needed to produce optimised and efficient sites is no longer possible as it has been in the recent past.
The field is maturing, this is an expected effect. I'm looking, as I re-enter the field, to pivot in to site optimisation as a bespoke B2B service
It's hard not to be at least a little cynical about "be passionate" messages. On one hand it's true. On the other hand, it's almost like saying "be brilliant."
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.
> The older I get, the harder I have to work to remain
> relevant.
No. I will be 40 in a few weeks and I consider myself more relevant than many many web developers half my age, even if web development currently is not my main activity (it was however for the last 14 years).
The more you know the easier it gets to grasp new stuff — because it is rarely fundamentally different and you can easily see patterns and where it fits.
Just like with languages—the more you know the easier it gets to learn a new one.
exactly. I think it is an common misconception that everybody has trouble learning new things as they grow older. This might be true for some. However, it seems that if you actually try and don't let the misconception trick you into thinking you can't keep learning, then you won't fall victim to it.
- 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
That sounds more inline with the jobs I've seen floating about for web-devs recently, although there's probably plenty still relying on the good old tools.
I believe he means that if you cannot use an architecture where you push presentation logic to the client as JavaScrpt (aided by an MVC-like framework like Backbone), serve all HTML/CSS/JS statically, and serve data dynamically through a web service (e.g. node + express or express-resource, RoR or Sinatra, MS Web API or WCF), then it's important to know a modern (MVC-based) server-side web framework dynamically generating HTML.
Only learning new stuff is all fine and well until you're tasked with integrating systems and the other vendor provides a SOAP interface and a giant WSDL file for documentation. It's happened to me a lot of times, I can't imagine that I'm unique.
Everyone has their own experiences, but from my view as a freelance web developer constantly working with new clients, I don't see much of this happening. All of this depends on who you are working with though.
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.
> It's very easy to hire someone to turn your PSD's into HTML / CSS
This is definitely true, however things are a little more complicated ... it's not the actual writing of the HTML/CSS that bugs me, but the fact that a PSD is static and often is not accompanied with guidelines on how it should be used.
So for instance if the width of the design is 960px, what are you going to do? Keep it static while centering it on page? What background color should you use? (ever noticed that many designers simply forget about the background around the page?) And also, it's much better to make it dynamic, especially in this age of mobile browsers - so what should you resize? Should the side-bar also resize? By how much? Should it be capped at a max width? Should it fall at the bottom if the total width is too small?
The big problem is that the dynamic parts should also be part of the design. I mean, sure, give me the PSDs because I can do a better job at writing clean and optimized HTML5 and I'm pretty efficient at it too, but I also want an HTML to see it live. It makes my work easier and also it shows me that you've thought about the dynamics at play, so I don't have to fill in.
> 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.
In an ideal world, yes. Unfortunately, you can often end up with HTML templates and CSS stylesheets that might fit the bill visually but simply aren't fit for purpose in other ways. As developers we need to consider factors such as the behaviour of the page and maintainability of the system as a whole. A badly designed stylesheet may be brittle and resistant to change or may even do things in a way that is incompatible with the frameworks and tools that you are using, and many designers aren't even aware that such constraints exist, let alone what problems they may cause.
For example, I was once given a CSS stylesheet to work with (for which the client had paid quite a large sum of money) that declared <span> as a block-level element. This caused no end of chaos when we had to use it along with ASP.NET validator controls on a WebForms page, which of course makes liberal use of <span> tags for inline validation messages.
> It's very easy to hire someone to turn your PSD's into HTML / CSS
My experience has been the opposite. Why? Because understanding how the site's likely to evolve, which items are one-off HTML usage, which need to become generalised components and which CSS is going to be reapplied in similar but slightly different situations through the other X00 pages of the site requires insight and skill.
You can blame the business for not providing a detailed enough spec to the HTML/CSS developer, but having tried providing loads of detail once, it just didn't work.
Bad developer, bad spec - whatever, I do it myself now through necessity to deliver a good job, not through choice.
I do not agree with the overall point. In order to stay relevant you have to build stuff and in building it, you have to constantly improve your techniques, while dealing with scalability (of development, of features, of a bigger consumer base, of growth in general).
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.
The cycles are so much shorter now that what you were doing last year is antiquated, and what you were doing 5 years ago will get you fired.
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.
YES!!! Add "print this page" or "print this very long page" that many "webdevelopers" still don´t know how to handle and see how unbelievably br0ken or at least unfinished the whole concept still is.
Barners-Lee is a god now and untouchable, but I would nominate him for the "most-unfinished-idea"-oscar, if it existed.
The continual references to how much easier it was "ten years ago" makes me wonder if the author was actually in the industry ten years ago, or is merely using it as a shorthand for "grandpa's stories of how it was in his day"
I'm pretty sure I could have written the same thing in 2002 except that the list of technologies would have looked different.
Learning and adapting is a great thing. However, history shows us that real progress is made by societies made up of co-operating specialist elements. One person can certainly be mediocre at the range from Photoshop through to MySQL and jQuery, resulting in a mediocre product. Masters, working together, at each discipline will result in a masterful product (at greater initial expense).
That was maybe true few years ago. But with the web of today with backend and frontend becomming more and more complicated, I personnaly found that expertise is more and more of required.
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.
34 comments
[ 4.7 ms ] story [ 69.3 ms ] threadYou 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.
http://www.amazon.com/Good-They-Cant-Ignore-ebook/dp/B0076DD...
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.
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.
Companies will hire a guy to do the hard stuff, then hire a couple grunts to write the apps.
Currently, I fall into the grunt category.
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.
I've done a little work in this space.
WP changes, plugins rise and fall, UA's come and go, devices spawn ever more variants, SEs adjust algos, design moves to a new focus, customer expectations alter. The technology changes constantly, if you sit still then offering a quality service becomes impossible.
The background is the commoditisation of web site creation using massive web hosts with automated installation and templating systems. Add in the availability of off-shoring of design and coding, eg via 99designs and similar systems. You have a price squeeze, massively increased competition and a continuously rolling variation in the tech.
Personally I don't think it's possible for a single dev to address all the necessary issues any more. Keeping pace with the changes needed to produce optimised and efficient sites is no longer possible as it has been in the recent past.
The field is maturing, this is an expected effect. I'm looking, as I re-enter the field, to pivot in to site optimisation as a bespoke B2B service
Accuracy doesn't appear to be important.
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.
The more you know the easier it gets to grasp new stuff — because it is rarely fundamentally different and you can easily see patterns and where it fits.
Just like with languages—the more you know the easier it gets to learn a new one.
- 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
Uh, how exactly would you push your API to the client?
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 is definitely true, however things are a little more complicated ... it's not the actual writing of the HTML/CSS that bugs me, but the fact that a PSD is static and often is not accompanied with guidelines on how it should be used.
So for instance if the width of the design is 960px, what are you going to do? Keep it static while centering it on page? What background color should you use? (ever noticed that many designers simply forget about the background around the page?) And also, it's much better to make it dynamic, especially in this age of mobile browsers - so what should you resize? Should the side-bar also resize? By how much? Should it be capped at a max width? Should it fall at the bottom if the total width is too small?
The big problem is that the dynamic parts should also be part of the design. I mean, sure, give me the PSDs because I can do a better job at writing clean and optimized HTML5 and I'm pretty efficient at it too, but I also want an HTML to see it live. It makes my work easier and also it shows me that you've thought about the dynamics at play, so I don't have to fill in.
In an ideal world, yes. Unfortunately, you can often end up with HTML templates and CSS stylesheets that might fit the bill visually but simply aren't fit for purpose in other ways. As developers we need to consider factors such as the behaviour of the page and maintainability of the system as a whole. A badly designed stylesheet may be brittle and resistant to change or may even do things in a way that is incompatible with the frameworks and tools that you are using, and many designers aren't even aware that such constraints exist, let alone what problems they may cause.
For example, I was once given a CSS stylesheet to work with (for which the client had paid quite a large sum of money) that declared <span> as a block-level element. This caused no end of chaos when we had to use it along with ASP.NET validator controls on a WebForms page, which of course makes liberal use of <span> tags for inline validation messages.
My experience has been the opposite. Why? Because understanding how the site's likely to evolve, which items are one-off HTML usage, which need to become generalised components and which CSS is going to be reapplied in similar but slightly different situations through the other X00 pages of the site requires insight and skill.
You can blame the business for not providing a detailed enough spec to the HTML/CSS developer, but having tried providing loads of detail once, it just didn't work.
Bad developer, bad spec - whatever, I do it myself now through necessity to deliver a good job, not through choice.
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.
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.
Barners-Lee is a god now and untouchable, but I would nominate him for the "most-unfinished-idea"-oscar, if it existed.
I'm pretty sure I could have written the same thing in 2002 except that the list of technologies would have looked different.
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.