Wilful educated ignorance
This morning I found an old unpublished draft post lying around from about six months ago. I didn’t publish it because there are quite a few posts about technical front-end knowledge overload out there.
But as someone once told me: ‘Ah, just f***ing publish them. Nobody really reads anything anymore anyway.’ Ironically, this is apposite to the sentiment of the article below.
Let me know if you enjoyed it so I can get some more confidence to repurpose old rants :-)
(Warning, it’s nearly 1000 words - so this is probably a weekend read.)
All the best,
A tweet this morning got me thinking. Paraphrased: one of the most important skills to learn as a knowledge worker is the aggressive and continued ignorance of almost everything. [Later me: I have not tried to find this tweet].
Now naturally I immediately started to think how this applies to front-end development, and to what extent I practice it myself. Because I agree with the sentiment.
Allowing yourself to get swept up in the torrent of information, opinion, hot takes, latest frameworks, approaches, and industry gossip will eventually lead to something bad. Whether it’s feelings of inadequacy, stress, cognitive overload, or hopelessness.
Occasionally, the sentiment of not being too hard on yourself and not trying to keep up with everything crops up online. But there continues to be phases of my own professional life where these feelings will resurface. After 20 years, you would think I would be confident enough or familiar enough with this to handle it well.
Now, I’m not about to argue for ditching your outward-looking eye. Keeping in touch with the direction of the overall industry and professional communities that you belong to is important. And I’m not suggesting you take Homer Simpson’s advice to ‘never try’.
However, Homer’s general attitude to life in some ways is admirable. To quote:
The key to parenting is don’t over-think it. Because over-thinking leads to … what were talking about?
Now that’s a sentiment I can get behind, and over-thinking things is really what I want to focus on here.
Say you have decided to write a detailed article on how to test complex co-ordinated asynchronous API requests using LatestAmazingFramework.js. A good article about this will present all the options and conclude with a best-practice approach that will work in a variety of circumstances. To do this you’re going to have to do lots of wide research, test out your approaches and get your reasoning down in a form that others can follow along with. In other words, you’ll need to deliberately over-think the problem.
If you were instead implementing something like this on a project, you might find yourself doing less research, because you want to solve the one specific problem you have in front of you. Premature abstraction is generally a bad idea, and your single implementation doesn’t need to become a generalised library or approach just yet.
If an article like this cropped up on your radar as a Developer Who Keeps Up to Date With The Industry, you might be tempted to think: “that looks like it would be pretty useful.” Or: “I’ve had that problem before and I had a lot of questions about it.” What do you do at that point? Read the whole article in-depth immediately? Skim read it immediately? Save it for later in your giant reading list which only ever gets longer not smaller?
Here’s what I usually do: I ignore it.
But I might mentally file away the knowledge that such an article exists somewhere out there. I don’t bookmark it, or mark it ‘to read’. The only circumstance I will do that is if I’m potentially interested in including it in my monthly link newsletter.
And yet I subscribe to a lot of newsletters, feeds and other sources. Most of that stuff gets ignored too. My filter is extremely strict.
Years ago, I tried to read as much as I could around the whole front end development landscape. It was too much to read about in 2000, and it’s certainly far too much to keep up with now. This isn’t just restricted to technical articles, I have the same attitude about new frameworks, libraries, big splash opinion pieces and industry news.
I’m able to be wilfully ignorant like this partly because of my privilege, and partly because of the background of 20 years experience and expertise I’ve built up. I now have the confidence and filtering skills to ignore almost everything. It’s enough for me to know that something exists. When I need to, I can then start to dig in to particular topics.
But more often, the need never actually arises.
Take Progressive Web Apps as an example. In the distant past, I implemented some offline capabilities with the old appcache approach, and I’ve done a little tinkering with manifests, but my PWA skills don’t extent beyond that. And yet I know that PWA is a just a term for a specific way of bringing together a handful of Web Platform technologies. I wouldn’t go out of my way to ‘learn PWAs’ until I have a need to do so.
In my consulting work, the same applies. Once I realised that I add value not through all the in-depth technical knowledge I can apply, but through the ability to consolidate decision-making expertise into targeted advice, I stopped comparing my technical knowledge to others’.
Key to this is being honest about what you don’t know. I led a team of front-end developers through an Angular 1.x build, but didn’t learn that much about Angular myself along the way, beyond knowing its scope, its high-level approach and patterns, and the kind of skills the team would need to learn and build stuff with it.
After two years of that project, I would be no better as an Angular developer than someone who had completed the introductory tutorial 2 years previously.
The point here is that just-in-time learning is extremely powerful, efficient and far better for your mental health and self-esteem than the pre-emptive guesswork involved in ‘keeping up to date’.