Avoiding creating imposter syndrome
Imposter syndrome is a common occurrence in the world of programming. It’s not something that I have suffered from with relation to programming in a while, but I have many friends who do. I’ve tried to guide my interactions in such a way as to let the awesome people I’ve worked with feel awesome. This blog post is a write up of some the guidelines I follow to achieve that.
Technical Discussions
As someone who generally has strong opinions about some things, I find it very important to self-reflect on the way I communicate those opinions. Let’s examine some examples.
I recall have a discussion about how someone was adopting Moment.js to use in their project. They were working on a new project, having not used Moment.js previously. I had some bad experiences personally with Moment.js, and wished to warn them of the downsides.
My natural response is to say “Moment.js will break everything in your project, don’t use it”. There’s a couple of issues with communicating in this way. Firstly, I specify my experience as a global truth — Moment.js will break everything is not exactly fair nor reflective. Secondly, I tell the other person in the conversation as though they must do what I say. There is no room for debate, there is no experience being shared other than “I’m right you’re wrong”. This can make the other person feel as though you consider your experience more important or more powerful than theirs.
Instead, what I will try to say is “When I was working on X project, I used Moment.js and had some issues with it. In particular, the way that it used mutation did not work well with Elm. Have you ran into any of those issues before?”. In this version, we’re letting the other person know three things they didn’t in the other example: 1) we have used Moment.js on X project, 2) Moment.js uses mutation in a strange way and 3) we are interested in what they think. The third point is the most important — we aren’t telling the other person that we know better than them. We’re stating our experience and prompting their experience.
I don’t always succeed to communicate in this way when I am certain I know the most about a given topic. I’m somewhat conflicted by that. To counter this, I try to say “do you know how X works?” and then proceed to explain it if they don’t. This brings both of us up to speed in the discussion. A discussion where you are the only one who can provide insight makes the other person feels inexperienced. It also means that you lose the opportunity to ideate with the other person — nobody has to know all about a topic to be able to come up with new concepts. I’m not very fond of this either, as I think it can come of patronizing. If anyone has any suggestions, I’d love to hear.
When teaching someone how to do what you do
When teaching a new concept, adopting a student-teacher role puts the teacher in the role of power and experience. Consider a developer picking up frontend having previously only ever been a backend programmer. If you ask them to develop a whole website pixel-perfect as soon as possible, they will feel like a fish out of water. Lower your expectations — not because they are bad programmers, but rather because they are inexperienced right now. Break large tasks down into small learning projects. The code base should be easy to throw away. Writing code that implies some legacy can lead to decision freeze — should I use position absolute or position relative? What about flex? Don’t expect the learner to write perfect code.
When you’re learning something, you don’t want to be bound to your mistakes. Every commit to a production code base can feel binding. The ideal project is something small, useful, but ultimately replaceable or non critical. Admin tools are a perfect use case for this.
Another approach is pairing. I like to take juniors and examine some of the hardest issues together. The whole time we are working together, there should be constantly questions being asked — do they know about X? How does Y work? Don’t give the answer right away — the goal is not to fix whatever you need to. The goal is to help the other person know how to fix it in the future. Let them drive. Provide feedback on their suggestions. Become a living resource of that knowledge. But they should be the one to implement the changes. You are their workmate. Not their overseer. Don’t direct: discuss.
Encourage and praise
There’s nothing better than someone else telling you did a great job. Let everyone know when you appreciated something they did. It can mean a lot to people when that happens.
tl;dr
Let your workmates know you see them as equals. Experience doesn’t make you better than them, but it does mean that you are more familiar with a given issue. Bring them on board with the learnings from your experience and you can work together to solve things. Having a junior developer on your team can help you communicate your thoughts in a more productive manner. As a more senior developer, your job is to help the less experienced developers succeed in their roles.
I have some more thoughts, but I will cover them in another post.
