Hey folks, welcome to The Imposters Club, the podcast for misfits in tech. You know who you are? Who am I? I'm your host, Teddy Kim. I'm a director of software engineering at a SaaS startup, here in Minneapolis. And today let's talk about the four stages of competence. Noel Burch developed this model in the 70s and it has endured as a really useful way to think about the learning process. In essence, the four stages of competence describe your path from novice to expert. In stage one, you are an unconscious incompetent, which means you don't know what you don't know. You certainly don't possess a skill, nor are you aware that you even need it. After a little exposure to the problem domain, you become a conscious incompetent. You realize that you don't possess a given skill, and you're aware that you need it. So for at least your first two years in the industry, you are a conscious incompetent. After a long process of trial and error, you become a conscious competent.
At this point, you possess the skill, but the execution requires concentration and conscious involvement. Eventually, you become an unconscious competent. At this point, conscious involvement is no longer necessary because the skill has become second nature. Unconscious competence relies on intuition rather than conscious attention. Being an unconscious competent sound pretty awesome. But it can actually cause problems within a team. You've probably worked with a grumpy senior developer every time you go to him for help. They'll say something completely unhelpful. Like, "connect the thing to the other thing over there, and don't forget to test the piece that does the stuff..." Dude so unhelpful. This is one of the great ironies of professional life, the better you get at doing something, the worse you become at explaining it.
Well, why would that be? Well, in an earlier podcast, we talked about the latticework of mental models. That's the idea that you should accumulate and interconnect knowledge across multiple problem domains. When that happens, you can rely on intuition which by its nature is difficult to explain. How can you explain a hunch? It's a hunch.
So a word of advice. If you are an early career dev seeking a mentor seek out the conscious competent's. They are most likely to be able to explain things to your level because they're still doing the work consciously. In all likelihood, that's going to be a colleague who's been in the game for somewhere between three and five years, but regardless of vintage, you will always know a conscious competent, because he or she will be able to explain things in a way that actually makes sense.
Now, for some reason, managers usually get the mentoring thing wrong. The reflex is to pair the most senior member of the team with the most junior member. And then you end up with an arrangement like Mr. Miyagi and Daniel, you remember from that movie, The Karate Kid, wax on, wax off, wax on, wax off. No, not like that, like this wax on, wax off. Meanwhile, Daniel is like "this is so not what I signed up for. I just wanted to learn karate, and this guy has me sending decks and buffing cars." And that right there is pretty much the entire conversation around test-driven development. Wax on, wax off.
Why am I doing this? Why would I write the tests before I write the code? Wax on, wax off... Yeah, somehow I thought being a coder would be different than this. Wax on, wax off. Stop saying that! Eplain better! Yeah, when managers pair the new kid with the unconscious competent, neither party benefits from the arrangement. And that begs the question, should an unconscious competent really pair with anyone? Yes, but it's more for her benefit than yours. The natural drift of genius is isolation. and isolation is the opposite of teamwork. On most teams, the unconscious competent's tends to become isolated. I'm sure you've observed this in your own teams.
Because the unconscious competent usually is held to high expectations, their responsibilities mount which makes them even busier, more unapproachable, and more irritable. Pretty soon that person becomes a bottleneck and everyone else on the team is standing around watching this person do all the work. And about then the manager has a bright idea. If only the unconscious competent could train the junior devs to be half as awesome as she is, then we would be crushing all the goals. Except she can't remember the reason she's so awesome is because she doesn't have to think to do the work. Because she's not conscious of how she's doing stuff. she can't explain it, especially to a noob. Much better to pair her with another senior dev that way she won't become isolated, and she can load balance with someone more at her level.
And therein lies one of the most powerful takeaways from the four-stage model of competency. If you are looking to learn, then pair up with someone in the adjacent stage, don't skip a level. For early-career devs, you are conscious and incompetent. You should pair with a conscious competent who can explain things in a logical and linear way. So look for someone with three to five years of experience. If you already are a conscious competent, then it's time for you to level up. Pair up with an unconscious competent and do your best to keep up. You might be confused by the mental leaps and cryptic incantations or wax on wax off, write test, run test. But that's okay, you're being taken along for a ride by a legit wizard. Just sit back and allow yourself to be seduced by the Dark Arts.
I'm hiring software engineers! Check out the jobs page to see my open positions.