How I successfully made the switch to a software engineering role

My journey of transitioning from a software tester to a software engineer. I will talk about the key learnings that have helped me succeed in making the switch.

I have been working at Simply Business for 7 years. For the first 5 years I was a software tester and I had the opportunity to be heavily involved in building our new platform from the ground up.

I then decided to undertake the new challenge of moving to a software engineering role, starting off as a junior.

Now that we’re expanding to sell insurance in the USA as well as in the UK, I have been working on preparing the infrastructure and functionality required for us to be fully up and running across both continents.

Making the move

It was not an easy transition to make for me personally, as it turned out that there was so much more involved than I expected!

Some of the skills as a software tester were easily transferrable such as pairing and coming up with test cases, but I had to learn many new skills and adjust the way I approached problems.

Communication and learning from mistakes

It may seem obvious, but it can actually be really easy to get dragged into a rabbit hole and become isolated. Don’t be afraid to ask for help when you are really stuck, provided you’ve had a decent go at solving the problem yourself first.

Mistakes will happen, but it’s important to not be in constant fear of them. If you make one, take it as an opportunity to learn, and remember – your team knows that you’re learning, and are there to support you.

At Simply Business, we don’t have a blame culture, with the possible exception of “enforcing” doughnuts of shame if you break production (buying treats for the team if you make a big mistake). This really helps to create an environment for growing rather than being stifled. Plus, it’s difficult to feel your shame once everyone’s eaten it!

In short, be open with all teams you’re involved with, draw in the support when necessary, and treat everything as a learning experience.

Pair Programming

Pairing can be a really effective way to improve your understanding, although it may take some time to get used to it. Be prepared to have to use extra brain power and energy – it’ll be tiring at first!

Some general guidelines are:

• remember that constant communication between the “driver” and “navigator” is key to a good pairing session
• swap drivers regularly
• take regular breaks
• when in the driving seat, I found it useful to always explain in detail what you are doing and why. It helps the navigator understand what’s going on, and is a great way to sanity check your work
• it’s fine to say that you’re lost or don’t understand something

For a more in-depth guide, my colleague Regina has written a brilliant set of best practices for pair programming.

More haste, less speed

One issue that I had in the early days of debugging tests was that I’d make too many assumptions and try to jump straight to where I thought the problem was.

Sometimes I was right, but quite often I wasn’t entirely accurate with my assumptions, and that slowed me down a lot more than I expected.

Thankfully, my line manager noticed this and after some discussion we came up with a strategy. After our conversation I slowed down, read the test output from the start, line by line, and made sure I fully understood the problem before attempting to fix it. When starting out I even had a spreadsheet where I’d log the problem and how I went about fixing it.

The same principle can be applied to many different scenarios, and now I always avoid those dangerous assumptions. In some cases my assumption would have been right, but I learnt the hard way that it’s better to be safe than sorry.

Get your problems out of your head

One of the things that made things difficult at the start was that I was trying to fit too much information in my head at once. Unsurprisingly, that made it very easy to get confused!

To some this will seem obvious, but drawing out the issue you’re trying to solve can make a real difference. Whether you go for just a section or the whole problem, having that external reference means you don’t have to hold both the model and your workings in your head at the same time.

I’d recommend one, or a combination of the following:

• keep a notepad with you
• have access to a whiteboard
• use post-it notes
• find an online drawing program, such as draw.io

On top of that, I also use a simple note keeping app to help me remember all the intricate details when understanding a problem.

Ban copy & paste

It was all very well finding a solution to my problems using Stack Overflow or elsewhere in our codebase, but there were times that for whatever reason, I would copy and paste snippets of code without too much thought – I just knew that it was a solution.

My line manager caught onto this and pointed out that it wasn’t good practice, particularly as a junior engineer.

It’s all very well to have a solution but do I really know why it works that way, and understand the implications of using that e.g. is it DRY, does it introduce tech debt, increase a dependency, or is it really the best solution?

By initially banning all copying and pasting and forcing myself to type each character out, I had an opportunity to slow down and think about what I’m actually doing and why.

Self study

Another thing I soon realised was that everyone on my team was constantly learning. Whether this was reading books or blogs, attending meetups, or just putting in the time to practice more, everyone was invested in their growth as engineers.

For me personally, when first starting out I was comfortable with scripting, but not with using OOP in a codebase with many contributors. There were a couple of books in particular that helped me a lot in my understanding of OOP:

• Practical Object-Oriented Design in Ruby by Sandi Metz
• Design Patterns in Ruby by Russ Olsen

Also, learning design principles such as S.O.L.I.D. proved to be invaluable.

That was obviously a lot of theory to learn and remember, so to help me consolidate that knowledge I created a simple Ruby on Rails blog where I would write-up my learnings for each topic. I did follow some generic guides for the Rails blog, but I was surprised to encounter a number of issues when following the steps, so I had to debug and fix things as I went along. It made for more interesting blog posts, at least!

Learning on your own is great, but it can be even more powerful when you learn as a group. It stops you from getting isolated, bogged down in a problem, or giving up when things get tough. So I set up a group with a few other engineers who are learning Ruby. We regularly review and discuss different ruby topics and analyse real world examples in our codebase.

Not only does it help with your own motivation when you’re in a group, but you learn from each other, and encounter problems and solutions that you might not otherwise have come across. Plus there’s always a sense of pride when you’re able to teach as well as learn.

Conclusion

Wherever you are on your software engineering journey, I would recommend having a set of goals that you’re working towards. There will always be challenges along the way to meeting those goals, but know that the journey itself can be more valuable than the destination.

Finally, I will leave you with this quote by Thomas A. Edison:

I have not failed. I’ve just found 10,000 ways that won’t work.