—Everything keeps changing
—I’m spread too thin trying to keep up
—I feel like I’ve lost control over my professional life
—I’m starting to regret getting into web development
—I’m tired of constantly chasing new frameworks to make sure I don’t get replaced by an inexperienced college graduate
—Whatever I try to do to keep up is never enough; the changes never stop coming
- You’ve barely pushed a feature to production when you notice a new major release of a dependency.
- Keeping up with all of the changes in a single framework is next to impossible. Keeping up the framework’s ecosystem is impossible.
- So. Many. New. Packages.
- So. Many. New. Or. Changed. Standards.
- Dozens of new blog posts or articles on how to do stuff appear every day
I can’t keep up; you can’t keep up. Nobody can.
—But I have to keep up! Otherwise, I won’t be able to do my job. Web Development is hell. Maybe I’ll just quit and do something else. Anything else.
People say that web development is unique because of the fast pace and volume of changes in the field. And, since most of us have at least a tangential awareness of other fields through our friends and families (and, in my case, former fields of study), we know that web development seems unique in invoking this feeling of helplessness.
It is unique in overwhelming those of us who practise it, but it isn’t uniquely fast-paced.
I’m not talking here about the difficulty of doing or learning the job.
It’s the task of keeping up with change and new developments in the field once you’re in it. In that regard, web dev isn’t unique.
If anything, compared to fields that still have active research going on (which isn’t the case for software or web dev) like medicine or biotech, the pace of change is arguably much, much lower in web dev.
But, this feeling of being spread too thin, of being unable to keep up, is real. Just not for the reason you think.
So, how do people in other fields keep up with changes in that field? Why is web dev so bad? And, how can we learn from other fields and try not to go mad racing the Red Queen?
“Well, in our country,” said Alice, still panting a little, “you’d generally get to somewhere else—if you run very fast for a long time, as we’ve been doing.”
“A slow sort of country!” said the Queen. “Now, here, you see, it takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!”
First, I’ll tell you about the two approaches that work in other fields but won’t work in web dev because we actually do kind of suck. Pretending otherwise isn’t productive. Then I’ll end with the one approach that genuinely works. It requires work. But that work is still less effort than keeping up with the firehose of change.
1. Other fields have collective or institutional filters
The first method is the one that’s the least useful to us because, as an industry, web dev does not invest in itself as a field. Training is the bare minimum needed to fill jobs. Conferences are mostly for networking. There is little to no active, original research into new approaches or ideas.
But other industries, esp. those who have been around for a while, have institutions and traditions. These provide practitioners with filters to help them stay up-to-date to industry goings-on.
They help you keep up with what’s broadly important, and they have journals and industry rags that help you keep up with what matters; which you then complement by following developments in your primary speciality.
We instead have aggregators that filter very little. Instead of helping us keep up, they become firehoses of content which makes the problem worse.
A web dev equivalent, for example, would be a quarterly publication outlining all of the broadly important news in web dev.
2. They specialise
Cardiologists don’t keep up with experimental Alzheimer’s treatments. Editors and agents in the publishing industry pick the genres they focus on and follow. A developmental linguist specialising in bilingual language acquisition in children isn’t going to be keeping up with the development of natural language processing software models in applied linguistics.
People specialise. They don’t isolate themselves—they’ll still use information from other specialities—but they won’t regard keeping up with those specialities as a core part of their job.
Web dev is unique in how we’ve been trying to roll back the specialisation of the field with notions like Full Stack Web Devs. Fifteen years ago, it seemed obvious to many of us in the industry that the future would involve more specialisation.
Instead, we went the other way and decided: “Hey! Let’s make everybody also code the servers! That’ll save money! Node and browsers are pretty much the same, right? Right?"
We expect people to do the impossible: keep up with everything.
—So, this is hopeless, right? Might as well quit and become an English teacher or something?
There’s one more thing that many fields do that web dev doesn’t. It’s a tactic we can copy as individuals without waiting for a broken industry to fix itself.
3. They stop “Keeping Up” and instead do Research
Students generally start in “keep up” mode. They’re in a new environment like a university. They need to keep up with their coursework, reading, practice, and a new social life. It’s often tough to keep your head above the water. You can do this, as a student, for a few years, but it’s not sustainable for life. So, one of the tasks teachers have, esp. once the students reach the postgraduate stage, is to flick that switch in their minds from “keeping up” mode to “research” mode.
Instead of keeping up with what everybody else is doing, research the task at hand. You let work guide you.
How, exactly, the research is done varies from field to field. Sometimes it’s overtly practice-led like in arts or media. Sometimes it’s directed by your speciality. A lot of the time it’s driven by your thesis question, followed by your research question later in life (Umberto Eco’s How to Write a Thesis explains this one well). The methods and practices vary but new people aren’t expected to just figure it out.
They aren’t expected to keep up with everything and then decide afterwards which bits of everything are related to their work (or not).
These fields spend a lot of effort teaching new entrants research methodology. Choosing your speciality or your question is generally regarded as a Pretty Damn Important Moment.
Web dev as a field doesn’t have a common research methodology or standard tactics for keeping up with change. That’s why we’re all overwhelmed. Not because it’s uniquely fast-paced but because it’s unique in how it doesn’t invest in people, training or methodology.
We don’t teach people to ask the right questions.
The strategy you need to apply is simple: you keep following your feeds, your social media, your subreddits, etc., but you now default to not reading any of it.
You only check out articles, podcasts, or videos that are directly relevant to your Work Questions. (More on that later.) Even then, you still don’t read, watch, or listen to them. You scan them above the fold and ask yourself:
Can I defer reading this until I’m doing the task?
It’s useful to have a library of articles that you know are good references for tasks you may or may not need to do in the future. You don’t need to read any of them right away. Just get into practice at spotting them and filing them away.
There’s no point in religiously reading every blog post on accessible drag and drop in React, or state management with hooks, whenever these articles pop up in your feed. Bookmark them and use them as references when you’re doing that task.
Does this relate to one of my Work Questions?
If it doesn’t touch on one of your long-term goals and isn’t a reference you can use later on to guide you in a task, stop reading and close the tab.
If it’s important it’ll come across your feed again and again. Paradigm-shifting changes in web dev are rare (AJAX, jQuery, React, CSS Media Queries, CSS Grid, CSS Variables, ESM modules). When they do arrive they’ll become so loud and so prevalent in your web dev community that you’d have to work hard not to notice them. Even then, the transition usually takes years.
People are still building projects that don’t use CSS Grid or Variables and bundle together CommonJS modules. Old methods keep on working.
If it does touch on a Work Question you generally need to do a first-pass read to decide how important it is?
Read through it without looking up words or phrases you don’t understand and skip over the hard-to-parse sentences. The goal is to discover whether a deep read is worth the investment or not, so you don’t want to spend too much time on this read.
Sometimes you find articles that don’t add anything to what you know—don’t materially affect the Question—but are still useful references to have, esp. if you need to convey an idea or method to other people, like your colleagues.
Sometimes you’ll find that the article is worth a deep read. You either put in the time right away and give it a deeper re-read, or you file it away to study later.
For example, one of my Work Questions is “How can I make a web UI that doesn’t feel flat but also isn’t a skeuomorphic cartoon pastiche of real-world objects?”. Anything that touches on filters, gradients, or texture effects in CSS will catch my interest. When Ahmad Shadeed’s article on radial and conic gradients came across my feed I scanned it to make sure it was relevant. Then I filed it away for re-read later (which, to be fair, just involved opening as a tab in the browser window that holds research related to current work). After re-reading, I bookmarked it properly so that I could refer to it later when I’m using gradient effects.
If it doesn’t relate to a Work Question and isn’t a how-to reference for a future task, ignore it and move on
Really. I don’t need to follow the ins and outs of React state management. You don’t need to know about the state of modern JS support in XHTML. You should be ignoring most of the goings-on in the web development community.
How do we choose our Work Questions?
Now we get to the tricky part. The good news is that you don’t need to figure this out in one go. You can start with many vague questions and, as you do your research, you either cross them off or rephrase them to become more specific.
They are supposed to change over time. Some of them should be dictated by your current tasks. Others can be more aspirational: ask questions related to the work you want to be doing.
For example, here are the questions that guide my web dev research when it comes to my Colophon Cards project:
- How do you provide a lightweight yet nicely interactive front end? Anything that comes across my feed that’s about doing more with less—smaller bundle sizes, fewer dependencies, faster loading, etc.—on the front end piques my interest as a possible answer.
- How can I better manage the project’s CSS? Continue to use bundling? Continue to use CUBE? How do the approaches from Every Layout work in this context?
- As I wrote above: How can I make a web UI that doesn’t feel flat but also isn’t a skeuomorphic cartoon pastiche of real-world objects? I think UX generally suffers in flat UI design as it doesn’t leverage layering, affordances, and metaphors to the degree that it could. I’m very curious about breaking out of flatland.
- Can I integrate accessibility features into UX designs as obvious-yet-attractive affordances instead of constantly being hidden from view? Wabi-sabi used to be a common reference in web design circles. An example of this would be to make focus styles overt and obvious. But in an aesthetically pleasing way.
- How can we make browser-based reading more powerful, more useful, and more accessible than other forms of reading?
- Is it possible to make Multi-Page Apps as engaging and ‘snazzy’ as Single-Page-Apps?
- What are the simplest kinds of state management tactics that’ll work for a web app? Esp. in a vanilla JS or web component-based app.
- Is it possible to build this kind of app using only serverless-style services without having to geta PhD in AWS and CloudFormation?
- What are the best ways to implement unit, integration, and end-to-end testing for a vanilla JS or web components app?
- SVG WTF? Just, SVG. WTF? I need to understand SVG better.
You’ll note that these questions range from the high level to the low level. Some of them focus on practical details of a specific technology. Others are more ‘chewable’. Some of them are specific and will eventually have a clear answer. Others are open-ended and represent the ongoing development of a work philosophy or outlook.
The questions change with the job. When I’ve had projects that involve PDF-rendering in the browser, then that (“What’s the best way to render a PDF in a browser?") became one of my Work Questions. “How can CSS Grids help with my layouts?” was once a big question. But I dropped it once I felt I had a handle on it. I still rely on the reference articles I bookmarked when I was doing that research.
I set aside about an hour or two a day for research.
I sit down with a cup of coffee and go through my social media, my feed reader, and a couple of select online sources. I filter out articles and papers based on whether they touch on one of my questions or whether they look like a ‘how-to’ that I can file away.
I rarely need to spend the entire two hours. It isn’t unusual for me to go over all of my sources in about 30 minutes and come away with nothing relevant. That’s when I switch to active research and proactively look for sources and references related to the questions I have.
And that’s how “keeping up” stops being a chore and becomes an interest-driven research activity that feeds your enthusiasm instead of draining it.