tl;dr - Stop claiming to be an expert at things you haven't delved into deeply. Conversely, if you've delved into a subject deeply, there's a high chance you won't feel like an impostor. If you don't have time (or resources) to delve into something deeply, and understand thoroughly, accept that fact and move on.
Impostor syndrome hits experts, often when they are at their peak, while beginners rarely experience it, hence the name "syndrome".
I didn't mean to state that being aware of your need to learn and improve isn't normal or healthy -- but you can't learn about everything. You literally don't have the time to learn (and practice, and implement in production) everything as deeply and thoroughly to make you a tried and true expert. You have to cut and run at some point, if you want to get anything done. If you know anyone that constantly keeps every single piece of the actual "stack" (and I don't mean AWS + your apps, I mean down to the assembly at the very least) in their head, please direct me to them so I can learn how they do it.
I don't think widely considered experts experience the impostor syndrome in the same way that I see it explained. Experts on postgres internals don't wonder if they're experts on postgres internals... Maybe they worry if they're good application developers, but that's a different thing.
Um. I'm an expert on PG internals. And I get impostor syndrome on stuff related to PG internals.
If you do, could you expand on the parts of PG internals that you know the best (I assume that's what you've written/hacked on the most), and the parts that you feel you don't know enough to be an authorative source on?
A sub-point of my post was that maybe people should avoid statements like "I'm an expert at X" for a sufficiently complicated X. Maybe just say "I have a lot of experience using X's feature Y, and dealing with Z when it occurs".
> If you do, could you expand on the parts of PG internals that you know the best (I assume that's what you've written/hacked on the most), and the parts that you feel you don't know enough to be an authorative source on?
I've hacked, and in some of the cases authored, on many parts of postgres (I'm a committer in the project), including physical and logical replication, durability, locking, executor, JIT compilation, good chunks of the planner, ... There's a few parts of postgres that I don't know as well (SSI, some of the PLs, gin/gist/spgist), but even there I know a good bit.
But that doesn't really matter. Even on code that I personally wrote and committed I get impostor syndrome like feelings. I've learned mechanisms to cope and continue regardless. But I consciously have to do it.
I don't think you should disregard the fact that other people get impostor syndrome quite so blithely.
To some coworkers I'm a programming expert. To a 30-year veteran sysadmin I'm a novice.
The same goes for any skill or knowledge - musicianship, cooking etc. Only one person in the world is the best at something, and it's not reasonable to compare yourself to that person when there's billions of us.
> To some coworkers I'm a programming expert. To a 30-year veteran sysadmin I'm a novice.
I agree with this -- but it was less about how others see you and how you see yourself. My point was that rather than claiming to be a programming expert, if you just get more specific about what you know, and keep good track of what you've learned/deep dove into at least once, and don't over-sell yourself, it is unlikely to feel like an impostor.
Regardless of your actual level of expertise, if you've literally taken the time to follow an interrupt through the kernel, or read the SMTP spec, you have those pieces of knowledge (though they may be rusty).
> The same goes for any skill or knowledge - musicianship, cooking etc. Only one person in the world is the best at something, and it's not reasonable to compare yourself to that person when there's billions of us.
This is kind of a weird claim and seems to contradict the first thing you said. Most non-trivial skills can't be boiled down to one person just being the undisputed "best" -- for the world to work that way, expertise would have to be some absolute-ish thing.
If I had to try and sum up your thesis:
Expertise is very much about perspective. An amateur may look like a superhero to one group, but a novice to another group.
If I had to sum up mine:
Expertise is how much of a finite space of known things you currently know.
The two theses seem orthogonal, I don't think we actually disagree.
You basically say "don't say you're good at something unless you really are", but have no threshold for this. This quote from your article highlights this:
> If you don’t want to be a fraud, or feel like one, do the hard work of learning(...)
There's no upper bound on the level of knowledge required here. Am I "good" with Python because I can understand basic syntax and scoping rules? Do I need to know all of the standard library by heart? Python 2 and 3?
Impostor syndrome isn't when you are a fraud, it's when you think you are but really aren't.
To go with this, an intended (but maybe not properly conveyed) second point of the post was to stop saying "I'm an expert at X" and start saying "I'm familiar with X and have used it to do Y, and deal with Z -- spending a long time debugging problem A when it came up".
The only way you can "know" a piece of code is by reading it, I would consider that table stakes, so for me "knowing" python means reading the interpreter code. But, I think it doesn't stop there because you could consider "expert"-level pythonistas to also include a working model of the system underlying to write super efficient python code.
The point was that rather than claiming you're "good" with python, get more specific about what you know about it, and it should be relatively easy to note what you do and don't know, and cut down on the feeling that there's a world you don't know (which there almost always is).
> Want to solve your impostor syndrome? Repeat after me (preferably in a tech interview): “While I wouldn’t consider myself an expert on A, I have read about A and done X, Y, and Z with it so I’m confident I can solve problems with it and debug it when things go wrong.”
This line makes me cringe (and I wrote it), but the point I was trying to make is that we should stop boiling down language familiarity to terms like "good" and "expert", it's subjective, and depends on the application a lot of the time, just be able to recount the bits of knowledge you've gained with experience that you're sure about.