In this blog article, I share my experience of changing from a frontend developer job to working as a backend developer – from my first learning steps up to my first backend project. Additionally, I will discuss the differences between both sides.
My starting position
In 2016, I started at inovex as a frontend developer. I like to work on the frontend because you build something that you can show to others and that is easy to use.
I worked on multiple projects which started with developing new web pages but after some time it changed to fixing bugs. Many of them were visibility bugs on specific screen sizes or browsers, i.e., fixing HTML and CSS – the least favorite parts I like to work on. Instead, I wanted to write JavaScript/TypeScript, so I decided to shift my focus to the backend as it is more about programming. Additionally, the backend also promised new challenges, concepts and learnings for me.
The journey
Some years ago, I started very slowly, purely out of interest, with different training and courses, like our internal cloud developer training. Here I learned the concepts and the basics of how to build a backend. During this phase, I also committed myself to Spring Boot and Kotlin, mostly because it is widely used.
Courses are a good starting point but they felt like using a happy path with perfect solutions for every task. In real projects, the solutions may not fit that easily and therefore it is more complicated.
So I started a side project, a registration form for a tent camp. I got external requirements and had to find a way to realise them. This raised new challenges and problems I had to solve with Spring Boot. To get the most learning from my side project, an experienced colleague reviewed my code and gave me feedback.
During one of my last projects, I was responsible for the frontend. We were a small team of two developers, one on the backend and one on the frontend. This meant I was the only one who was able to review the backend merge requests. This allowed me to read a lot of backend code and see solutions to real-world problems.
My first backend project
In my yearly planning review, I wished to be placed in a backend project. My wish for the change was granted and when my summer holiday started, I was replaced in my current project. After the holiday I began working on a new project as a backend developer.
The project had been running for six years with different developers, so there was a lot of functionality and code to get along with. And this was the main problem: I had to be cautious when changing one functionality and to be sure not to break another functionality.
Due to the long lifetime of the project, many big architectural decisions had already been made. During the development of a new feature some decisions had to be made, but always as a team, so I was never left alone with a decision.
My next project will be a Greenfield project, so I will be able to contribute to even more decisions.
Differences Between Backend and Frontend
Building Blocks
Being a frontend developer is always about HTML, CSS and JavaScript or some related language. Everything runs in the browser and so these three languages are basic knowledge. All frameworks are built on top of them. So even when you learn a new framework, there is always a lot of knowledge you can build upon.
The backend is much more diverse. There is no common language or framework that all backends being written with. Because there is no default runtime like the browser, many runtimes and therefore programming languages can be used to do the job. Additionally, each programming language has multiple frameworks which means you need to decide upfront which technology you want to learn.
DevOps
The operation of a web frontend application is mostly about serving static files. After the build process, the files only need to be copied to a web server like Caddy or nginx. All code is executed on the client.
Backend code, on the other hand, is executed on the server and therefore is your responsibility. So you have to prepare and run the backend. Additionally, you have to monitor the state of the application and the server itself. An error in your application should not crash the application itself or it should at least trigger a restart. Also, when the load increases on the backend, the performance decreases for all users.
And most importantly, the database is used by the backend, and often backend developers are responsible for running it. While the backend and frontend are stateless, all the state is stored in the database, so this data is crucial for the application.
Finally, the backend performs migrations on the database and is therefore responsible for the integrity of the data.
The Runtime
It is an advantage that all the backend code runs on our servers because we have full control over the runtime environment. We have exactly one environment, we can set it up how we want it and updates can be rolled out for all backends at the same time.
In comparison, the frontend needs to run on a variety of browsers, operating systems and their respective versions since there are people who do not update their browser or OS. This results in a wide range of different runtime configurations with different feature sets and additionally different screen sizes. This is a big source of bugs and requires a lot of customisation.
My final thoughts
The backend and frontend both have their challenges and advantages. During frontend development, you always keep in mind that you interact with the customer. The frontend should be optimised to be used by different people without excluding any of them.
Backend development is much more technical, like speeding up a request.
But for sure there are also many similarities. It is all about finding solutions to problems. Your problems and your toolbox are different but you have to act solution-focused in both domains.
I can recommend my way of learning backend development. The courses and tutorials help to understand the basic functionality of the framework and how to work with it.
But the big improvements in understanding start when you work on a side project. You do not have pressure and can take your time to understand the problem and find a fitting solution. A process that also needs to be done in a real-life project but with less time.
And finally, just do it! Work on a project! There will never be a perfect point in time but you will gain speed and experience much faster than on your side project because you will spend more time and learn from experienced colleagues. You can also choose tasks you feel comfortable with or that are slightly over your experience and get a review from others. Additionally, you can take a look at solutions for tasks you think you would have struggled with.
And, as a last piece of advice, I would recommend you to keep your focus on one thing when you learn something new. Learn backend first and the DevOps topics later. This will not overwhelm you and you will achieve your goals faster.