New Engineer

Failing as a junior developer

I’ve been a software engineer for the last 15 months.

I’ve been failing a lot recently

Sometimes failing quietly and sometimes failing in very public ways at work.

I recently had my first incident retro where my actions caused the incident (an incident retro is where you get together with your colleagues and understand why something went wrong and what you can do to prevent it in the future).

I’ve also recently received some feedback from a senior colleague highlighting where my fear of failure is dampening my growth potential.

Fear of failure and my internal reaction to failing is clearly a challenge for me.

I imagine that for a lot of developers, this could be something that they face in their early career. By writing this article, I’m hoping to help myself as much as anyone else who might relate to this.

What kind of failure are we talking about here?

Failure is showing up for me in a few different ways.

The most painful is the feeling of shame when I don’t know the answer to something I think I should. This frequently happens with mathematical problems and coding challenges specifically, rather than my day to day work.

Senior developers fail all the time

Whilst observing my own experiences of failing, I do note that very senior developers are also failing and quite frequently too.

They cause incidents that affect colleagues and users. They introduce bugs which we are fixing for weeks afterwards. They introduce bugs that we only find years later. They fail and they fail a lot.

If the most senior developers are failing, it must mean that failure is part of the engineering job. It means that it’s something that I and other junior engineers need to get used to.

Fear of failure is not new for me

I seem to fear failing, because I’m scared of not being respected, valued and ultimately loved. There is a lot to unpack in this statement. As a child I may have internalised an idea that if I get something wrong on a maths test, my parents might feel sad and therefore they might not love me as much. Of course this is not the case, but nevertheless there began an unending avoidance of failure.

I remember in school actively avoiding challenges, so that I wouldn’t have to fail. I avoided mathsy subjects in my Baccalaureate (pre university level), choosing the lowest level of maths I could get away with and taking Design Technology instead of sciences. I chose not to do primary research in the dissertation for my degree, choosing secondary research instead (taking the results from other people’s surveys etc) to avoid the risk of my research going wrong.

Photo by Chris Liverani on Unsplash.

In other areas of my life I have taken risks. I’ve taken the road less travelled and declined PhD scholarships and offers of fancy well paid legal jobs to work on the things I’m most passionate about. I have taken risks, but largely not with technical things like maths where there is either a right or wrong answer.

According to Jo Boaler, in her book, Mathematical Mindsets, the avoidance of subjects which are seen to have a right and wrong answer rather than room for exploration is more common in high achieving women, especially those from minority ethnic groups and low incomes. She blames our western education systems for creating fixed mindsets and suggests changes that teachers can make.

Jo Boaler's book, Mathematical Mindsets
Mathematical Mindsets: Unleashing Students’ Potential through Creative Math by Jo Boaler.

Exploring math trauma has helped me to understand why I tend to feel incredibly insecure when I make a mistake in a teacher-pupil relationship at work (for example, if I have a coding mentor). It evokes the same fear I must have felt as a child in maths and sciences when faced with the prospect of making a mistake.

The problem with running away from what scares you

Being too scared to try is a recipe for disaster, because there is no growth, no learning and no progress. All of the things that are our worst enemies as junior developers.

I’ve experienced this as focusing on the parts of the job I find easy and spending the least amount of time on the bits I find hard; programming in Scala for example. Rather, my time allocation should be the other way round. I should be spending the most amount of time on the things I find difficult. I should be spending time making mistakes in a safe environment and quickly correcting them for efficient learning.

Adopting a growth mindset

Early on in life, I seem to have adopted a fixed mindset, rather than a growth mindset.

In a fixed mindset, I judge myself for making a mistake and feel sad. In a growth mindset, I feel happy that I’ve made a mistake, because I understand that I’ve learnt something new.

Adopting a growth mindset is crucial for software engineers, no matter their years of experience.

Before I started noticing my reactions to failure at work, I actually thought I held a growth mindset! I didn’t realise that my mindset was incredibly limiting. Now, I’m working on changing this.

How do you adopt a growth mindset?

When I notice myself feeling emotional because I’ve made a mistake, I try to remind myself that this is me learning. I try to celebrate the mistake in my mind.

I know this sounds funny, but I visualise myself wearing nice clothes, with my hair and nails done, driving fast in a flashy car on a motorway with loud music on, celebrating my mistake!

Failing with style

There definitely is a way to fail with style. After causing another mistake that affected colleagues across my department, I was drafting a message to write on our internal chat.

I started writing something like “I’m sorry, I made a mistake…” My colleague stopped me immediately and said this is not required, because we do not assign blame to individuals, only success. He said, rather I should write something like “We have caused xyz problem and will keep you updated whilst we work on a fix”.

This taught me that failure, at least in my current workplace, is detached from the individual. There is no blame or judgement. The only person judging is myself.

Take regular breaks

It’s vital to be your own best friend as a junior engineer.

Most of the work I do is completely new to me and I’m literally sitting at the edge of my understanding most of the time. Being outside of your comfort zone for the majority of your working day is tough!

That’s why, as a junior engineer, you’re a superhero. You spend most of your day not understanding, struggling, making mistakes and then you do it all again the next day! If that isn’t a superpower right there, I don’t know what is!

But, even superheroes need rest.

You may have hustled to get into this industry. You pushed yourself through early mornings and late nights. You kept striving past rejection after rejection.

Now you’ve got your job, you don’t need to do that anymore. You need to rest and look after yourself. This is a marathon, not a sprint.

Whilst you can get an entry level job in less than one year (if you’re very lucky), you can’t become a senior engineer in a year! It simply takes time.

Even then, I don’t think the mistake making ever goes away. It just changes, there are different kinds of mistakes and we adapt so that we become more comfortable making mistakes.

For these reasons, it’s really important to take regular breaks. The pomodoro technique is nice for daily breaks. I know some engineers who take some days holiday at least every 6–8 weeks. I’ve been thinking about working fast and working slow and how I can welcome different paces of work, accepting that some days I am full of energy and in others I am needing slowness and ease.

Superheroes need rest. Junior engineers need rest! Finding a sustainable rhythm to the challenges of everyday life as a new engineer feels really important.

The journey continues

Adopting a growth mindset takes time. It requires unlearning years and years of habits, but each journey starts with a single step.

If you’ve experienced this, please share on social media. I hope that there aren’t junior developers suffering in silence thinking they’re the only ones going through this!

Thank you Nick Owuor for the cover image.