Imposter syndrome is fueled by colleague deification.

It's easy to view smart coworkers as superpeople... until you're reminded that they, on occasion, make dumb human mistakes too.

This is a fantastic insight.

I used to suffer from imposter syndrome significantly. It helped to see the mistakes others made which anyone could have made. It also helped to have my own good ideas and talent explicitly acknowledged. Learning to not take criticism personally and own your own mistakes also helps to rob imposter syndrome of its power because it demonstrates to others that you can be forthright and self aware, and that helps build trust.

I’ve found one of the best things I can do to help my jr devs feel more confident (and be willing to ask for help) is highlight my screwups and “basic” things I’ve just learned. It make me seem more approachable and less like everything I say is a pronouncement from on high, it makes them more willing to admit to their own mistakes, it clarifies that we’re all learning stuff all the time and it helps spread knowledge about things that folks might otherwise be too afraid to ask about for fear of looking silly.

A benefit of being a sr dev is getting the benefit of the doubt on mistakes, so I might as well use that to my advantage and let everyone learn from them, not just me.

I 100% agree with you, and have used the same technique. Showing juniors that you are also human and make mistakes allows them to be less anxious about learning and trying new things. It also helps to keep them from trying to hide their mistakes which can quickly lead to larger system issues.

Of course, you have to have a culture where making a mistake doesn't immediately lead to being let go or publicly reprimanded. I have definitely learned quite a few things about people and code by helping juniors work through bugs that may not have been so obvious (including occasionally finding bugs in 3rd party libraries).

Pitching in to your and parent comment but from the junior side to say that yes, this definitely helps :)

I find that I have to argue a lot for making systems where humans are allowed to be human and not burn the house down.

Operationally, people gravitate toward trying to treat the humans as machines.

We have machines for that.

I don’t think there was any dig implied. And I will second that it will add to self esteem. Specially during discussions if you have more understanding about the code you will have both better contribution and take away

Sure, when you succeed in understanding someone else's legacy codebase, it builds self esteem. When you fail attempting to do that, it does the opposite.

I have inherited projects where I just could never understand what they were thinking well enough to make the service good (not running out of memory and crashing). It was very humbling; I still sometimes wake up in the middle of the night with things I wish I'd tried, but the assumptions of how it all worked was just scattered throughout a bunch of files and the assumptions of everything was just not how I'd do it.

Sure, but if there's anything I've learned from working on legacy software, it's that I don't know why the code was written the way it was. I'm not the only smart person to work on a codebase, and it's more common that another smart person did what they did for a reason, than that I'm a genius who knows better than they did.

Sometimes there were reasons, but they were not necessarily good ones. Like these:

- time pressure, leading to just making it work and not caring about edge cases, which were bolted on later. Or maybe never at all. And naturally, there is no useful testsuite.

- the prototype ended up in production

- a refactoring happened, but there was no follow-up into other areas of the code base

- features changed, but the code is still influenced by the necessities of the old way it worked. Similarly, for changing technical circumstances

- code was copy-pasted or was worked on by too many people

- code was herded too long by the same person and now, to put it nicely, bears traces of their bespoke coding style

Chesterton's Fence is still very relevant, therefore I'd still err on the side of writing a lot of high-level tests before touching anything.

And not to forget: business realities change over time, but it is not always the code follow.

All of these, I have been guilty of. Fairly recently, too.

Such a rare opinion on HN unfortunately. But you're correct.

Kind of light fighting against the human tendency [0] to blame the failings of others on their core character rather than the situations they are in, and vice-versa for oneself.

[0] https://en.wikipedia.org/wiki/Fundamental_attribution_error

Also why I used to like interviewing.