Could you restate what was "false"? Are you referring to the article or my comment?
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.
> 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...
Um. I'm an expert on PG internals. And I get impostor syndrome on stuff related to PG internals.
But you don't get impostor syndrome on PG internals itself do you?
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".
> But you don't get impostor syndrome on PG internals itself do you?
I do.
> 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.
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.