[kkoncevicius]

Maybe an unpopular opinion but I think most people who think they have impostor syndrome don't. Instead they accurately estimate the gaps in their knowledge but are working under conditions that allow them to bypass those gaps by using machines / libraries / frameworks and other types of automation.

If you know you will not be able to answer some things when asked about them - then you know you lack a specific piece of knowledge. That is not impostor syndrome.

[closeparen]

I think it depends on where you are relative to the standard. You may be under the mistaken impression that the ability to understand and explain everything from the application to the silicon is baseline for a working software engineer, and because you can’t you’re a pretender. But it doesn’t make sense to think of yourself as an imposter when most everyone you would think of as “real” meets the same criteria.

[juancn]

Impostor syndrome is kind of a corollary of the Dunning–Kruger effect. Since you know a lot about some discipline, you're better able to judge your gaps in knowledge, and you assume others know as much as you (because of a gap in knowledge on what others know, so you extrapolate from your on level of knowledge on that discipline, which is high).

The converse also happen, where you know enough to overestimate your knowledge of the thing.

https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect

[username90]

According to the Dunning-Kruger effect a majority of people overestimates themselves, so if most people thinks they have impostor syndrome then a lot of them are wrong.

[juancn]

No. By definition, if you overestimate yourself, you don't have impostor syndrome in that particular discipline.

[bonoboTP]

Right, what if there are indeed many impostors in the industry? Going by some of the threads on hiring, job applications, promotion criteria etc., there may be quite some people who aren't quite up to the job they are doing, e.g. non-fizzbuzzing programmers, people taking credit for others' work etc.

Ultimately, you have to look at the specifics and some objective criteria. What are your achievements? How does your understanding and skills compare to you peers? Be careful not to get fooled by bullshitters who just pretend to know by using lots of fancy buzzwords in random sequence. You can only tell this through deeper technical conversations.

There's a lot of feel-good answers out there that boil down to "oh, nobody has any idea what they are doing anyway, everyone is just winging it" etc. This is not true. Through conscious effort you can master and build strong mental models of technical systems and processes. It's entirely possible to feel confident in one's expert knowledge of a field after many years of experience. It doesn't mean you feel invincible, and much of this kind of knowledge is indeed about your own gaps of knowledge but also knowledge of pitfalls and illusions of easy answers and knowing when you're entering unexplored but enticing territory that feels simple to beginners, but you expect it to be extremely complex as an expert, etc.

Keep on learning and studying. If you feel embarrassed that you don't understand a particular thing and this bothers you, take some time and dive into it. In my experience there is no better cure than to realize that everything in tech can be understood. It's all logical from the highest part of the stack down to the lowest electronics level. Once you gain enough experience and have a rough mental map of this whole territory, you will know that there's a lot of details you could learn if needed, but not everything is worth knowing for your own case. Apply an engineering approach to this as well. You have a limited lifetime and no single person can know everything. That's the constraint. Now pick out the actually important parts and discard those that aren't necessary for your development. And feel comfortable that you will pick up whatever is needed along the way.

It's a similar case with general personal confidence. There are people who exude this level of confidence which in effect says "Whatever happens to me, I will take care of it. If I'm dropped into a foreign land tomorrow, I know I will rebuild my life. If my house burns down, I'll recover. If I'm thrown into prison, I'll figure out how things work there and will adapt. I don't know what will happen tomorrow, but I'm prepared."

In tech, you can also not know exactly what you will have to learn in the coming years, it will never be like I've now learned everything, from now on I'll just apply it. The best you can do is have a good overall mental overview of the kinds of things that exist and be able to zoom in on any of it when needed.

[_y5hn]

These arguments run counter to practical considerations: Most programmers will inherit larger and larger codebases. So the skill and dedication for a professional steady job is reading the code well, and use that to over time learn the domain well. This may take years, or never be complete if focus is all over the place.

But what matters is also are you providing value? Increasingly value is more in inter-personal, teamwork and collaboration, rather than conjuring up magic codes nobody else can relate to.

There are simply no objective metrics. Software development is not bridge building or an engineering practice. Evidence is how everything is in flux and nothing is ever truly settled. At the same time any old code can be extremely low cost, valuable and maintainable, regardless of the code itself!

[bonoboTP]

I largely agree.

> Increasingly value is more in inter-personal, teamwork and collaboration, rather than conjuring up magic codes nobody else can relate to.

The problem is, this is exactly the area where bullshitters can do well. I do think that office politics and social strategy is the most lucrative one (e.g. winning allies, getting credit and recognition and visibility, generally buzzing and being in the center of attention), but I don't think it connects much to impostor issues. You may be winning at the social game while still feeling like an impostor.