The overwhelming web
Learning curves, tools and fatigue
Web Development can be pretty strange these days.
On the one hand we tell beginners that they need all the things: build tools, task runners, package managers, frameworks, polyfills, libraries, runtimes and deployment systems.
I also noticed a sense of urgency for everything. Mobile-first, Offline-first, Accessibility-first, Content-first and the list goes on. It starts to feel like “everything-first”, which of course really would mean: Nothing first.
Where are the olden days, where all you needed to build websites was a text editor and some space online to put it?
Plot twist: The web is still like that
Don’t get me wrong: All those aspects are important and all the tools we’ve got these days help achieving our goals towards those — build tools help us check for accessibility issues, libraries help us with making our web app work nicely when the user is offline and frameworks can help us with building apps that work great on mobile and other devices alike.
Yet, while all of this is definitely important, I think we should not gather around beginners and dilute their attention — it is overwhelming that way and there’s a good chance there’s gonna be a single focus and the rest gets forgotten.
And here’s the thing: In the end, all it takes to get something online is still just a text editor and some space on the web.
The right tool at the right time
I noticed something when I was coaching at Rails Girls events, schools and universities alike: Using tools without fully grasping what they’re good for is not helping.
Yes, you can be more productive by using npm or bower, grunt or gulp, angular or react compared to starting from the bare essentials — but different people use different tools for a reason: We’re not all exactly the same when it comes to problem-solving and approaching tasks.
I also think this diversity is good — but I believe that in order to figure out how what’s your personal way of being productive in tackling your tasks you should get a first-hand experience with the problems and challenges and then seek the tool that fits your approach (this seeking may involve asking other people how they do it and what tools they’re using and then evaluating them yourself).
Where people start is entirely up to them: It can be with an IDE, if they’re familiar with the concept,
it can be an editor like Sublime or Atom or even just Notepad.
Starting with a simple text editor will get you going. And when you get lost in the monochrome text forest you can fix that by using syntax highlighting.
Next might be the observation that the website takes too long to load — so you’ll want to minify and compress assets.
But running those tools manually all the time gets annoying, so you find yourself a build tool to simplify and automate that.
This way there’s a gradual improvement in productivity and along with it an understanding for the problems each tool solves.
Of course, that does not mean that everybody should start with just a text editor — that’s exactly the point I’m trying to make here: Start with whatever you feel comfortable using and extend and improve when you notice you’re hitting a bottleneck in your personal productivity or comfort.
But don’t just put random ointments on your skin without having an itch.
In the end, it’s about solving problems
All the tooling that makes our jobs easier every day are there to solve a problem and in turn helping us to focus on solving the problem that we’re actually working on.
Tools serve a purpose, they’re not the purpose themselves. Don’t be offended when somebody uses different tools, they may have a reason. Also always keep an eye open for other tools that you may want to come back once you’re having the problem they solve — but don’t let that ever pressure you.
Fatigue is a reminder to not let the tools we use become the purpose of our work.
Our goal is delivering something of value to our users, not setting up all the tools we find on HackerNews.