The importance of frontend techs for backend developers

By Diego | Software Practices

Sep 16

During the past few years I’ve been working mostly as software engineer focused on the backend side and architecture of the systems I developed. But in the last few weeks I had to get up to speed with some frontend techs that sparked an old flame. How could I’ve been out of this for so long? Today I’m rambling a little about why I think a developer needs to keep in touch with both worlds, with my personal story mixed… and the usual song treat at the end ;)

A little bit of history…

My personal journey in the software development career begins decades ago, back in the days where VBScript was used side by side and, even disputed a place, against JavaScript at the frontend. We are talking about 1999, early 2000. Frameworks? None to be found. I think that word was not even invented at that time… I remember that we used “client side” programming mostly to validate input in forms before sending them to the server.

Anyways… I started programming a long time ago and at that time it was not so clear the separation of roles between frontend and backend developers. We did everything. And it was good. We knew everything that happened in the code and we could control it. Most of the libraries we used at that time were our own packages of reusable code that grew from project to project. We kept our knowledge in sync with the latest language versions and updates.

As time passed by, improvements came at warp speed. Suddenly we no longer had a few reusable self made packages any more, but complete “frameworks” specialized on the client side or the server side code. Frontend and backend development became the common terms to distinguish the two sides of the web development coin. And with the added complexity, we started to specialize. Some of us moved more towards the backend side of things, while others stayed in the frontend side.

Personally I worked actively in both sides for most of my career, and understood the very basics of every framework that came into my hands, backend or frontend. As the saying goes, not because I’m wise, but because I’m old. I understood what the framework devs have done and had to dealt with in order to create those massive pieces of software… just because I’ve been there myself too.

With time my career shifted a little bit, and I started to lead software development teams, where I was more involved in architectural decisions for several projects at the same time and keeping other devs productive. I kept doing my beloved coding, but it was a small portion of my working week hours. And obviously, I couldn’t keep up with everything, so I decided to let the frontend loose :( .

“Architectural decisions”

One of the things that I loved when I was involved actively in the the backend and frontend is that everything falls in the right place. You understand how everything is tied together, how everything works… or it’s supposed to work at least ;). Nothing can catch you off guard.

And this is especially important when you are in charge of the architectural decisions of the software systems you are building. It’s essential that the engineer leading a project have a solid understanding of every piece of it. It might not need to be an expert developer in all of the techs used, but definitely needs to know to work with them. And really important, it needs to understand every tech core principles, how they are applied and what that tech main features are, what problems can and can’t solve.

If, as a software engineer, your focus is solely on one side, backend or frontend alone, you are missing the big picture. You cannot make architectural decisions correctly. If you only know how to use a hammer, you might think that every problem is a nail or solved hammering it out.

Usually when the software teams are big enough to have separate roles for frontend and backend developers, the backend guys are more inclined to be the ones leading the projects and making most of the architectural decisions. I’m generalizing here, so don’t be mad if your case if different, just in my experience, this is what I saw the most.

But frankly it doesn’t matter if you come from the backend or the frontend world. If you want to understand the whole picture and make the correct architectural decisions, you will need to know the other side too.

My last years in the software development world have been mostly focused on the backend side of things, mainly working with Laravel. You know how much I love Laravel, don’t you?  And my beloved framework makes it a little bit easier to work with the current frontend stuff. I came to realize that I was neglecting my frontend knowledge a little too much during these past years when I spent a few moments to see what Laravel was doing in regards to the frontend.

It didn’t take long for me to realize how much the frontend had evolved during these last years behind my back! I’m not going to go into details of what passed under the bridge in that time, but enough to say that I had to spend some dozens of hours updating myself to know where I was standing. Thankfully I did.

Final Words

I don’t what to bore you guys any longer with my ramblings today. I think the idea should be clear by now. Don’t lose sight of what’s on the other side, specially if you are the one that needs to be making the decisions. This also applies to the DevOps / SysAdmin / Infrastructure world too… but this is the topic for a whole new article ;).

I’m not so sure what Phil Collins was thinking when he wrote this song, but I can certainly find some pieces of it and relate them to this story. Congrats if you reach the end, and enjoy your 80’s music treat!

Follow

About the Author

I’m a software engineer and work as an independent software developer and consultant. Software development is my passion. I usually find some time to write in between my work and my other interests, sports and PC gaming!