A lot of the discussion here is treating impostor syndrome and qualifications as binary: You're either qualified or not. And your evaluation of your skills is either above your actual skills or not. But it's more nuanced than that. I'm a Principal Engineer at a FAAMNG company. I have impostor syndrome all the time. Why? Because I measure myself against 1) role models that are ahead of me in many ways - I've always do…
A lot of this resonates with me, and in particular: > but I don't consider them difficult (how could they be, if I am good at them) I've struggled with this over the years. As a kid, once something clicked it felt like you had leveled up in some way, and now had a new skill. As an adult, I have a hard time not looking at everything I'm capable of and thinking "it's so simple, it obviously just works like this ". It's…
The way you fix this perception is teach the skill to someone with zero foundational knowledge of the skill’s background requirements. Or write if there is no person around. There is always documentation going begging.
IMHO, one of the biggest oversights I see in the industry today is the lack of inward-facing technical writer and editor teams, sitting alongside pair programmers and/or agile stand ups. Skills transmission works through a highly opaque diffusion membrane of tribal knowledge (reaching its peak form in StackExchange), and synchronous, people-intensive discussions, where insight is rarely if ever captured and memorialized.
Powerful, effective documentation prepared by professional programmers with professional communications skills asynchronously transmits insight and not just information. We have incredible tooling now, but ironically do not staff them.
One way to calibrate your imposter syndrome is write lots of documentation. In it, make sure you call out references for further to skill stacks you consider prerequisites lest you dilute your focus and the the prose becomes too unwieldy. And call out references to what you have used to learn meta information and abstractions beyond the current documentation’s focused skill band. If that list will routinely take an average practitioner at a particular skill level more than a year to absorb, then you have a fair baseline. Now update the documentation each time someone asks for clarification on a point in it. If there are lots of readers and few questions, then you possibly have a reasonable grasp of the material.