“Imposter syndrome affects women and minority groups disproportionately”, according to this New York Times article How To Overcome Imposter Syndrome. It sounded like the tactics worked for some people, but I definitely lean more towards the camp of “if you have a problem you gotta solve it at the root cause dammit”.
Despite colleagues’ feedback on “you are doing well”, I didn’t believe in myself. So perhaps, my problem was that I did not believe in my own ability, for whatever reason.
The method that worked for me
Be good at one thing that is demonstrably valuable and could be learnt at work, in a fixed timeframe.
Just to help with understanding, here are some of my underlying beliefs:
- Everyone learns differently and at different pace. No two engineers grow the same way.
- I am not afraid of not knowing everything. It is something I expect of the industry, and especially so after reading Dan Abramov’s Things I Don’t Know as of 2018.
So, in hindsight, what helped me in principle was:
- to establish an understanding with myself on what I know. I consider that I do know something by being able to do it myself (come up with a solution without a pair)
- to ensure the thing I know brings visible or measurable value as the feedback loop (instead of only verbal feedback by someone else saying “good job”).
What I did
1. Pick a goal and a timeframe, and pretend I needed to share knowledge by the end of my learning
I knew how to follow a written guide to do deployments using Jenkins, and copy and paste groovy scripts to add a step, if I really needed to. But I knew nothing beyond that.
After establishing that basics of DevOps was my topic, I chatted with my tech lead (see below) and eventually we agreed that “understand our current state of deployment” was a good goal to achieve in 3 months, and I should think about presenting it at cross-team tech time at the end of it.
Sharing knowledge is often times a good enough demonstration of value. Even better if there are hands on opportunities to work on it in form of stories or tech tasks.
2. Share learning goal with my tech lead
I told my tech lead about my learning goal. This is to have that someone who can formally hold me accountable – “So… how is it going?!”
3. Get extra support from someone who knows about the topic
Conveniently, my tech lead was also the person who knew about more about deployments and pipelines. So I knew that if I was stuck on anything, there was someone I could ask.
4. Grab all the opportunity(ies) to work on it at work
When there were tasks and stories that vaguely involved and looked deployment-y and infrastructure-y, I would be part of, if not anchoring, them.
Given that my tech lead now knew what my goal was, he also gave me some “invisible” tasks that were relevant. For example, we needed to increase the CPU request for one of our apps, which was a minor commit from 10m to 25m, and something that he could have done it himself. Instead he gave it to me, which meant I had to learn how OpenShift’s configurations worked, what “10m” meant, and how to test the config change.
I am now a firm advocate for learning at work, not outside of work. Admittedly I spent lots of extra hours to study because I was interested and it was effective for me, but I don’t think this is necessary at all. I would have hated if we were expected to do things outside of work hours to be good at our jobs.
How it turned out
By the end of the learning iteration, I unpicked the entire deployment pipeline of a single project across all environments and knew exactly what was doing what. (Holy cow it was complicated! No wonder I was well confused before this.)
No, I did not present “our current state of deployment pipeline” at cross-team tech time because (insert shrug emoji).
But I now have a hand-drawing of the said deployment pipeline ✍️, worked on several related stories, and with each of them became more and more crystal clear on what I was doing, and paid off some tech debt by making two improvements.
And a real bonus point was when I onboarded a new team member who said, “I learnt more about Jenkins from you in an hour than the past six months I have been at the other team”. Now, feedback from a colleague actually meant something to me.
To be continued
I am now trying the same framework for my current iteration of learning. Whilst I am studying design patterns or going through courses (“passive”), I am picking tasks and stories with the intention of unpicking the thing that I want to be better at.
For what its worth, my goal for this iteration is to be better at backend and frontend – much more vague than before! So to make my learning concrete, I wrote some blog posts and shared some items in cross-team tech time (super scary, but we gotta travel in the direction of fear!).