Learning without a mentor: how to become an expert programmer on your own

If you’re an intermediate or senior programmer you may hit the point where you feel you’re no longer making progress, where you’re no longer learning. You’re good at what you do, but you don’t know what to learn next, or how: there are too many options, it’s hard to get feedback or even tell you’re making progress.

A mentor can help, if they’re good at teaching… but what do you do if you don’t have a mentor? How do you become a better programmer on your own?

In order to learn without a mentor you need to be able to recognize when you’re learning and when you’re not, and then you need to choose a new topic and learn it.

How to tell if you’re learning

If you’re not getting any feedback from an expert it can be tricky to tell whether you’re actually learning or not. And lacking that knowledge it’s easy to get discouraged and give up.

Luckily, there’s an easy way to tell whether you’re learning or not: learning is uncomfortable. If you’re in your comfort zone, if you’re thinking to yourself “this isn’t so hard, I can just do this” you’re not learning. You’re just going over things you already know; that’s why it feels comfortable.

If you’re irritated and a little confused, if you feel clumsy and everything seems harder than it should be: now you’re learning. That feeling of clumsiness is your brain engaging with new material it doesn’t quite understand. You’re irritated because you can’t rely on existing knowledge. It’s hard because it’s new. If you feel this way don’t stop: push through until you’re feeling comfortable again.

You don’t want to take this too far, of course. Pick a topic that is too far out of your experience and it will be so difficult you will fail to learn anything, and the experience may be so traumatic you won’t want to learn anything.

Choosing something to learn

When choosing something to learn you want something just outside your comfort zone: close enough to your existing knowledge that it won’t overwhelm you, far enough that it’s actually new. You also want to pick something you’ll be able to practice: without practice you’ll never get past the point of discomfort.

Your existing job is a great place to practice new skills because it provides plenty of time to do so, and you’ll also get real-world practice. That suggests picking new skills that are relevant to your job. As an added bonus this may give you the opportunity to get your employer to pay for initial training or materials.

Let’s consider some of the many techniques you can use to learn new skills on the job.

Teaching

If you have colleagues you work with you will occasionally see them do something you think is obviously wrong, or miss something you think is the obviously right thing to do. For example, “obviously you should never do file I/O in a class constructor.”

When this happens the tempting thing to do, especially if you’re in charge, is to just tell them to change to the obviously better solution and move on. But it’s worth resisting that urge, and instead taking the opportunity to turn this into a learning experience, for them and for you.

The interesting thing here is the obviousness: why is something obvious to you, and not to them? When you learn a subject you go through multiple phases:

• Conscious ignorance: you don’t know anything.
• Conscious knowledge: you know how to do the task, but you have to think it through.
• Unconscious knowledge: you just know what to do.

When you have unconscious knowledge you are an expert: you’ve internalized a model so well you apply it automatically. There’s are two problems with being an expert, however:

• It’s hard for you to explain why you’re making particular decisions. Since your internal model is unconscious you can’t clearly articulate why or how you made the decision.
• Your model is rarely going to be the best possible model, and since you’re applying it unconsciously you may have stopped improving it.

Teaching means taking your unconscious model and turning it into an explicit conscious model someone else can understand. And because teaching makes your mental model conscious you also get the opportunity to examine your own assumptions and improve your own understanding, ending up with a better model.

You don’t have to teach only colleagues, of course: you can also write a blog post, or give a talk at a meetup or at a conference. The important thing is to notice the places you have unconscious knowledge and try to make it conscious by explaining it to others.

Switching jobs

While learning is uncomfortable, I personally suffer from a countervailing form of discomfort: I get bored really easily. As soon as I become comfortable with a new task or skill I’m bored, and I hate that.

In 2004 I joined a team writing high performance C++. As soon as I’d gotten just good enough to feel comfortable… I was bored. So I came up with slightly different tasks to work on, tasks that involved slightly different skills. And then I was bored again, so I moved on to a different team in the company, where I learned even more skills.

Switching tasks within your own company, or switching jobs to a new company, is a great way to get out of your comfort zone and learning something new. It’s daunting, of course, because you always end up feeling clumsy and incompetent, but remember: that discomfort means you’re learning. And every time you go through the experience of switching teams or jobs you will become better at dealing with this discomfort.

Learning from experts: skills, not technologies

Another way to learn is to learn from experts that don’t work with you. It’s tempting to try to find experts who will teach you new technologies and tools, but skills are actually far more valuable.

Programming languages and libraries are tools. Once you’re an experienced enough programmer you should be able to just pick them up as needed if they become relevant to your job.

Skills are trickier: testing, refactoring, API design, debugging… skills will help you wherever you work, regardless of technology. But they’re also easier to ignore or miss. There are skills we’d all benefit from that we don’t even know exist.

So read a book or two on programming, but pick a book that will teach you a skill, not a technology. Or try to find the results of experts breaking down their unconscious models into explicit models, for example:

• Gary Bernhardt’s talk “Boundaries” which teaches the concept of Functional Core, Imperative Shell.
• Sandi Metz’s talk “Nothing is Something”, about API design, branching and nulls.
• My attempt, probably not in the same league as the previous two talks, to explain how you should choose to test your software.

Conclusion: learning on your own

You don’t need a mentor to learn. You can become a better software engineer on your own by:

• Recognizing when you’re feeling comfortable and not learning.
• Finding ways to learn, including teaching, switching jobs and learning skills from experts (and I have some more suggestions here).
• Forcing yourself through the discomfort of learning: if you feel incompetent you’re doing the right thing.