Should I hire a Full-Stack Developer?

I’m not the first who feels the need to debunk the “full stack myth” or expose the “full stack lie”, but as trends in the software industry goes, I’m jumping on the “full stack isn’t the right thing for you” train.

What is a full-stack developer?

Let me break down what I expect from a front-end / back-end developer, and then finish with when you should hire a straight up full stack engineer instead of one or the other.

In order of importance:

1. Major Coding Skill: A developer must be able to build maintainable well structured code in at least one framework or language. For example: back-end developers should be very proficient in php/laravel or java/spring or python/django — including databases, caching, authentication and so on. For front-end developers — javascript and react/angular/etc. as well as css and html. This also includes all the goodies — unit tests, design patterns, debugging, optimizations, error monitoring, Secure SDLC, documentation and so on. I will expand later on testing and quality assurance.
2. Minor Coding Skill: A developer should be able to fix, patch, or at least debug code in additional parts of my product stack — this means that front-end engineers should be able to cover up for their vacationing back-end agile buddies by at least confirming that the bug was inserted in feature branch XXX from the last deploy, and they can either fix by changing a CONST somewhere or reverting the code.
3. OPS: A developer should be able to completely set up their own development environment and become fluent in their personal operations. This includes OS, Git, an IDE, build tools, etc. Clearly it is recommended that their own environment be as similar to the production environment. As far as operations is concerned, it is enough for me that the developer understands the CI/CD process, when their code is deployed to where, and what artifacts are created. I don’t expect developers to know how to bring up a Kubernetes Cluster in all three major clouds, but understanding the basics of dockerfiles, jenkinsfile, travis or bitbucketpipelines goes a long way.

So what does everyone else think a full-stack developer is?

Don’t build a product with this.

In my experience, small companies and startups that have a very specific and focused web application usually hire a certain type of web developer that can simply build a SPA quickly and maintain it for as long as the application is relevant. In contrast to the points I wrote above, these are what can be expected from this type of developer:

1. They are skilled exactly enough in each part of the stack (for example — react, express and mongo) to build a functional web site.
2. At best, poor code structure in one part of the stack.
3. Little to no tests.
4. Questionable security.

What I’m trying to say is — if your company is small and starting out, this might be what you need. Keep in mind that down the line, you will have a lot of refactoring to do — when the application grows and cannot withstand more changes or when your team grows and the code cannot be built and maintained collaboratively.

How About Testing and QA?

This is where I get into the most arguments. According to section (1), the developer added unit tests where possible to their code, but what about integration tests or end to end? Those tests that check that your code works well with everyone else’s? Those tests that mimic real life scenarios and run every time you promote your code towards deployment?

(I feel obliged to note that I am strictly referring to writing end to end regression tests that are meant to protect current features from future changes. I still believe in the merit of QA for verifying new features, exploring and challenging new flows and find issues that might not be apparent to neither the developer or the product team behind that developer.)

If you were with me until now, then I would argue that writing automatic regression tests falls under their minor skill, which states that they should be proficient enough to do easy tasks in your automation framework but are not expected to truly build or maintain it. That means that your organization should have a handful of test automation engineers at hand anyway. How do you split the responsibility for writing integration tests between the development team and the test automation team without WW3 ensuing?

My claim is you can’t —and it really depends on how your organization is built — but I plan on continuing this train of thought in a different post.

Finally, I would like to comment that I’ve seen the word “full stack” appear next to new fields in software engineering, for example “full stack BI expert” or “full stack algorithm engineer”. I would be careful with these CV’s or job offers. What is the underlying necessity? Are companies reaching out to the perfect jack of all trades, maverick, ace in the deck? Or are they looking for an employee that is willing to work 16 hours a day and fill 3 positions in the cost of one?

You get what you pay for, buddies.