Backend is for Frontend developers
the mindset switch we all need.
There is this silently accepted idea that back-end and front-end are two separate facets of software development, often referred to as server-side and client-side. While this split leads us to create more specialized teams with a focus on specific areas it often comforts us into avoiding things we don’t really want to do, but that is not really the problem. The real struggle appears when we try to integrate the two into a quality-oriented product. Most of the time this is a downside strongly felt in the client as they do the last part, the actual integration.
For a long time, the feeling was that backend developers have always done complex development while the frontend colleagues played with pixels and just made things look pretty.
With both tech stack and user needs evolving so fast, we don’t get to have the luxury to have developers that understand only their part of the app.
The reality though is that JavaScript has absolutely exploded in the last years and a lot of the responsibility went on the front-end part. If in the beginning, we had to deal with some specific pillars in web development: HTML, CSS, Javascript, some preprocessor language, now everything got more complex. We now think about the same problems in the front-end as in the back-end, the separation is no longer valid. The issues we talked about before, being perceived as backend matters (testability, maintainability, persistence, state, even API design) are now the daily debate and work of front-end developers. As we all know, with great power comes great responsibility & a lot of complexity, and this is how front-end developers end up with a strong need for knowledge in the area of patterns, principles, and best practices.
Honestly, this explosion is not giving us the luxury of having excellent frontend developers that only understand one side of the product - “their” part. From patterns to functional programming to reactive abstractions and continuing with architecture best practices, layers get shaped following the same mindset, the way we solve and approach these concerns is pretty much the same on the server as in the client.
If we really look at the product we are about to build from the perspective of a craftsperson we should care about the overview: how the relations between entities are being designed to how the server communicates to the client, having the awareness to differentiate business logic from presentation logic in order to make the best decisions, especially on API design and client state management, and being able to understand how our programs are being deployed and consumed at the end of the day. There should be no problem in my development process that is not MY problem. As long as it involves and affects my work, everything is also my concern. We talk much about team uniformity but we are not able to visualize the whole product the team is shaping and this, in the long run, costs us a lot of resources.
Please don’t fall into the extreme where you feel the rush and stress of becoming the master of the whole stack, but it’s a total game-changer to have an overview on more than just the front-end or just the back-end of the application. Having an understanding of how the two parts interact can help us a lot in optimizing, creating stronger, maintainable, and user-oriented applications while satisfying the business requirements.
One of the facts we have to stop and observe in the context of our projects is: when we talk about data that we receive from the server, are our clients managing too much? If the answer is yes, you know who will suffer from this? Frontend developers, who will become frustrated by not being able to manage the codebase anymore. Or, on the other side, front-end continuously changing needs might interfere with the development experience of back-end developers. Also, the need for refactoring appears way too often in order to gain some control back. This also brings serious complications on the performance side, and you know who won’t be happy about that? Users. This is where you know that you might be doing something wrong, from an architecture perspective but also from the way your team collaborates.
The point is not to dismiss the need for specialists in certain areas or creating experts in everything.
Although, as mentioned, things can get pretty messy, I regularly detect that this “dynamically split team” mindset is strangely and strongly considered. As a full-stack developer, in the first months of switching to only having control over the client-side, I found it pretty frustrating not being able to see what’s behind the curtains and always depending on someone else to do the debugging for me. I knew exactly what I had to do, I knew how to get to the root cause of the problem, and still, there I was, forced by processes, waiting for someone to give me an update.
The point is not to dismiss the need for specialists in certain areas or creating experts in everything. This kind of mindset is damaging and almost impossible, taking into account the speed of today’s technology stack. But switch your mindset a bit, refresh your professional beliefs, and next time you come into an issue before throwing the fireball on the other side of the team just try to understand what is happening, maybe pair with the specialist in the team and try to get an overview. Let go of limitations, stay open-minded.
