👨‍💻 Taking a back seat, part 1<!-- --> | <!-- -->Building Software Factory👨‍💻 Taking a back seat, part 1

👨‍💻 Taking a back seat, part 1

Reinventing yourself as a back-end software engineer is an intimidating quest. Here is the story of my transition and some tips on how you can make yours happen

In 2018 mobile gaming company I worked for received a grace of long awaited exit event. It was my "dream job", the one I was getting ready for ever since I wrote my first line of code in Turbo Pascal. I was also burnt out, and I couldn't take it anymore. As the modest package of stock options has materialized, I could afford to quit it, take a few months break, make a change.

As a software engineer in mobile games I used to work with Unity game engine. For those unfamiliar, in 2018 Unity still used obsolete .NET Standard 2.0 runtime as its scripting back-end, so while technically I was a C# programmer, practically I felt getting locked in a very narrow specialty of aging programming standard, and I wanted my eggs out of this basket ASAP.

Most of all, I felt like I was missing out on so many exciting things happening in technology. Being able to write a mobile game was cool, sure, but how do I make it multiplayer or how to build a chat system for it? More than that, I was getting curious about building other things than games, like a chatbot, or video streaming server. I wanted to learn about the wonders of GPT and GANs and learn to build something with it myself. And of course, learn how I can share my creations with others. When you created a mobile game, you have rather limited options for that - you either publish it to Google Play or App Store. With the advent of Kubernetes and cloud computing on the back-end and HTML5 on the front end sky become the limit - I've learnt that I could build anything I wanted without the burden of building the physical infrastructure for it nor locking myself into a Google-or-Apple ecosystems.

Reinventing yourself as a back-end software engineer is an intimidating quest though. First, there is a plethora of programming languages to choose from. Choosing tech for a mobile front-end is rather no-brainer. Is it an iOS App? Pick up Objective-C or Swift. Is it for iOS AND Android? Choose React Native. Is it a game? Go for Unity. On the back-end you can choose pretty much any programming language you like, including esoteric ones like Lisp or Haskell. Then there are questions of choosing web framework, persistent storage, CI/CD pipeline, message brokerage and so on and so forth.

After a short research I decided to choose one of the JVM languages as my main back-end programming language. C#, with which I had my most recent programming experience, is a viable choice too, although more dependent on the Microsoft technologies and Windows operating system. I wanted to be able to leverage open source technologies and Linux operating system as much as possible and while .NET Core can be written and deployed on any OS its ecosystem seems to still lag behind that of a Java world. I tried to pick up Scala at first, but I got crushed by the sheer depth of the language. Since I used to work with Java in the past I brushed it up a bit and learnt Spring framework. Eventually I was able to land a back-end programming job in Java. Learning curve was steep, and I still had to spend long hours after work to keep up to speed, but it was totally worth it. Finally, I felt excited about programming again, and almost three years later there is still no end of this journey in sight.

When making a transition, your biggest asset will be knowledge and practices that are common to any kind of programming work. When looking for a job without commercial back-end experience be honest about it and make sure you can demonstrate strong grasp of at least some of the following:

  • Communication skills and software delivery methodologies - your recruiters and future colleagues will be interested in how you organized your work, how you reacted to changed requirements and how you communicated with your peers. Maybe you used to do pair programming, or did pull request reviews. Make sure to put this in your CV and be ready to talk about your experiences with it from the past.

  • Version control system - any kind of code needs a place to live, so you probably worked with git or svn (cvs anyone?). If you only used GUI based clients like SourceTree, this would be a perfect moment to up your version control game. Learn how to use git from the terminal and make sure you can do commit history edits without googling. Know the difference between rebase and merge based workflows. Pick one that you like best for your personal projects and keep using it. As with everything, clean and tidy commit history comes with practice and your future colleagues will thank you for it.

  • Testing - no matter what kind of code you write, it should be well tested. While some types of tests are almost entirely exclusive to back end programming, some of them, like unit tests, can be used to test any kind of code. Familiarize yourself with different kinds of tests and learn when to use them. Get to know what a testing pyramid is and be ready to tell which levels of testing you are familiar with. Learn about tools used to write tests you have never written, or even better - try writing them yourself based on example projects.

  • Profiling - probably you encountered a situation when your code did not perform as well as needed. Be ready to tell about how you found the cause and how you fixed it. Know the difference between different kind of bottlenecks, like when the execution speed is CPU bound, and when it is I/O bound. Learn about which tools you may use when profiling back-end applications.

  • CI/CD - most of the CI/CD tools, like Jenkins, are quite flexible and can be used to deliver all kinds of software. Make sure you know how they work - or even better - get or refresh your hands-on experience with them. If you haven't worked with them before try setting up a simple build pipeline for the personal project yourself.

  • Task automation - if you know how to write bash or Python scripts in order to automate repetitive tasks, it will be more than useful in the back-end programming as well.

There is only so much you can do with the common programming practices during the back-end programming interview. It's also important to learn new concepts specific exclusively to back-end programming. But this is something for another time.