Why I can’t stand the term “full-stack”​ (and why you should probably specialize a little more)

You’ve seen it before. It litters thousands of job boards across the internet. It’s face is visible on every single StackOverflow job opening your slightly outdated Chrome browser has ever laid eyes upon. If recruiters had five favorite buzzwords for 2016, this is certainly three of them. That’s right folks, the term “full-stack developer”.

According to the definition, I am a full-stack developer. I can stand up a full blown web application, from server API to user interface. I can make relatively well informed technical decisions about infrastructure. I can create a blazing fast API to power the logic for my app. I can develop a reasonable user experience for my clients. I have a good understanding of software architecture, so I can create applications that scale effectively. However, even in lieu of all of these abilities, in recent years I have still chosen to focus my efforts and hours solely towards web API development, and I will tell you a few reasons why.

Employers that want it all are typically not good employers

Who would have thought it? Employers with a laundry list of responsibilities they expect out of their employees being bad employers? No way. While this certainly doesn’t apply to every company, there are a lot of shops out there that fall within this category. Perhaps they are on a tight budget, or perhaps they want something out of nothing. Perhaps they’re the typical velvet sweatshop that gave you a long list of benefits to make up for your lacking salary and long list of daily tasks? Whatever the cause, they do not have the resources to pay an expert or a team of experts, so the level of respect given to your role can at times, be questionable.

You are not totally working on all-cylinders

When you are a true full-stack developer, the overall level of commitment you can give to each piece of an application goes down with every hat that you wear. Each sprint feels increasingly like a marathon that you are ending, out of breath, disappointed in the performance you delivered. Full-stack development on an agile schedule leaves you with a feeling of being underwhelmed by your own work. Yes, you may have delivered a piece of functional code, and if you’re lucky that code comes with automated testing, but you were involved in so many varied types of components in the development process that any sane developer would constantly question the stability of his or her own contributions moving forward. Maybe you forgot quality documentation? Maybe you forgot to account for a few edge cases in the API in lieu of a looming UI deadline? When you are developing the full-stack, you don’t get to fully commit your mental resources to creating your best code, which brings me to

Loss of efficiency due to task switching is very real

Having to focus on multiple domains at once during a project slows down our natural work flow. For each additional task you are required to focus on, you can assume that you will lose about 20% of your overall remaining efficiency. Let’s say you are developing an API, a single page web app, as well as doing typical weekly DBA related tasks. With these three tasks alone, you are already down to 51% of your usual efficiency. You may be accomplishing three things at once, but you are doing each of them with just over HALF of your overall processing power. When you focus on one task at a time, you are able to fully commit your mind to engaging the problem at hand which initiates the deep learning process. Full engagement on a problem results in building the best solutions, saving on large amounts of technical debt in the future, and developing quality, scalable code.

While this article certainly doesn’t apply to every shop (or every developer for that matter), it’s important to realize that having mastery of a particular skill or specialization makes you marketable. Having the ability to fully grasp a problem from the perspective of a top level expert will pay dividends in your career down the road. This article is not to say that we should not continue building a diverse skill-set, but rather we should seek to build a set of skills that truly synergizes with our specialization. This synergy could spell the difference between being defined as a mid-level developer, or as a highly regarded software consultant.

%d bloggers like this: