Mobile to Backend: The Big Jump Into My New Developer Life
by Niklas Hösl, Software Engineer Backend
After around seven years on C#, Windows Phone and Universal Windows Platform (UWP) during university and working at Runtastic, I was something of a guru on the platform. As we were a small team of Windows developers, everyone had knowledge about most of the code base. From the database to UI controls to Bluetooth and network communication, we knew what was going on and we worked well together. Everything was fine, apart from one thing: the market share. After even Microsoft didn’t focus on its mobile platform in 2016, I knew that this day would come. I didn’t know when, but I was pretty sure that it would happen for many obvious reasons. Then one day last summer, we were informed that we were discontinuing the development for Windows.
Back then, it was a sad day, but actually, it was a very good and important start of something new. “One life ends, another begins” (from the movie Avatar) is the quote I always think of when remembering that day.
Obviously, I didn’t quit at Runtastic. At Runtastic, we don’t just hire developers, but people. When people fit into the team, why let them go? Developers can learn a new language within a few weeks – changing a person’s attitude is not that easy.
I got the special opportunity to choose any platform or team of my choice. I could start working as an iOS, Android, Backend, Web or JavaScript Developer or even as a Data Engineer without any coding or assessment tests. Great! I thought through the possibilities and decided I wanted a change, a big change. For me, Backend was always the holy grail of development, but it was also a big black box: as a client you send requests, but you never know what’s really happening on all those servers. Also, I heard from many people that Ruby is a fascinating and cool language. I decided to accept the challenge.
I had to say goodbye to my beloved Windows system and start to work on Linux (or Mac) as most of the tools work better there and with that also switch from an IDE (Visual Studio) to a code editor (currently Visual Studio Code).
My new role also changed my mindset. The following three aspects are key lessons that I learned:
1. Be open for changes and see the opportunity
and never think you can’t do it.
Java was the first language we learned at school and at university. Java is also one of the most widely used languages in the industry. My 2009-me also liked Java. But when there are hundreds of programming languages out there, how likely is it that the first one you get to know will be your favorite one? Later I got to know C#. All those LINQ and functional features made me fall in love with this language. Already before my move to Backend, Ruby came to my mind. Its simple and very readable syntax and its extensibility make it my current No. 1 language. I don’t think it’s better or worse than C#, but for the things I’m currently working on, it just fits better.
This does not only apply to programming languages, it’s everywhere in technology: using the tool that fits best over the tools you know. Most of the time, learning something new in the end saves you time compared to adjusting a known tool to the problem, even if it’s hard at the beginning.
Linux users are often bashing Microsoft. I never wanted to be like this. I know where Windows is good and not so good and this also applies to Linux. I still love Windows and Microsoft and I will follow every new announcement, but for now, not as a developer.
2. Automated testing rules
they increase quality and spread knowledge
Times were different at Runtastic a few years ago. Like in many startups, shipping the feature was more important than writing tests. On the Windows platform, testing was mainly done manually by the Quality Assurance team and the developers. Most of the time, this worked out quite well. We implemented features, built the app, deployed it to the phone (or emulator if possible) and verified if it works. If not, we modified the code and deployed it again. One such build-deploy-test cycle often took a few minutes and you always had to test the same thing. This is not only annoying but when changing something, you usually don’t test all possible cases every time. This could end up breaking parts of your system. Also, we didn’t mock anything: when we worked on a UI state that only showed up when a network was available, we needed an active network connection to test it. This also meant that the whole network part had to be fully implemented to work on features that depend on it.
In the Backend, I naively thought that they test their code by manually sending requests to the services. Luckily, this was not the case. The team that I joined is working on the News Feed and had very well-tested services. This helps a lot in getting to know the code base and when you change something you know it does not break anything. Running the tests is always just one click Bash command away and you can focus on something else as automated tests don’t grab your attention while being executed.
When a feature is ready to be merged, it’s time for the code review of the pull request. Here the tests can help the reviewers to grasp your intention about what the code should do and not do. Besides the reviews, the changes are also executed via the tests on the Continuous Integration server to prevent “… but it worked on my machine” situations.
3. Don’t be afraid of the command line
it helps you to understand your tools.
In schools and many universities in Austria, Windows is the main operating system and due to its mainly graphical interface, many people are afraid of the command line at first. While this is no problem for normal users, developers need to know their tools and often they are command-line interface (CLI) based in the end. By pressing buttons (e.g. in Visual Studio), you don’t really know what is executed in the background. This makes debugging errors harder and prevents automating tasks. In Linux, you have many tools that do one thing very well and with small scripts, several tasks can be automated easily and save you lot of time.
Another example is Git: on Windows, most people I know – including me – use GUI clients on top of the actual CLI application. On Linux, I switched to the CLI. The first thing I encountered was that the command Revert (undo changes) from the GUI client TortoiseGit I used is not the same as git revert. Also, those clients often abstract that changes can be staged and unstaged and what this actually means. Learning Git from the command line has, in my opinion, a way higher learning curve and let’s one really grasp how the Version Control System works.
Finally, the command line, of course, makes you faster. With a GUI you may make yourself familiar with a new environment faster, but most of the time, we use the same tools which we usually know by name. And here the mouse can’t beat the keyboard.
So … this is it now?
I have now been working on the Backend team for more than half a year and I really love it. I love Linux and the command line, the Ruby language, writing tests, discussing new features until we come up with the best fitting solution, working with all kinds of databases and tools and seeing our microservice architecture evolve. As a former app developer, one may think that I miss working on the GUI that users enjoy, but creating a well-designed JSON API that makes the clients happy is now even more satisfying for me. Yes, I will be a Ruby Developer in the Backend forever!
Of course not. Things will change – they always do. Maybe in two years, I will be programming in a language I don’t even know today. Maybe there will be yet another revival of Windows or the HoloLens. In the midterm, I could also become a Full Stack Developer for Backend and Mobile. I may change my mind in this and that direction. Everything could happen, but whatever it will be: it will be exciting.
Did you also experience a similar change? How did you deal with it and what were the lessons you learned? Share your story with us and leave a comment below.
***
