In recent years, we started drawing two separate career paths for developers: front-end and back-end. But we often forget about the third option — full-stack.

Full-stack development has been around for quite a while. It used to just be called “development.”

But due to increasing complexity, our user interfaces are now decoupled from much of the logic behind them. We now have the two distinct worlds of front-end and back-end development.

Let’s explore the idea of full-stack development, and see whether it’s still a relevant option considering all the challenges associated with going down this path.

I work as a full-stack developer at a company called Fortech, and a big part of my job is leading a team of full-stack web developers.

Our team culture is built around the idea that everyone should be able to switch between back end and front end as necessary. We do this based on the needs of the projects we’re working on.

But what is full stack?

Full stack is not specific to web development, or any form of development for that matter.

Full stack means that you’re engaged on every level of a system. You understand the bigger picture, no matter how well-separated the subsystems are.

Today you’ll work on a fancy drop-down menu. Tomorrow, you might have to adjust the API interface for that menu. The day after tomorrow, you might have to go further down to the database to improve the underlying queries your API uses to get its data.

I’ve talked with a lot of people at tech events and noticed increasing skepticism towards full-stack development.

Opponents of the idea say that you need to become highly specialized in a specific sub-domain in order for your skills to remain relevant.

I tend to disagree with this.

I believe that technology will evolve in a way in which it becomes easier for us to stay relevant, as long as we have the right set of skills to start with.

A few answers for the skeptics

Over time, I’ve explained the reasons why I believe full-stack development is the way to go — or at least a very good way.

Question #1: What are the advantages of having a team of full-stack developers?

As a full-stack developer, you can jump from one part of your application to another without significant overhead. This is a huge advantage when planning ahead or when designing new features.

The true value of full stack arises when you’re able to understand the business requirements behind a feature, then take full ownership over its implementation.

Having a team of multidisciplinary people means that you can adapt fast, branching your team when a new opportunity appears.

It’s also something that helps create chemistry within your team. Developers work together longer. Even if a project starts with building an API, then moves to mobile and web clients, the same people can make that journey together.

Question #2: How can I find time to stay up to date with so many technologies and frameworks?

I’d argue that even staying up to date on the front-end or on the back-end is impossible. So let’s push this off the table for now, and focus on what you actually can do.

Any good full-stack developer should start with a well developed core set of skills. You should be able to perform basic tasks: writing a cookie, connecting to a REST endpoint, performing a database query, etc.

You can then build on top of those skills by adding new tools and new abstractions over time.

Staying up to date with the latest tech is not a good indicator of performance. It’s your ability to quickly get up to date as needed that matters.

Question #3: Should a full-stack developer split their work 50–50 between front-end and back-end?

No. You should split your work according to the needs of the project. It’s all contextual, and should be addressed case-by-case.

You need to be able to jump in and perform tasks at any time, on any part of the application. This is especially important in today’s rapid-fire environment of agile software development.

Question #4: Is it ok to prefer one type of development over another?

It’s perfectly fine. Most people will develop a preference over time.

At some point, you’ll start focusing on one of them — and mastering its ecosystem — but without completely losing sight of the other.

I think this should be a matter of personal choice, and should not be imposed upon you by someone else. Some people enjoy doing front-end work better and as a result, get better at it. Others really fall in love with back-end development.

It’s like learning how to use the Force. First you learn how to jump, heal and wield a lightsaber. When you reach a certain maturity you decide whether you’d like to start doing mind tricks or force-choking people.

As far as software development, this is where the analogy to Star Wars ends.

But don’t stop at the code

We tend to think of our skill set as the different programming languages we work with, or the tools we know and use.

But a better way to think of skills — the full-stack approach — is to look at responsibilities you’re able to take on as part of your job.

Can you perform basic user interface tasks, infrastructure setup, and data analysis? Can you get involved in the product development process itself?

My team works closely with our customers. We’ve found that it’s useful to onboard developers into the business process. Once developers understand the problems of our customers, they begin to propose solutions for them.

This way, one person can provide a solution for an existing business problem without the overhead of a traditional silo approach.

I’m not arguing that we should replace all team roles with developers. But empowering developers to be responsible for more than just the code they produce can be beneficial in an agile environment.

This also helps with the high-level mindset shift from solution-focused approaches to problem-focused approaches. You start by identifying the root problem — not just the symptoms — so that you can design an optimal solution to solve it.

One final note

Full-stack development is about stepping out of your comfort zone and performing tasks that are necessary for the success of a product.

There are definitely a lot of good arguments against full-stack development culture, but I hope this article has refuted many of the more common, weaker arguments.

Approaching the full stack won’t always be the best strategy. Many products are too big for any one person to fully understand. For example, Google’s codebase is two billion lines of code. At that level of complexity, various degrees of specialization will be necessary.

Full-stack development should be an approach — not a forced way of thinking.

What’s your take on the future of full-stack development? Share your opinion by leaving a comment below.

If you liked the article, click on the green heart below and I will know my efforts are not in vain.