Guest Blog: Safia Mirza - The 7 Lessons I've learnt in 18 Months as a DevOps Engineer

05/05/2020  

The 7 Lessons I’ve Learnt in 18 Months as a DevOps Engineer

My route into the tech sector wasn’t typical. I don’t have a computer science degree, and up until last year, the only thing I knew about the Cloud is that Apple wanted me to pay for it.

I have worked as a waitress, bar-tender, a paralegal in Leeds and became a self-employed financial services contractor. Whilst in finance I moved to Glasgow as a Change and Competency Manager and then accepted a position in Manchester as a DevOps Engineer at KPMG as part of their graduate training programme in October 2018.

Having been in this role over a year, I have learnt so much and want to share those lessons…

1. Be prepared to fail (and learn from those mistakes)
It’s easier to break things than you think. I often hear the mantra of failing fast, but learn forever and I got to experience this first hand in my first couple of months at work.

I was asked to update a user’s telephone number on a production database that was used for their MFA token. A pretty simple task, however, I had forgotten the “WHERE” statement. This meant that instead of updating just one person’s telephone number, I had updated 3,800. The blood drained from my face and, I just stared at the screen. In a last-ditch attempt, I pressed Ctrl + Z, a few times, just in case, but unsurprisingly, it didn’t work.

Then reality hit, and I knew I needed help to rectify it. I told my manager I had really messed up and unlike me, he was very calm, and asked me if I had remembered to back up the database… which, fortunately, I had. He helped me write a Python script that pulled all the old telephone numbers from the back-up and updated the new database with them.

For me, this story epitomises the culture of a successful DevOps environment, being supportive, promoting learning and knowing that even if you mess up, you can always ask for help and learn from your mistakes.

It’s helped me to hear that I’m not the only one that makes mistakes in this industry. In 2015, Google Drive went down, because the code being pushed, worked differently in the production environment to the test. Remember, even the biggest tech giants can mess up, so if you do, learn from it and keep going!

2.  Ask for help!
Another lesson from my earlier story, always ask for help, no matter how badly you think you’ve messed up, two heads looking at a problem can often be better than one.

Another pair of eyes on your work can often spot anything you’ve missed, before, you execute anything major. A two-minute check now, can save you a lot of time later.

There will be times where you’re sat staring at your computer screen, with an issue that may be obvious to other people. For example, you may be trying creating an application gateway to connect your application on a virtual machine to a public URL, and you just can’t quite figure it out which is really frustrating, so ask for help!

Since we’ve gone into lockdown it’s been harder asking people for help. I can’t just grab my laptop and go sit next to a colleague, so instead, we share screens virtually. As my manager walked me through the above issue on Azure, I realised I did understand the technical aspects of the issue, I just wasn’t quite sure how to implement them.

By asking for help, I get to consolidate my learning and feel more secure in my role. My colleagues never make me feel foolish or small for asking for help, they like sharing their knowledge. They remember being in my position and have shown me that I can rely on them for support which promotes a more collaborative working environment.

3. Googling is a skill
Prior to working in tech, I thought that if you didn’t know the answer to something, you had to blag it. In my new role, I asked what my colleagues do when they are faced with questions they didn’t know. They said, “Be honest, say you don’t know but can find out, then Google it”.

Google it? I never realised Google was such a known aid. I thought it was mainly used to find out the name of an actress I can’t remember from a sub-par film. Google is now my first step for anything I don’t know before I go to my colleagues I try to exhaust all the other options.

Googling, however, is easier said than done.

If you get an error message, start with putting that into Google, chances are someone has seen it before, asked the same question and got an answer for it.

When you have no error messages, it gets a lot harder. Just typing the words in, is not enough, you have to put them in the correct order to link to the correct Stack Overflow page. Googling is an art, and the more you do it, the better you will get at it and the quicker you will be able to solve your own problems.

4. Don’t discount yourself because you’re new to the field
I thought that just being new to this field meant that I had little to offer but soon realised my experiences had value. Skills that you think are not technical can still be really useful. Being organised, adaptable to change and problem-solving can all be readily applied to most technical roles.

In 18 months, I have learnt how to code in Python, understood what the Cloud is, used AWS, Azure and GCP to create client solutions, used Terraform to automate tasks and passed my AWS Solutions Architect Associate exam. If I can achieve this in a year and a half, so can anyone! So believe in yourself, remember everyone was new to this sector at some point, Ada Lovelace, Annie Easley and Amali de Alwis all had to start somewhere!

Sometimes, when I’m trying to work out a new piece of tech, I ask a senior team member how to do something and they reply, “I don’t know”. Again, this has been relatively new to me, the honesty of admitting they don’t know everything. Tech moves so quickly, that it’d be impossible to know it all and my colleagues will readily admit this. This makes me feel like less of an imposter, that everyone is on a learning path, and some people are just a bit further ahead. A mindset of theirs that I’m still understanding, is that though you might not know the answer to this problem, a problem can usually be broken down and logic can be applied to understand each one.
 
I have such an interest in other people’s stories and backgrounds and love seeing programs that are passionate about diversifying the tech area. Tech Returners is a fantastic scheme from Manchester that gives people real skills and opportunities to change careers. Many of their candidates have done extremely well, taking tech roles at Booking.com, AutoTrader and BBC. This shows that even if you don’t come from a traditional tech background, companies can see your talents and want you to work for them.

5. Automation is key
When I first started building solutions on the Cloud, I was told to build things manually. I would spin up an EC2 instance on the console, go through the steps and within about 5 minutes, I would have a new instance. My manager then asked me to create it using Terraform, and next to spin up 5 at a time. Using the building blocks that is Terraform, it took seconds. This is when I saw the real gift that is automation.

When I updated the database as stated earlier, to manually go through nearly 4,000 rows and update the telephone numbers would have probably taken days, using Python to automate the task meant it took minutes.

Friday afternoon, 4pm, I update the Terraform, push to my test environment in Azure. Believing the environment is new, I confirm the plan and so it builds. I then realise, the test environment was created manually in Azure to see if it worked, so I had inevitably just destroyed the database data, the virtual machines and the storage accounts by updating the project name.

Was I becoming a chaos engineer, a destroyer of projects and environments?!

Luckily, my colleague was able to speak to Azure and bring back most of the services. Though I ruined his Friday plans for an after-work beer, he was nice about it, helped me to learn and this error made sure we checked our other environments to ensure this wouldn’t happen again.

So if you’re finding yourself doing something manually, more than a handful of times and it’s becoming tedious, automate! 

6. Get involved in the community
Meetups have been a fantastic way for me to integrate with other people in the industry. There are so many different meetups for different languages, methodologies and experience levels that anyone that wants to be involved truly can be. DOXMAN, has been a great place for me to learn about other companies’ practices, for example, Jennifer Stark recently gave an insight into her role at LADBible at the International Women’s Day event.  

Check out their meet-up page for upcoming events.

Another way to get involved is to give back. Having seen the lack of women in technology, I wanted to get involved in volunteering at a coding course to encourage more women and young people into technology. My manager, Jake, another manager Gary and I decided to create our own 6-week Introduction to Python course. We picked Python as it’s becoming a more and more popular programming language and is an easier language to pick up as it is very readable.

We have delivered the course multiple times, from teaching young people with the Prince’s Trust to teaching a class of 80 women at Manchester Met Uni (MMU). This course at MMU was unfortunately stopped due to COVID-19 so we have decided to take this online and live-stream the course to anyone and everyone that wants to get involved! Though this is a new challenge, I love being able to give back to a community that has supported me on my journey.

7. Say yes!
This industry is great in that it offers lots of opportunities to get involved. My advice is to say yes. Say yes to the things that push you out of your comfort zone. Say yes to the chances, where it would be easier to say no. This was the advice given to me in my first week at work and has so far led me to speaking at DOXMAN, being on the #CALMS podcast and attending AWS Re:Invent in Las Vegas.

All things, I would have been hesitant to do, for fear of not knowing what to say or do and just being too anxious. Having been through it, I can tell you I was definitely very nervous but, in the end, so glad I pushed myself to do these things.

Saying no may have been easier but, these opportunities have made me a better public speaker who is more confident in my abilities.

There you have it, 18 months later and this is what I’ve learnt. I know I still have so much more to learn and that’s exciting. I would also love to hear any of your tips, advice or horror stories from being in DevOps, whether new or not.

Safia Mirza is a DevOps Engineer at KMPG - she is heavily involved in the DevOps Community and is currently running an Introduction to Python Course. If you missed out joining the course originally, you can catch up on YouTube.