Full-stack overflow

Why every engineer should be full-stack

The title of full-stack engineer can be really misleading. So often, I see job descriptions for full-stack engineers that don’t even mention any real backend programming. Very little mention of databases. No mention of backend languages or frameworks (AKA, saying React and JavaScript, but not Node.js). Usually, that means the backend is just using serverless functions for an API. Sorry to say, but that isn’t exactly “full-stack”. Yes, it is hitting a database, but that is just a small subset of most backend development. I know, just because someone’s title says one thing, that doesn’t mean that will end up being their responsibility. It’s just a job description geared towards finding the right individual for the job. It serves its purpose.

With that being said, everyone should be a full-stack engineer, though not necessarily in title or even responsibility. What I mean is that you should understand the full stack. You don’t need to work in it every day, though learning by doing is often the best way to learn. I’ve seen it time and time again. The backend engineer goes off and builds the APIs with no consideration for how that UI will use them. The frontend engineer builds the UI without considering the data model. They start integrating their code together and nothing works. Both of them need to refactor their code, or one of them has to entirely concede to the other’s decisions. You could argue that agreeing on a schema contract up front would solve the problem, but I don’t think that’s always a perfect fix. It absolutely helps, but I think there is another way to prevent this problem.

So many people tell you to “focus on one thing” or “become an expert”, but I’m of a different opinion. I think there is real value to breadth over depth. Understanding more than just one thing allows your brain to make connections between unrelated subjects and come up with new and innovative ideas. Think I’m crazy? There is actual research and real world examples that demonstrate this. Don’t believe me? Then I encourage you to read the book Range by David Epstein. He really makes the case for generalists over specialists, which is where being a full-stack engineer comes in. Being able to understand how the entire application is built will help you make connections between disparate parts of the application and find common patterns. You will see problems more holistically and be able to identify optimizations at different layers. Instead of seeing a problem in the UI and thinking you have to solve it by changing something in state or local storage, you can dive into the database model to identify the real problem (and feel comfortable fixing it). It also helps you expand your knowledge and experience by learning different languages, or at least different frameworks/patterns.

One thing to tangent on here is that I’m really glazing over the responsibilities for a software engineering team. I’m well aware that there are more than just backend and frontend developers. There’s devops, database administration, web designers, solutions engineers, and the list goes on. Generally, most backend engineers have some understanding of devops and database admin work. Often, frontend engineers have experience with web design and building bespoke solutions for customers. Sure, maybe they aren’t the best person for the job, but they can do it without having to hire and train an entirely new employee. Whatever they build may not be the perfect solution, but it will be a good start for a new employee dedicated to that work to pick up whenever you have the capital. Conversely, I don’t personally know a lot of strictly devops focused engineers that could architect and write a whole backend web server (including database modeling, API design, etc). If they could do that, they would probably call themselves a backend engineer who just also had a lot of experience doing devops (or just really enjoyed it). Sure, I’m probably nitpicking on responsibilities here, but I really just wanted to say that while there is more to engineering organizations than frontend and backend engineers, that’s the majority of the industry and what I’m focusing on here.

When you understand the application from CSS to database architecture, you will build higher quality features at a faster pace. Amplify that by everyone on the team having a similar understanding, and you start to really develop great software. People can still have their areas of interest, but not being limited to a single part of the system will create a better system overall. Backed engineers will design better APIs for frontend engineers to consume. Frontend engineers will consider how data problems affect the components they build, possibly finding simpler ways to structure the application. Maybe the backend engineer will have a problem with the database architecture that could be better served with a solution on the frontend. Maybe the state management gets out of control in the React application, but just a simple Redis storage at the API layer would simplify the implementation. To make things even better, when something breaks in the system, anyone will be able to debug it. You won’t have to rely on one person to be available because it just so happens to be in their part of the system. Not saying they need to be an expert in all areas, but having just enough of an understanding will make the overall system better.

Testing is another way this pays dividends. Often, backend engineers will design and test their APIs with a tool like Postman or curl (assuming they are testing beyond unit tests). This is great for rapid testing of the API in isolation, but leaves out how it would work in the frontend code. Maybe it leads to lots of small API calls that hammer the system because there isn’t a bulk option. Maybe the UI doesn’t have access to the data that the API expects and an extra query would slow down the user experience. Sure, this might require the frontend to actually be done before the backend engineer can really test that part, but it is useful. Maybe the frontend engineer didn’t quite understand how a given API call was intended to be used, but they “just made it work”. If the backend engineer also understands how to use the frontend, it makes catching bugs that much easier. Understanding how the APIs and database architectures affect the user experience is a big step towards building a better system.

This is especially important in startups, where you have a limited budget for staff. If you just hire a backend developer, then your UI will look an admin interface. “Okay, then I’ll hire a frontend developer!” you say. That is a bit better, as at least your customer and investor demos will look pretty. But then you need any sort of sophisticated functionality requiring data storage, a third-party integration, or event-driven services, and it takes months for the developer to learn. Admittedly, this isn’t quite the same thing that I’ve been talking about with “just having the knowledge” of how the full stack works. However, it nicely illustrates the point. If either of those developers had some knowledge or experience working on the other side, you would be much better off.

At the end of the day, everything comes down to trade-offs, just like deciding on BFS (bread-first search) or DFS (depth-first search) for finding a node in a graph. Not being an expert in one specific thing may have its limitations. You may end up paying for an off-the-shelf solution that isn’t exactly what you need because you can’t build it yourself (like authentication, which you shouldn’t build yourself anyway). You spend time integrating it and getting it to work for your use case, but maybe that allows you to move faster and focus on the real problems you want to solve. I’m advocating for breadth over depth in most cases. I think that in the long run, breadth will pay off. Not to say that depth can’t absolutely work, but more so that breadth will have a higher chance of success. This might be a contrarian way of thinking, but I’ve kind of always found myself in that camp. Am I alone?