I recently read the book Apprenticeship Patterns which advises programmers how to overcome the challenges that come with being and remaining self-taught and become better at what we do.
Apprenticeship Patterns does not tell you how to write better code. What it does, is presents roadblocks you would encounter during your career with solutions to help you overcome them. An apprentice is someone that seeks to learn and get better at their craft. It is more of a mindset than a formal title you might acquire. The main lesson the book teaches is that in order to become a better programmer, we have to take our career and learning into our own hands. I will review a few of the patterns from the book that I use and believe will benefit anyone who wants to further their career.
Draw your own map
“None of the career paths that your employer provides is a fit for you.”
I used to think that I needed my employer, or someone whom I perceived to be more knowledgeable than me, to guide my career. All the advice about finding a mentor reinforced this belief that my life could not move forward until someone else intervened. I have long since realized this is not true, nor do I want someone else to decide my future for me. "It is your life, and you are responsible for moving it forward," I tell myself. "Do you really want to leave it in the hands of someone else?"
I have made a map of my life, except I call it my grand design. It is my grand design because it takes into account my entire life, not just my career. I do not treat the work I do as being separate from the rest of me. I have tried before to disassociate myself from my work. However, it is very difficult to maintain multiple personalities, and I do not recommend it. Being a programmer is very much a part of my identity as it is a part of my lifestyle.
Your first language
You are familiar with a few languages but lack fluency in any of them.
To solidify what I have learned, I record what I learn. It can be in a text editor or a journal. When you learn something, especially something very tough, you should record it so that you do not have to relearn it. There has been more than one occasion when I have needed to do something at work that I did before, like unit testing Angular components. It is easier to write it down than to look it up each time. Save looking things up for syntax.
Additionally, recording what you learn reinforces what you have learned. It is like teaching an invisible student. Explaining your thoughts on paper or verbally helps to make sense of them. And if you share your thoughts publicly, you can hopefully open up a Socratic dialog that will further deepen your understanding.
Create feedback loops
You can’t tell if you’re suffering from "unconscious incompetence."
Feedback is essential to confirm if you know what it is you are supposed to know. As a self taught programmer, I struggled with knowing if I had any skills worth paying for. I am not talking about imposter syndrome. Many people are posing as software engineers, and they should feel ashamed about it. No, I am talking about having some criteria to judge my competence. Well guess what? Such a set of criteria does not exist. Just because you were hired, it does not mean you are qualified for the job. Just because you get promoted, that does not mean you have improved your skills. My consolation is to compare myself to other engineers I admire and hope they are a good role model.
Some things you can do at work to get feedback is to ask for a code review. Ideally, you would want this for everything you write. Next, you can pair program with someone more senior than you. Working with someone through a problem will allow you learn some of their tricks and techniques you would otherwise not get from just a conversation. Another option is to schedule one-on-ones with your manager to get feedback.
Expose Your Ignorance
You have discovered wide gaps in your knowledge and are afraid that people will think that you don’t know what you’re doing.
Saying “I don’t know” seems to be the hardest thing to do. Granted, we do no’t want to expose that we are unqualified for the job and find ourselves fired. So the alternative is to pretend like you do know and stare at the computer screen until the solution jumps at you. This is very dangerous. Usually, there is someone depending on you to produce something for them by a certain date.
As programmers, we do not have to know everything. We just need to be able to figure it out. If you need to ask questions to understand the problem, do it. If you need help to complete your work, ask for it. By exposing your ignorance you create a learning opportunity. It is far worse not meeting a deadline than saying “I don’t know”. And if learning on the job, asking questions, or collaborating with your coworkers is frowned upon, then you have a bigger problem to deal with.
For those of us who desire greatness, you can use these patterns to design your own apprenticeship. The main criterion is having a passion for learning and seeking out opportunities to do so. That leaves me with the final pattern: the long road. It takes time to master our craft. There are plenty of bootcamps that will promise you can become a senior engineer after three months of study. Or some tutorial that says you can learn to program in 30 days. However, if your goal is to become a better programmer and not to just get a job, you will not be enticed by such claims. Let your map guide your decisions. That will be far more rewarding than any paycheck.