You don't need to know everything (but you should know something well)

Dan Abramov recently published a couple of posts that made me think considerably. I regard these two posts as precious gifts. Let me tell you why.

In the first one, Things I Don’t Know as of 2018, he lists technologies and topics he knows little about or none at all. I’m not going to list them here because it would be beside the point.

Many developers struggle with the mythical manifestation of the omniscient programmer, those who inhale all the cool technologies (present, past and future). This myth probably arises from a combination of fluctuations in self esteem, peer pressure, unrealistic expectations, buzz wording as a sport, boisterous “ninjas” of software, aggrandized job ads and more. Going down that path either results in burn out or a progressive disappearing of one’s social life.

So, as a breath of fresh air, I’m going to warmly suggest you go and read that first post. A couple of quotes:

We can admit our knowledge gaps, may or may not feel like impostors, and still have deeply valuable expertise that takes years of hard work to develop

This reminds me of the attitude of many devtoers that I follow with pleasure. Being knowledgeable or an expert in something and having no qualms at admitting where the end of that knowledge lies is a real quality. As a human in general.

I’m aware of my knowledge gaps (at least, some of them). I can fill them in later if I become curious or if I need them for a project. This doesn’t devalue my knowledge and experience. There’s plenty of things that I can do well. For example, learning technologies when I need them.

This is the gist. Curiosity driven development (or “necessity driven development”) are one of those traits that many successful developers have. Learning how to learn is even more important.

In the second post, The Elements of UI Engineering, Abramov talks about what he does know well, but with a twist that makes the article the real gift it is.

If the first list is about tools and stacks, this one is about metholodogy, patterns and the important things in UI development.

Abramov emphasises one aspect (and here we can draw breath the second time):

My biggest learning breakthroughs weren’t about a particular technology. Rather, I learned the most when I struggled to solve a particular UI problem. Sometimes, I would later discover libraries or patterns that helped me. In other cases, I’d come up with my own solutions (both good and bad ones).

It’s this combination of understanding the problems, experimenting with the solutions, and applying different strategies that led to the most rewarding learning experiences in my life. This post focuses on just the problems.

Another thing that comes up often in discussions on dev.to is the value of fundamentals and problem solving versus this or that tool.

As the title: you don’t need to know everything, but you should learn something well.

I have a feeling that these two posts are going to pop up in 2019 again and again as reading suggestions for developers of all skill levels.