Stages of competence: 2 ways of learning

The classic way to master something is the following:

That is, we start in the first quadrant without any knowledge of a particular field. Often, the degree of the knowledge we possess in the beginning isn’t enough to even realize we are incompetent. This stage is called unconscious incompetence.

I noticed this type of thinking in myself in the past. Entering some unfamiliar area often was accompanied with a false sense of knowledge. Well, I know I didn’t use this language before but give me a week and I will complete this project. After a time, I realized there is much more to learn than I initially thought.

This realization helps enter the second stage: conscious incompetence. At this stage, we are aware of our lack of knowledge, so we actively seek to fill the gaps.

Eventually, we fill enough gaps in our knowledge to become competent in what we are doing. That brings us to the third stage: conscious competence. If we continue to practice over and over again, eventually, we start applying the acquired experience mechanically, without even thinking of it. We become unconsciously competent.

This is the classic (and most common) way of getting expertise.

It’s interesting that if you don’t communicate your decisions to others often enough, you tend to forget the reasoning behind them. For example, you might have modeled relational databases so many times that you forget about the types of normalization and just apply proper techniques right away, without ever considering the options.

Similarly, you may apply the OO patterns in your code even after you forgot what their names and descriptions were in the GoF book you read several years ago.

Aside from the classic learning path, there is an alternative way. You can move from the "Unconsciously incompetent" stage to the "Unconsciously competent" one directly:

That might seem too good to be true, but it can actually happen if you have someone to learn from directly, and this person themselves is unconsciously competent.

In this case, you just watch how your mentor does their job and mimic the way they do it. At some point, you start applying the best practices yourself. You move from the first stage to the fourth one without ever being conscious about it.

If when reading a book, you find yourself thinking "Wow, it turns out this thing I apply in my code all the time has a name", that’s it. That means at some point, you learned how to do "this thing" yourself or watched someone else doing it without traversing the second and the third stages.

The "Unconscious competence" stage is good for doing the actual work because it eliminates unnecessary "roundtrips" between the conscious and unconscious you. However, unless you never work with teams, you should always strive to move to the conscious competence stage.

It doesn’t matter how exactly you’ve got to the mastery stage, you should be able to clearly communicate your decisions to other programmers. A software developer - even a great one - will rarely get credit for a design decision if he or she can’t explain why exactly this decision was made.

Books and articles help with that. Even though reading them may not teach anything new, in most cases, they lift the level of consciousness for the knowledge we already possess. This, in turn, allows us to better express the "gut feeling" with which we write code.

At the beginning of my career, I often followed the alternative way of learning. It wasn’t a choice but rather due to the ignorance with which I approached the learning itself.

Nowadays, I prefer the classic path. In my experience, it turned out to be the best option to keep myself in the "Conscious competence" stage. It’s easier to move to consciousness if you’ve been there at least once, even if you already forgot everything you read on the subject.

Another shortcoming of the alternative way is that it’s hard to implement without a really good mentor you can learn from, so in most cases the classic path is the only option we have.