Exposing My Ignorance
In Apprenticeship Patterns, Dave Hoover and Adewale Oshineye introduce a technique called "exposing your ignorance":
"Show the people who are depending on you that the learning process is part of delivering software. Let them see you grow." –Apprenticeship Patterns, pg. 26
I'm going to do that today, and explain why.
I've been writing software professionally for a decade, and I feel confident that I'm an expert at what I do. And yet, there are areas of my domain that I don't know a lot about. Here are three:
API Design. These days I write frontend JavaScript, and my API design skills are on ice. I honed them in Ruby on Rails, which champions particularly strong conventions. I'm passingly familiar with recent advancements in this domain, and barely involved in API design decisions on my team.
Enterprise Scale. I've only worked on small teams, so I don't have experience at a grand scale. I live in a world where performance and infrastructure decisions are easy to think about and change.
Frontend Frameworks. Almost every project I've worked on has been built from the ground up, crafting artisanal code to solve the unique problem at hand. I don't have a go-to frontend framework (I don't count React as one), or strong opinions about them.
I feel these shortcomings sometimes in casual conversations. I'm up front about them, and when asked, offer the best general advice I can.
Okay, so I've shared a list of my technical weaknesses. Why would I do that? Doesn't it reduce my value as a worker?
Within reason, I think that the opposite is true. As Dave and Adewale point out, software is a learning process. We aren't paid to have every answer immediately; we're paid to be experts at finding the answers, understanding the tradeoffs, and articulating them.
Occasionally, a colleague will see some of my recent work and say something like: "It's so cool you solved that; when did you learn so much about email?" The answer is often a magic trick: I learned it in order to build that feature. I don't need to memorize every esoteric email specification to do damage. I just need to figure out which one matters, learn it, and use it. And cement it so it's a thing that I "know."
When you're new, your list of gaps will be long. If someone asks about one of them, be honest and confidently commit to learning about it. Try to learn something valuable every day, and you'll soon have a knowledge portfolio that can take you far. For me, I'm confident that I'll improve my gaps on-the-job, if and when they become more relevant.