On Ignorance

So I’ve been thinking lately what makes a good developer. There are tons of articles about it, and I’m sure most of them under striking titles like “x things you must/should learn as a developer”, “x traits only top notch developers have”, “the x things to do so you don’t become a pathetic little weasel (as a developer)" and whatnot.

I don’t love those kind of articles. Mainly because all of them contain more or less the same information in different order and style.

I’m certain I’m not the first one to propose the following idea as something that improves your thinking, but I wanted to write about anyway so I think through it a little bit more.

Metacognition

I firmly believe that the most important traits of a developer (in general, any person) goes well beyond technical capabilities and knowledge, and lies in more abstract and hard-to-measure things. In this case, metacognition or metathinking —thinking about thinking.

I’m not aware if there are well backed theories on what is the structure of the knowledge inside our brains, but I think most of use have the ability to consciously add a layer over it so we can organize our pieces of knowledge in something like a mind or concept map. I’ll refer to this later.

One of the tools that you may use to improve your metacognition is the “known unknowns” framework. It’s similar to the Johari Window , but it doesn’t take into account what other people know. It’s just about what you know, and what you know about the things you know.

Known unknowns

Imagine that knowledge is contained in atomic pieces. And you can either know them, or not. And you can be aware of them, or not.

Knowing it means you’re informed about its contents. You’ve assimilated it. You own it.

Being aware of it means you know that it exists, and even that you know how it would fit in the broader scheme. You’ve seen it.

According to the known unknowns framework, there are four categories in which a piece of knowledge can fit into:

Now, I’m gonna describe what I believe is a sensibly accurate abstraction of the learning proccess of something you’re unfamiliar with.

Learning the unfamiliar

First you give an bird’s-eye view of the topic. You start to be aware of some core concepts and their connections. You may not know anything about them, but you’re aware of them. These pieces are represented in gray, and are your known unknowns.

alt

Then you start exploring, and after some research, practice, time, and sleep, you start to learn some of those pieces —represented in black.

You’re converting known unknowns into known knowns.

alt

You may even start extending your awareness network, and find new links between pieces (there are more gray circles now).

And even if you don’t know it, you may start to make connections you’re unaware of. It may be because of a structural resemblance to completely different topics, previous experience, or implicit hints you picked up.

You’re building intuition. These are your unknown knowns.

alt

But even with that knowledge, you’re still ignorant. Not because you don’t know some of the pieces. But because you’re not even aware of them. You still have unknown unknowns.

alt

They may be unimportant pieces that getting to learn may not even worth the effort. But they also may be important pieces that are fundamental to building a more robust network.

Growing your awareness

I believe that moving those unknown unknowns into your known unknowns is a responsible objective to pursue. It can help you to discover the hidden roadmap behind the fog.

The only question is how to do it, and I can only think of two ways:

  1. Diversifying your interests.

    I think that the structural resemblance of different topics can make you develop the intuition that can help you realize you’re missing pieces.

    You may be learning economics and realize that there is some resemblance to the cycle of water, for example.

  2. Giving a bird’s-eye view every once in a while.

    The more knowledge you acquire, the easier it could be to find unpolished links, or gaps.

Conclusion

But now, of course, reality is not that simple.

You can’t just pinpoint and say —yeah, that’s one piece of knowledge. And that’s another right there!—.

Knowledge it’s not self-contained. It has many dimensions. Even a single “piece” contains networks of smaller pieces. Links between pieces go beyond what you can imagine, and a true learning roadmap may not be as organized as a concept map.

Finally, getting back to the original idea, I think this may help you both as a solo developer and as a team member.

As a solo developer, you could improve your ability to think with different perspectives, broadening your “toolkit”.

Knowing that there’s a thing called memoization that caches return values may help you write more a more efficient function one day (or never, but let’s stick with the possibility of that one day), even if you don’t know the specifics of it. You can go back and research it when needed.

And as a team member, you can strive to make a smoother flow of work between teams. You don’t need to know what your pals on other teams do, but if you are aware of their tasks, (and you’re kind enough) you’ll make an effort to fit your work to ease theirs.

It’d be like striving to specify an interface between developers.

At the end, what I want to force myself to do, is not just accept and embrace ignorance, but make an effort to fight it at least by increasing the size of my awareness network. Getting to know my unknown unknowns.