I came from "uhh, I will never touch that frontend thing" to being a passionate full-stack developer.

I'd like to explain why I love it and to encourage other devs to try it. No matter if you are currently frontend or backend-only.

But let's have a quick look on where I came from to give you a change to understand my reasoning behind this. I worked with all kinds of languages but I started my professional career in 2007 as a Java developer, writing software for both embedded and backend systems.

And this is what I did basically until roughly 2017. At that time, I was working in a team consisting of only backend engineers. When there was the need for some frontend work, we had to basically plan this so that one guy from another team would do the work at some time in the future.

Avoiding Bottlenecks

But UI got more an more important and that got more and more of a bottleneck. Actually, nobody really wanted to do it but one member of our team finally volunteered to get her hands dirty and get into frontend after all. Frontend was viewed as both too trivial as as well as too dirty in terms of code quality.

But there we were. We had one frontend dev in the team. And it was quite a success as we didn't have to rely on someone from outside the team. However, also that person turned into a bottle neck in our team pretty quickly when we worked on more than one feature at a time that required UI.

So we knew that something has to change. So whenever we hired someone new, we made sure that person would be already full-stack or at least interested in learning it.

We were working on a product that allowed storing, monitoring and analyzing a lot of data in an industrial domain with a high degree of inter- and reactivity in the web application. In 2017, the existing frontend tech-stack was AngularJS. The code quality was actually pretty bad (as we assumed), the code was neither readable not maintainable. But after some time, Angular with TypeScript was introduced. For me, this looked very much like Java and Spring Boot so I felt at home immediately and were interested in learning it to help achieving our team goal to go fullstack. Also, now beeing more involved, we tried to apply clean code principles and boy-scout-rule every time we touched existing code.

As a result, it was a lot easier for our product owner to prioritize user stories by just business value and not having to think about if the UI and backend devs are available at the same time or even split user stories in non-sensible frontend and backend pieces.

It just worked out pretty well.

Piece of Cake

So remember, I thought frontend development was piece of cake but boy, was I wrong. Building a complex web application with lots of interactive charts, live data and much more was actually a lot more complicated and tough to get into. The abstractions for reactivity in the UI (e.g. rxjs) were hard to comprehend (I still think, that it is not the best abstraction as it is a domain specific language on top of the actual language that you have to learn and understand which is bad IMO). Also styling was tough, tougher than it should be. I always wonder why this is so unnecessarily complicated if you know how you want it too look like and you cannot simply express this with a few understandable steps. We had common components but we needed to build a lot of custom components and thus custom styling was needed.

But let's not get into the specifics here. I guess the web was just not build for applications, I guess. Bottom line is, it took me way longer to get half-way decent. I would still not consider myself as a UI expert but I can get stuff done.

Why it's fun

Now, if you are currently backend-only, you might ask yourself: "Why the fuss?".

My honest answer is: Because it's fun. It is fun in a couple of ways.

First, it is really great to see stuff getting alive that you just built. To interact with your code. You add that button, click it and something happens. As trivial as that might sound, it's just a lot different than what you experience when doing backend only.

Second, it's just great when you implement a feature and you can jump back and forth between front- and backend code. Need to change the model? Just do it! Want to add a field here that makes building the UI easier? Just add it. Boom. No need to ask someone else. No need to discuss APIs, data formats with "the frontend dev", write it down somewhere and then annoying that persone when you need one or two changes. You can also decide, whether it's easier to compute something in the backend or do it in the frontend, depending on the use-case. This is even easier when working with a monorepo containing both backend and frontend.

As full-stack usually also includes operations (or if you like buzzwords: "DevOps"), it is also great if you can just connect to the cluster, because, lets say the dev environement is not working. You look at the logs, fix that DB migration issue quickly to eventually get your new UI feature online and test it. No more waiting for someone to fix it and being blocked.

I think all the arguments are equally valid if you are a frontend dev. It will help a lot if you understand where data comes from, how the data is stored, why there are things that are easier in the backend or vice-versa.

I believe that you end up in writing better software with less compromises.

Jack-of-all-Trades

One downside of going fullstack is that you probably will not be able to have all the knowledge in both width (knowing different technologies) and depth (knowing all details). But, that is not a big issue as you are not the only one in the team. There will we usually be people that like to focus more on frontend, some will have knowledge in the backend, data bases or operations. In our team, we usually work in pairs or a mob, so there is always someone you could ask if you or StackOverflow doesn't know. Having a couple of different T-shaped developers (known a broad number of technologies with one or two focus areas of expert knowledge) in the team works pretty well as for 80% to 90% of the tasks, you don't need expert knowledge.

Also, not everyone in the team might be willing to invest team in expanding their knowledge and go fullstack. That is something that the team need to respect. No one should be forced to do it. One way to get them on board is to regularly pair/mob with them working on stories that require both backend and frontend. That might change their mind.

Tech Stack

As a former Java backend developer, I was used to pretty solid tooling (IDEs, compilers, build tools, debuggers, testing etc.). That changed when learning frontend coding. As web frontend is a much younger profession, slow and fragmented tooling, completely broken dependency management, unstable test frameworks is the result.

Since starting with frontend, I went from JavaScript, npm, AngularJS, Karma, Protractor to TypeScript, yarn, Angular, Jest and Cypress in just one or two years. The backend Java tooling landscape is just a lot more mature and stable.

It's a bit annoying but things are slowly evolving for the better.

Sorry, TDD

If you know my other articles, I am a big fan of testing and Test-Driven-Development. In frontend development, I had to pull-back here a lot more than I want.

I would not say it's impossible but highly impractical to use TDD for all unit and e2e tests. In my experience, there is usually a lot of exploration necessary to get something working in the UI. You have to understand browser behavior, understand how 3rd-party components are working and behaving. So you basically need to build kind of a prototype first. So I end up using TDD for logic code like mapping, services etc but less for component code. Also, I usually write e2e tests (e.g. with Cypress) after getting thing working as the structure and behavior of the UI will usually change drastically during implementation that writing e2e tests upfront is mostly a waste of time. That also means, I need to intentionally break assertions to see if the tests actually turns red if the code doesn't work. And I feel a bit dirty ^^ afterwards.

Conclusion

If you and/or your team mates are willing to try this experiment, you will benefit as you grow your knowledge (and if you think it's important, it might boost you career), the team including a product owner will benefit as unnecessary bottlenecks are removed and the software you work on will have better quality with less compromises.

A Win-win-win situation.

Photo by Karsten Winegeart on Unsplash