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.

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.

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!

Maybe this image comes to mind, because learning is a journey and it’s not the destination that matters (knowing the fact) but the journey itself (making a mistake and learning from it).

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!

If you liked this article, please check out my latest ones here: https://www.aminaadewusi.com

Thank you ❤️

A number of software engineers have reached out to me who are interested in joining the Guardian. I thought it might be helpful to write my answers down so that everyone who is interested can benefit from them.

What is the digital fellowship?

The Guardian’s digital fellowship is an annual programme open to people early in their software engineering career from all backgrounds. I don’t have a CS degree and didn’t do a bootcamp, so it’s open to us who are self-taught too! It runs for 1 year and during that time fellows are given the opportunity to rotate to different teams within the engineering department every quarter.

How have you found working at the Guardian?

I’ve really enjoyed working for the Guardian for the last 10 months. The engineering department has a really special culture where generally you meet really kind hearted people.

The people in the department are the highlight for me. Maybe because the Guardian doesn’t necessarily offer the highest salaries in the market, the engineers who are here are choosing to be here for a reason other than money. They might believe in the power of the Guardian’s journalism and hold Guardian values close to their hearts. I wonder if that’s why you tend to meet so many lovely souls here!

Also, I feel I’ve met some stellar engineers here who are incredibly responsible and professional. It feels like a privilege to work alongside them.

One of the downsides is the lack of diversity across the industry, which impacts the department at the Guardian. We have a lot more to do to attract more diverse candidates, however we do have a diversity group which meet weekly and I’ve found some amazing allies through this.

Do you have any tips for the behavioural questions on the online application?

I read over the application that I submitted and noted that I had a lot of examples that showed my passion for software engineering. I wrote about the meetups (Codebar and Code First Girl) that I attended and conferences that I spoke at. I also mentioned the open source project I worked on and juggling self study with a baby. I guess all of these things pointed towards someone who was working really hard to get into the industry. I would advise including examples that show your passion and zeal for engineering.

How did you find the initial interview process?

I really enjoyed the interview process. It started with a short telephone call and then I went into the office to do a technical pairing test and a face to face interview. I also had a chance to meet engineers during the break times on that day.

I was really nervous before the technical pairing test, but actually it was the highlight of my day and I didn’t want to stop! The Guardian has 9 pairing tests, so you can take a look at them before which is helpful.

Which qualities make a strong applicant?

I don’t know what the criteria for judging applications is, but I assume that a passion for learning would definitely be a priority. Whilst you don’t need a Computer Science degree or to have completed a bootcamp, you would have to show a passion and drive for engineering.

There are lots of other skills that make a great software engineer too, not just coding! I had a few months experience as a product manager before interviewing at the Guardian and I think that helped my application.

Do you have any tips for people who are unsure about applying?

Apply, apply, apply!

If you’re feeling uncertain, I would really encourage you to apply. I did not for one moment think that I would get a place on the fellowship and was completely shocked when I was invited to interview, let alone offered the job.

I was dreading the coding test, but it was actually the most enjoyable part for me, so don’t let that put you off if you’re nervous about it.

Even if you don’t get it, it’s a fantastic learning experience and will help you for your next job application.

What are your day to day responsibilities as an associate software engineer?

As a fellow I’m expected to maximise my learning by being enthusiastic and taking on the day to day work of the team. I spent the first 6 months on the fellowship working on the Android app, which was amazing. I’ve never even used an Android phone, let alone developed an app! Nevertheless, I had such a phenomenal time because my colleagues spent so much time pairing with me and I always felt they were there to support me.

I’ve found it really useful to voice any challenges I’m facing with my team members as colleagues are always willing to help and provide support. I feel I’ve been very lucky to get phenomenal support, which I think every new developer requires.

In your role, would you say you spend an equal amount of time on both the backend and frontend?

It really depends on the team. On the Android team, I spent more time working on styling. Having said that I also spent a great deal of time introducing Sign in with Apple to the Android app, which required backend work.

On my current team, Ophan, which collects analytics data for the Guardian, I have done mostly backend, but this quarter will be doing a lot more frontend so it’s a real mix!

In terms of stack, on Android I was writing Kotlin and Java. On Ophan, I’ve been writing Scala and using AWS and Elasticsearch. I’ve also spent the last couple of quarters doing Fridays on our DevX (Developer Experience) team which is akin to DevOps and there I’ve also been working with Scala, AWS and Elasticsearch.

Do you get to choose what kind of engineering you want to do?

Yes, fellows get to indicate which teams they would like to rotate into and ultimately graduate into after the fellowship year. All my preferences were granted. I am particularly interested in server side engineering and infrastructure and was able to do all of those things.

How was the onboarding process?

I had an amazing onboarding process whereby I simply spent 100% of my time pairing with colleagues. I personally find this the best way to learn and get up to speed quickly. On the Android team I asked colleagues at standup every morning if I could pair with them. I scheduled this into my calendar with them so that no one would forget! On Ophan, the team has a strong pairing culture, so this wasn’t required.

What has the learning and development process been like?

There is no set routine or schedule for learning and development. Rather, it’s really autonomous, which suited me as I enjoy self directed study. Whilst on the Android team I put in place weekly meetings which rotated around my colleagues, so that each week one person would pair with me on a topic about Android. On Ophan, I paired with the tech lead most mornings on an online Scala course. Also, I found a mentor outside of the teams I was working on day to day who paired with me for an hour a week on various server side topics and on Scala.

How does the fellowship invest in your growth?

The fellowship does a really good job of growing your software engineering skills, because you’re doing the work of a software engineer day to day, but with little pressure to deliver substantial work. Fellows are not costed to teams, but rather the department as a whole, so it’s completely fine to prioritise learning.

I always felt (and still do, even post fellowship) that I can follow my interests and learn in ways that work for me. The Guardian does offer 10% time to all developers, which means that you can do your own project, contribute to open source or something like that during this time.

How do you work with stakeholders and the wider team?

On the Android team, there was a lot of work with colleagues as the apps team is quite large. It includes a server-side team and the iOS team as well as designers, testers, infrastructure and user experience specialists. Given this we had a number of regular meetings where we could demo our work and plan work to be done.

On Ophan we mainly work with our stakeholders in Editorial, which is fascinating because I’ve had the opportunity to understand more about the world of our journalists which is the heart and soul of the Guardian. There are a lot fewer meetings as the team is much smaller and I feel we are more developer led.

It’s really interesting to see the contrast in team practices and cultures across the department.

What is the top strength and weakness of the fellowship programme?

The top pro is that it’s an amazing entry level software engineering scheme and there are so few of these in the industry. Not only that, but it’s high quality because engineers across the department are so willing to give their time to support fellows through pairing and in other ways.

The con (which could definitely also be seen as a pro) is that you have to rotate teams. This is perfect for people that are unsure about the kind of engineering they want to do, but for those who already know it might feel like a detour. The good thing is that you have a lot of choice about which teams you would like to try during your fellowship year and you could choose to specialise in backend roles for example if that was your interest.

Any other questions?

If there’s anything I haven’t covered here, please do ask me your question on Twitter and I would be happy to add it here or respond to you in private.

If you liked this article, please check out my website and YouTube channel.

Thank you!

I just finished reading Maisie Hill’s Period Power. Wow! What a read! Maisie completely enlightened me about the power of understanding our own unique menstrual cycles. I now have a basic awareness of the four seasons of the cycle and the super powers they bring.

I’ve been working full time as a Software Engineer for 5 months and recently have noticed significant changes to how I feel whilst menstruating. I’m so glad I found Maisie’s book to shed some much needed light.

I’m no stranger to pain whilst menstruating.

I’ve been ambulanced to hospital after collapsing in a London train station. On another occasion my husband had to pick me up from work due to severe, debilitating cramps. I found a haven in the office prayer room after lying on the floor in a work toilet cubicle for hours in agony.

I remember riling in pain at home and wondering if labour would be as bad. As a mother who gave birth at home without pain killers or a health professional (not by choice – she got stuck in traffic lol), I actually believe that the severity of my period pains were not a million miles off.

My periods are a lot better since those terrible days and I had largely forgotten these stories. But last cycle, at work, I started to notice that I couldn’t concentrate.

I spent a whole day trying to do my normal work, but struggled. I felt worried that maybe I was experiencing burn out. It felt as if grey clouds had descended into my mind. It was foggy. I couldn’t think or process things. Basic tasks would take eons.

Then my period started. I suddenly had that “Aha!” moment when the world suddenly makes sense again. I couldn’t concentrate because of my period. Now I’ve read Maisie’s book and started to educate myself, I realise that this brain fog is calling for me to do something.

Apparently periods are a litmus test for our overall health. The period we have today, reflects how we were feeling, the care we gave ourselves (or not) 6 months prior. There’s a bunch of science behind that, which Maisie explains elegantly!

It’s therefore no surprise I’m noticing changes after 5/6 months in my new job! What I thought of as burnout, was actually my menstrual cycle saying “Hey Amina! SLOW DOWN! Take a break!” And damn right, I’m going to listen.

I’ve spent too long in my life trying to push through, not heeding the wisdom my body had to offer. Enough! Rest sincerely is the new revolution. Putting the phone down, closing the laptop lid, resisting the impulse to turn on Netflix, and just sitting. Hell yeah. Living life on the wild side now.

Each menstruator will have a different experience and cycles will differ over the lifetime of a person. The symptom I’m currently feeling of lack of concentration is something that other colleagues at work experience too.

I nervously approached a couple of kind colleagues who I felt I could confide in. I couldn’t help but laugh when one told me he feels that way on a weekly basis. So much so that he keeps a list of non-intense-brain-activity work at hand so he can still add value to the team whilst also meeting his own needs.

Another colleague completely empathised with my situation and told me about one of her team members who openly tells the team at standup when he feels he needs to take a break. His sharing helped her feel more at ease about addressing her own feelings rather than ignoring them.

I wonder, are there many suffering in silence? Menstruators and non-menstruators alike? Those who need a break from solving problems in codebases? From doing logical work? From even the act of looking at a computer screen?

I don’t know the answer, but I do know that I’m not going to ignore what my body is telling me anymore. I will be a revolutionary and rest. I will take sick leave if I need to due to menstruation. I will speak about how I feel at work so that others feel they can do the same.

Maisie talks about the time of menstruation being the menstrual cycle’s winter season. It’s a time that calls for the lights of the world around us to go down and the inner lights to rise up. It’s a time that some traditional cultures encouraged menstruators to leave their daily activities and practice meditation, believing that they could access a spiritual realm unavailable at other times.

Whilst I haven’t reached my nirvana, experimenting with rest has been refreshing so far. I’ve also taken Maisie’s advice to start a menstrual cycle diary in order to track how I feel each day and piece together my own unique patterns. Menstrual cycles are gifts. Listening to their messages and enjoying its seasons, seems wise.

I don’t feel like there’s a well defined place for human feelings and emotions in the workplace. There are schedules, deadlines and targets, but there aren’t really spaces for discussing how we’re feeling. I wonder if this will change in the future. Can we embrace our humanness, rather than treating ourselves like the machines we work with on a daily basis?

I very much hope so. At least, I’m willing to give it a try.

I recently got my first software engineering job. As someone from an under-represented group in tech, I’m constantly reminded of the inequalities in access to the web development industry. Of 80 developers in my department, I am one of few women, one of two mothers and I may be the only black woman (the department doesn’t track data on this yet).

This balance feels wrong to me. It feels unjust. I don’t understand why this job, which can be done by anyone with the passion for it, clearly has weighted access to a certain type of person. When I feel this way, my automatic response is to start solving the problem.

I signed up to the Diversity group at work. I gave an internal talk about how to support new developers. Colleagues started inviting me to more forums and presented me with ideas for things that we could do.

Soon after starting my job, I realised that my days were filled with meetings. I was hardly getting a chance to sit at my desk and code. Tanya Reilly’s tech talk, “Being glue” made me realise that by doing all this work, I was risking my career. I was becoming like glue – doing the non technical work that makes a project or team succeed.

If I don’t focus on coding, the main activity of a software engineer, I will struggle to become good at it. If I struggle with this, I may not get promoted.

A colleague put it aptly, I may be tagged as a junior who will quickly move into management, as soon as she gets the chance.

This isn’t what I want. I didn’t work the hardest I ever have to become a software engineer, just to be labelled as “not technical enough”.

Therefore I cancelled all my non technical commitments.

It feels sad, because there are so many changes I would like to make happen in our department. However, I also really want to learn my craft and eventually get promoted. I wasn’t hired to be a diversity lead.

I want to understand our technical projects and be able to solve problems autonomously. I want to be a great developer. I hope that I will help even more people as a senior developer, confident in her technical abilities.

Does that mean I can’t do diversity work? No, it just means that I need to influence and persuade others to do it. There are colleagues who may be in positions in their career where doing this work won’t hinder their progression. Perhaps those who have already proved their technical ability. I want to persuade those people to start contributing to diversity work. Let us, who have just entered the industry, find our feet here and become the senior developers this industry so desperately needs us to be.

If you are from an under-rep group, please don’t feel under pressure to do lots of non technical work. It’s the responsibility of all of us to do this, not solely those from under-rep groups. It’s achievement enough that you’ve got your junior developer role. Focus on that.

For those of you in senior developer roles or management, what is your contribution? Please check out my ffconf talk, “How to become a developer with no time and no money”, which gives lots of ideas as to how you can contribute, or read my article on a similar topic. Thank you for being part of the solution.

If you liked this article, please check out my latest ones here: https://www.aminaadewusi.com ❤️

So, you’ve started learning one programming language, maybe Ruby, JavaScript or Python and now you would like to move onto your second. There are lots of reasons you might want to do this.

Maybe there is a job or a bootcamp you would like to apply for and you need a particular language for it. Maybe you want to try something new just for fun. For whatever reason, I would like to reassure you that you are most definitely not starting from square one!

All of the learning you have done in your first programming language are very likely transferable to your next. Learning about objects, classes, methods, data types and operators for example are transferable.

In addition, there are skills that cut across all programming languages like getting acquainted to your terminal, Git, GitHub, using an IDE, CI/CD tools, raising and merging a PR, that you don’t need to learn again!

I recently got my first developer job at the Guardian after teaching myself how to code in Ruby. Whilst I was allowed to do my technical test in Ruby, I will need to learn other languages, amongst them Scala, for my job.

When I received the job offer and it finally dawned on me that I might be better off leaving Ruby and starting with Scala, I suddenly felt quite sad and very nervous.

Sad because I felt like I was leaving behind a family member.

Over the preceding months I had coded Ruby almost everyday, made fantastic relationships with loads of Ruby developers who formed my core support group and I had attended several Ruby conferences. I felt like I was leaving a secure home that I had built myself. Now I had to leave to venture into the unknown.

I felt scared that I would be starting all over again after months of hard work. Whilst the allure of becoming an engineer so that I could constantly learn new things seemed attractive before, suddenly the reality felt quite different.

I spent some time explaining my feelings to several mentors and receiving their advice. Here is what worked for me:

Get started

Soon after I started learning my second programming language, Scala, I realised that I was using the skills I had learnt in Ruby. It was a completely different experience compared to teaching myself how to code for the first time.

One key difference was that I started Scala using Test Driven Development (TDD), because this discipline had become so natural to me in Ruby that I couldn’t help but take it with me when learning Scala. When I asked for a code review from a new Scala mentor, he noted that he didn’t write his first test until two years after starting to learn Scala. This showed me that indeed, I was not starting Scala as a complete beginner.

Your learning methodology

Having learnt one programming language, you may have an idea of the learning style that works best for you. For example, do you prefer learning with YouTube videos, tutorials, buildings things, with other people at meetups? Ask yourself this question to understand how best you learn and apply this to your second programming language.

For example, I learnt Ruby by pairing with senior developers, completing technical tests and doing kata like exercises such as Exercism and Codewars. Given I knew this was how I learnt best, I applied the same method to learning Scala which really helped.

Find others who have done the same

It’s likely that there are other developers who have walked the same path as you and can translate the second language you are learning in ways that would make sense to you given your first language.

I googled “Scala for Rubyists” for example to learn how I could approach Scala as a Ruby developer. It really helps to get advice from people who have made the same leap.

I also attended a Scala meetup where I found other people who were new to functional programming, so we could relate to and support one another. For example, I paired with a lady who had learnt Python and we often had the same questions when learning Scala.

Don’t worry

Overall, don’t worry and relax! Enjoy learning your second language because I’m pretty sure you’ve done a lot of the hard work already in getting started with programming.

Yes, it may feel a little emotional leaving the language you first started with, but you can always go back to it and the community that has supported you will still be there.

Learning a second programming language is an amazing way to experience different ways of solving a problem. I’m really grateful that I have been introduced to functional programming, a completely different paradigm. What has your experience been like learning your second programming language? Please share in the comments below or on Twitter!

What is the Guardian’s Digital Fellowship?

The fellowship is for budding software engineers who are looking for an entry level position. It’s open to people who have taught themselves how to code, have done a bootcamp or have any other route into tech.

It’s a competitive scheme and not surprisingly given so few companies offer such high quality programmes. Successful candidates do a minimum of two rotations in different engineering teams over a one year period.

Their main goal is to learn as much as possible and they are given a designated mentor and lots of support to ensure this.

My first week

I was told a couple of weeks before I started that I would be on the Android team.

I have not coded in Kotlin or Java and have never even owned an Android phone 😂 so I really am learning everything as a complete beginner!

My mentor and whole team have been incredibly welcoming and helpful in my first week. Everyone has paired with me and made me feel right at home. I’m able to ask all my questions without feelings of judgement or fear!

After spending a year teaching myself Ruby with very little time and with only the amazing kindness of willing engineers, it now suddenly feels like the greatest privilege to have a whole team of professional developers willing to help me and a 40-hour week!

I expressed these feelings with my mentor and we decided to share our learnings with the wider community so that hopefully other people can benefit from my experience. We recorded our first YouTube video.

What I’ve learnt

I’ve admired the way my team treat one another when discussing tricky problems. I don’t see any blame culture whatsoever and there’s such a positive camaraderie in every meeting.

Across the department there seems to be a culture of openness and willing to discuss all issues in a non-hierarchical way.

There seem to be some challenges too. At times poor communication between senior management and other staff and of course the Guardian’s challenge to achieve sustainability, but no company is without challenges.

I really value the kindness of everyone I have met. I also really like the flexible working options, which suit me as a parent. I feel that people in the team recognise the importance of our lives outside of work.

How about non coding activities?

This week I attended Morning Conference, which is where the Guardian’s journalists discuss the results from yesterday’s articles and the news today. Anyone at the Guardian can attend. I really enjoyed listening to the journalists speaking about their views and it reminded me why we as engineers are here.

I attended the Digital team’s Diversity group, which was great because I got to meet some more engineers in different teams and made new friends. I also found out about interesting diversity initiatives going on, including a bake sale for Black History Month led by one of the previous fellows!

I had two restaurant lunches during the week! One with the apps team and another with the fellows alumni.

I got invited to join the Guardian’s Women’s group and also a People of Colour group, both of which are open to everyone at the Guardian. I’m looking forward to meeting with other people in these groups from across the organisation.

Overall

I can’t help feeling that I couldn’t be in a better environment to learn how to become an engineer. I’m so grateful that the Guardian offer a fellowship programme and I hope that other companies can do the same too.

I’ll be sharing my journey on my website, on YouTube and Twitter. Join me!

In this article, I want to support readers who are already teaching themselves how to code or are considering it.

For others, I hope this article sheds some light on how we can support those trying to become engineers without bootcamps or formal education.

What does self-taught mean?

To me being a self taught engineer means that you haven’t completed any formal coding education, such as a bootcamp or a Computer Science degree. I would love to hear other opinions on what this term means to you.

When I started considering a career in tech, I didn’t realise there was such a thing as “self taught”. I just assumed that anyone without a CS degree would have to do a bootcamp like Makers Academy, General Assembly or Flatiron. So in Autumn 2018, I started preparing for my bootcamp application.

I really wasn’t sure how I would manage to do a bootcamp, because I had a 9 month old baby, I live in the suburbs at least an hour from the city where all the bootcamps are and I was breastfeeding. The cost of the bootcamp combined with expensive London nursery fees meant that it was a significant investment. This and the lack of flexibility in the programmes meant I was not looking forward to the prospect.

Luckily, I received a scholarship to Mozilla’s View Source Conference in London. It was my first ever tech conference and there, I met a lady who would become an important mentor for me. She was the first one who told me that I didn’t have to do a bootcamp and that I could definitely get a job by teaching myself.

I am so grateful to the bootcamps whose marketing reinforces the positive message that it is possible to change careers into tech. Without them I may not have started my journey. However, for many this option is a challenging one and the self-taught route may be preferred.

How do I choose what to learn?

There are so many different resources out there that can help you on your learning journey. For example, you could use a platform like CodeAcademy, Freecodecamp, Exercism, Codewars or a Udemy or Coursera course.

You could also find a GitHub repo that you feel passionate about and learn by contributing to a project with other developers. Or, you could start by completing technical tests and putting them on your personal GitHub profile. Or, dare I say, create your own website! There are so many options!

I would say start with the goal in mind. Why are you interested in learning how to code? What kind of job would you like? Frontend or Backend?

Once you have an idea of the kind of job you want to pursue, find job adverts that describe your dream job. Which skills and competencies do they require? Which languages do you need to learn? Which testing frameworks? Do you need to understand git and bash programmes? Make a note of the requirements.

Can you find people on LinkedIn who have that job title? If so, it would be worth reaching out to them to ask what advice they can give on the evidence you should build to make a compelling application for an entry level job. Would a GitHub profile with your work be evidence enough? Do you even need that or do you just need to pass a technical test to get your dream job? Finding out the answers to these questions will determine the path we take.

How can I structure my self-taught journey?

The prospect of trying to teach yourself how to code may seem really confusing. There are so many resources out there. Which ones should you choose? Also, what should you set as your goal. Which kind of job should you be targeting?

One of my mentors encouraged me to start applying for junior developer roles very early in my coding journey. I was rejected from 99% of these jobs, but what I found helpful was the conversations I would have with the HR representatives and even moreso, the technical tests I would receive.

Applying for jobs is not easy. I would receive multiple rejections in one week. At one point I thought about quitting, but I’m really glad I didn’t. Instead, I saved all of the technical tests I received and I started completing them really slowly. I used the tests to structure my learning. I put them on my GitHub and used the test challenges to discover what I needed to learn next.

Finding mentors

It’s interesting that I call myself “self-taught” when in actual fact, I couldn’t have made progress without the fantastic mentors that have supported me over the last few months and given me so much of their time.

Being self taught doesn’t necessarily mean you have to be alone, battling with google and your computer. I often think of learning how to code in the same way I experienced learning classical music as a child.

In music, it’s very normal to have regular lessons with a teacher and then to go away and practice by yourself before your next lesson. In the same way, with coding I found people who would kindly pair with me or answer my questions over email or chat so that I could solve problems with my code that were not initially clear to me.

I used open source communities to find contributors who would be happy to pair with me. I also used meetups like Codebar in London and companies like Thoughtbot who have office hours where you can pair with a professional developer.

I found mentors who genuinely love coding, teaching and helping others. I also felt that when potential mentors saw how passionate I was and how interested I was to learn, it was easier for them to become committed to me and my journey.

How to keep yourself accountable

A major reason for seeking formal education is the need for structure and accountability. I open sourced my learning plan and used some agile practices (sprints and retros) to keep myself motivated and learning every week. I shared my plan with my mentors and got their feedback on how I was doing.

I also started creating a network of people who like me, were trying to teach themselves how to code, I would meet them at tech conferences and meetups and keep in touch with them. These people became my support group. When I got rejected from a job or when I was feeling low, I would turn to them to lift me up again.

One of my favourite posts on rejections is from the amazing Linh Nguyen: https://link.medium.com/oJ8r28u0vX. I read and re-read articles like this whenever I felt low in order to keep my motivation up.

Here is an actual recent email I sent to a mentor:

— — — — — Forwarded message — — — — -

On Wed, 12 Jun 2019, 10:12 Amina Adewusi, wrote:
Hi
I feel like I’m hitting a lot of walls. I am struggling to get past technical test stage. I don’t know how to keep going on this journey in a balanced way (with a full time job and family) knowing that it could take me quite a number of months before I learn enough to pass technical tests.
I would really appreciate your encouragement and any tips you have on how to keep going.
Thank you,
Amina xx

— — — — — — — — — — — — — —

I didn’t hold back to share my struggles with others and reach out for help. I would suggest doing the same in order to receive the emotional and technical support you need.

Choosing the right job

A few months after receiving many job rejections, I received some interview feedback that I was in fact at graduate level rather than junior developer level and that I should focus on applying to graduate jobs and apprenticeship schemes rather than junior developer positions.

This feedback was very helpful for me and it was largely true. I had not realised that there was a difference (at least in London it seems) between graduate level and apprenticeship roles compared to junior developer roles. In fact, when I started applying for apprenticeships, I felt I was a competitive candidate after all of the practice I had been doing for junior roles.

I would recommend to others keen to start their first job as soon as possible to look out for apprenticeships, graduate roles and other entry level schemes. Otherwise, I’m very sure it is possible to successfully get junior developer roles, it just might require a little more time.

Be visible

I was pushed by one of my mentors to speak at tech conferences. I never ever thought it was something I could do. I wondered what I could offer a technical audience?

However, after speaking at a few conferences this year, I realise that there are so many people trying to get into tech who are forming an increasing part of conference audiences. Also many engineers will have juniors in their team. I found that in fact I did have something to contribute as a speaker.

I highly recommend speaking at conferences, even before you have a job. I received a few job offers after people heard me speak at conferences, but even more valuable than that, I made so many friends. Audience members would come up to me after my talk and introduce themselves. It was a wonderful way to widen my support network and I wouldn’t hesitate to recommend it to others.

Pacing yourself

We live in an age where we have a strong desire to complete chapters of our lives in haste. We may have very good reasons to do so, but if at all possible I would highly recommend teaching yourself how to code at a sustainable pace.

I had an interesting experience where I actually broke down in public whilst attending a coding workshop.

As self-taught engineers we can be very hard on ourselves, suffer from imposter syndrome and push ourselves to the limit. I really struggled with knowing when to take a break. Teaching oneself how to code is a long journey, more of a marathon than a sprint. Taking the time you need to do this whilst prioritising your wellbeing is vital for success.

Can I help you?

Leave a comment with your view. I welcome views different from my own. We all have varying experiences and it’s great to hear from everyone.

Please reach out to me if there’s anything I can help you with. I am particularly keen to support under represented groups in tech.

If you liked this article, please check out my latest ones here: https://www.aminaadewusi.com ❤️

Diary of a Self-Taught Engineer was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.

Thank you Brighton Ruby for inspiring this article!❤️❤️❤️

There are lots of senior developers out there who wonder what to do with their career after many years of experience.

They could go into management and their day would typically consist of lots of meetings with key stakeholders across their company.

They could consider consulting if they want to keep coding the majority of the time. There are many other alternatives too, but for now let’s focus on these two broad cases. The first being management and the second being programming as a consultant.

I would argue that in both these cases, mentoring more junior engineers will be required.

As a manager, you might not be getting involved in detailed code reviews but you are likely to be coaching your team on how to navigate their career trajectory, you’ll be keen to understand what motivates them in order to incentivise their best work on your team, you’ll also advise them on how to support junior members of their own teams.

As a consultant you might be working with various engineering teams to support them with actual coding, upskilling their team or more broadly technical direction. Ensuring that your client is successful will mean having an awareness of the team you’re working in, including junior members of staff.

I want to argue that mentoring and supporting more junior developers is key to being a successful senior developer, manager and consultant.

I also assert that it might be challenging for engineers with many years of experience who have been working largely by themselves to suddenly be expected to hold expertise about nurturing more junior talent.

As a hobbyist programmer myself, having started teaching myself how to code just 9 months ago and aspiring to become a junior developer, I understand how it feels to be in a position where you are seeking mentorship. I also have direct experience of joining a company as a junior developer only to realise that there was little means to grow in this role.

I would like to offer my humble advice to more senior developers who feel unsure or unconfident about how to mentor juniors.

When it comes to mentoring, the first thing I would ask is what kind of work I aspire my developer to do. What kind of problems should they ideally be able to solve independently? Once I have an idea about this, I have a clear goal in mind about the kind of things they will need exposure to in order to build both their expertise and confidence to one day independently fulfil this role.

The close second question I would ask is, what kind of learner is my mentee? I myself like self directed learning where I am given a lot of freedom and independence to forge my own learning journey. Someone like me needs a mentor who is available to answer questions and pair programme with when they get stuck. Apart from that I feel like this kind of person, who tends to be highly self disciplined prefers less structure than more. Instead of telling them what to do, you can give them problems to solve. These might be actual business problems or side projects.

Others may prefer a more structured plan. This is where understanding how they learn best is wise. Are they visual learners? Therefore will YouTube tutorials and diagrams be best for them? Do they prefer reading and writing? Can they learn how to read technical documentation, blog posts, books and potentially write about their learnings? Understanding how someone learns best will be most efficient to advising them on which resources to consume.

No matter the un/structured nature of their preferred learning style and means by which they learn, I would contend that every junior needs pair programming. And frankly I think the more the better. There are effective ways of doing this.

I prefer leading when pair programming. That means that as a junior I am in control of the keyboard and mouse. As a mentor, making sure your junior feels comfortable to make many mistakes is essential. It might be frustratingly slow for you, but take a deep breath and try and empathise. You will see progress within a matter of days and weeks which will show you that your pair programming with them is having a really positive effect.

Lots of praise is important. Reminding your juniors of the great progress they have made, even just one improvement compared to the week previous, will help keep both yourself and them motivated.

Encourage questions, no matter how stupid to be asked. You could volunteer your own very basic, if not outright silly questions and try and find the answer out together, in order to make them feel more comfortable.

Building a relationship of trust where both you and your mentee feel you can openly and honestly express yourselves is pivotal. If you’re not sure where to start, you could try by asking them a few questions and taking the time to listen carefully to their answers.

Questions could include:

• What are you finding challenging?
• What are you proud of?
• What are you enjoying the most?
• What would you like to improve?
• What are you most excited about for your future learning?
• What can I do to help?

Asking these questions regularly, perhaps even at the end of every week, will give you the information you need to iterate and improve upon every week spent supporting them. Soon it will become clear what their formula for learning success is and the kind of optimal support they need on that journey.

In May 2019 I spoke at my first tech conference. It was an unconference where attendees are able to propose talks at the beginning of the day and then all attendees vote to decide who they want to hear.

I had prepared a talk in advance, because I was keen to try speaking after having attended Global CFP Day, which supports underrepresented groups in tech to prepare talk proposals.

All in all I had a phenomenal experience, right from talk preparation to the feedback I received afterwards and all the people I got to meet at the conference as a result.

The main learnings for me were:

Talk preparation is an amazing experience. I researched a topic dear to my heart (the late great Jim Weirich) and conducted interviews with experienced developers. I learnt so much from the weeks of preparation and that learning is going to stay with me forever.

After proposing my talk at the unconference, I received a much higher number of votes than I was expecting. This taught me that a topic that had been so close to my heart, was also of great interest to many attendees. It was so touching to realise that I could share this with others.

Later in the conference, a developer came up to me and said he had proposed a talk because of the one I had given. This was unbelievable to me. By giving my talk, I had encouraged others to do the same. I had really enjoyed his talk on code reviews and was completely blown away that this was initiated from mine.

I had such a positive experience and I am looking forward to speaking at Brighton Ruby in July.

As a background, 6 months ago I started teaching myself how to code (for more on this see here). I got my first job soon after (see here) and yesterday, my first break down 🙂

Why I broke down

There are physical reasons why I broke down and a number of emotional ones too.

First, I had not slept well in many nights and I hadn’t even taken a sip of water the morning it happened, even though I had prepared breakfast for my family. I completely forgot to do the same for myself. Lack of sleep and depression are best friends in my world. This compared with no food and water is simply a recipe for disaster.

Generally I have been pushing myself very hard to do my day job whilst coding most evenings and at least a half day on the weekends. This coupled with lack of sleep proved dangerous, although I did not realise it at the time.

Finally, I also suffer from imposter syndrome and perfectionism. The workshop environment was my perfect nightmare. A small room, packed with people typing away, solving a problem I felt I could not.

Very quickly into the workshop I realised I wasn’t able to do the task without support and that I wouldn’t be able to get very far with the work given it was above my level.

I started crying. At first silently and I hoped that no one could see. Unfortunately I was right at the front of the room, so I was pretty much in full view of everyone. The tears just kept rolling down my cheeks. I could not stop them. And then I just started full on crying. I had tissues surrounding me. I was just broken.

My sheer physical and mental exhaustion coupled with my nightmare scenario of being unable to complete a problem, surrounded by people who can, led to me crying uncontrollably.

I didn’t feel embarrassed or ashamed, I was simply shocked and scared. At the time, I didn’t know why it was happening and I could not stop it. I ended up leaving the workshop.

What can we learn?

Teaching yourself how to code is not easy, but it’s the path I have chosen and likely also you too if you are reading this.

An old rowing coach told me that I could only get as strong as the time I spent resting.

This is so counter-intuitive, but it totally makes sense. He told me that when I was training my muscles were adapting and then at rest, they would heal and re-form stronger. This is not scientifically correct I’m sure, but it’s just a high level summary!

Therefore, rest is important. But, it’s not easy to know how much is too much work. We don’t have a battery icon telling us when we need to take a break. But we can use our self awareness to create boundaries and be aware of certain burn out triggers to watch out for.

Practical tips

The lovely Jo Franchetti advised me to schedule rest time or have a slow day after attending a workshop or event. I think this is really important and I’m going to implement this immediately.

I’m only going to code one evening per week and half a day on the weekends from now on. I want to try and accomplish my learning during working hours.

I’m also going to make an effort to schedule rest time. This is really counter-intuitive for me, but I think it will be worthwhile.

If you have any other tips or ideas, please reach out to me @a_adewusi, I would love to receive them ❤️