> 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".
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.
It's interesting you say this, because I have probably written more documentation in the last two years than I did the first eight years that had made up my career prior to that. The team I'm with now, we've been building it with a focus on documentation (and testing) that I didn't appreciate was possible prior.
We've also been pushing hard to get a full time technical writer, someone who specifically doesn't get screwed three months into the job with "Ok, you write docs, AND do a little coding work on the side in your down time". No, we've clearly got the workload necessary for a full time writer, let's bring someone on board and really let them become that core differentiator.
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.