fbpx

Let’s kill the full-stack developerBy Daniel Ávalos

Let’s kill the full-stack developer
Reading Time: 6 minutes

Let me start by asking a question: What does being a full-stack developer mean to you? I’m sure some people will respond with something along the lines of “a developer that can do front-end and back-end work.” Now, let me tell you a story from my point of view.

Even though the beginning of the Internet as we know it started in 1989 with the development of the World Wide Web, it was in the late ‘90s’ when the term “web developer” was coined. And in the 2000s, it was popularized when more and more people started working on creating websites and web applications. Around that time, the titles of web developer and full-stack developer were almost synonyms. The times were simpler, and all you needed was HTML, CSS and in some cases, a little JavaScript for the front end. The back end was similar, the market was dominated, and whether we like it or not, the statistics show it is still dominated by PHP, along with C# and Java for enterprise applications. You could even count with the fingers of one hand the database engines battling for some piece of the market share at that time. MySQL, Oracle and MSSQL were the options.

Surprising as it may sound, 20 years have passed since those times, and we live in a world dominated by software in every industry with many front-end libraries, frameworks and pre-processors; a huge amount of back-end languages and multiple frameworks for each of them; and numerous databases dedicated to specific use cases. But not just that, we now even have new areas for web development and new titles for people working on those areas. It is impossible to be an expert on all those technologies. It is normal, as our industry has evolved, but for some reason, the term full-stack has stayed with us all this time and refuses to go.

Why should we kill it?

Now at this point, you may be thinking, “Hey Daniel! Why shouldn’t we continue using it if it is so sticky?”

Well, here are a couple of reasons that come to mind.

It is confusing… for everyone.

First of all, it’s confusing for developers. There are so many questions! When should we use the full-stack term in our title? Should I use it if I know some front-end and back-end technologies? What happens if I’m an expert in the front end, but I just know the basics of one back-end language? What happens the other way around, if I know the basics of HTML, CSS and JavaScript, and I’m an expert on the back end? What happens if I haven’t had experience with non-relational databases? Are cloud services even considered for being a full-stack developer?

It is also confusing for clients and employers: I already have a front-end developer on my team, and I need some help in the back end. If I hire a full-stack developer, am I not taking advantage of his/her knowledge? Will that developer quit when a new opportunity to use the full potential appears? Why don’t we just hire some full-stack developers and let them decide when to work on the front end and when to work on the back end? Will the wage for those developers be higher?

And finally, it is also confusing for recruiters: I have an open position to hire a full-stack developer in React and Python. Do the candidates need to be experts in both technologies? What about more complex positions like a Vue/Elixir full-stack developer? How difficult is it to find them? Do candidates with those combinations even exist?

Our industry now has clear specialties.

Let’s take a look at other industries, let’s say the healthcare industry, for example. You wouldn’t expect an orthopedic surgeon to perform surgery on your brain, right? You would expect a neurosurgeon to help you because that is the specialty this doctor prepared for so many years. And yes, both of them have the same strong medical foundations, but each one is an expert in their field.

Well, as mentioned before, the software industry has evolved, and now we have front-end developers, back-end developers, database administrators, DevOps teams, web content developers, cloud architects and many more. The same happened to other areas of our industry like design, data or quality assurance, where now there are graphic designers, UI designers, UX designers, product designers, data scientists, data engineers, data analysts, manual QAs, automation QAs and security QAs. And many of those positions didn’t even exist a few years ago!

We need to improve the quality of our work, allow professional growth and keep mental health.

Have you seen open positions like this?

We are looking for a rock star full-stack developer with a great sense of commitment, agility and adaptability, looking for an opportunity to grow.

Required skills:

  • Proven experience with .Net technologies.
  • Strong development skills with Angular.
  • Experience building microservices and microfrontends.
  • Expert with SQL and non-SQL databases.
  • Interest in Scala.
  • Able to set up a CI/CD pipeline.
  • Knowledge of cloud services.
  • Experience with office software packages.
  • Basic knowledge of Photoshop.

So, what’s wrong with this kind of job listing? First of all, there are some typical red flags in the description, like the phrase “rock star,” which often means “you have to be an expert at everything and you will have tight deadlines.” Then we have “commitment,” which means “you will probably be working extra hours.” How about “agility, adaptability,” which means “we don’t have priorities defined, and you will receive a bunch of work that needs to be done ASAP.” And finally, “opportunity to grow,” which means “we don’t have much to pay you, but you will have to learn a lot, and every now and then we will have pizza.” But that is a topic for another post!

The focus of this post is how the list of requirements asks for what we call in our industry “a unicorn”: someone who should know and excel at a list of several technologies. It’s called a unicorn because it’s difficult to find them, but most importantly, if the recruiter finds it and the employer has the budget to pay for it, some consequences could happen within the project. Some examples include the high probability of burnout because this person will be juggling and switching context to accomplish all the responsibilities; the quality of the code delivered will decline since the developer won’t be able to focus on creating good solutions; and it will be more difficult to grow professionally due to having to learn a bit of everything instead of being an expert in one or two technologies.

How can we kill it?

Easy. Pick your favorite weapon and… no, no, wait, come back, I was joking!

Let’s focus on our specialties. Developers should pick one area, specialize and complement it with basic knowledge in other areas. It’s more accurate and realistic to say that you are a back-end developer focused on .Net technologies, and then add more information in your resume about your secondary skills, than saying that you are a full-stack developer.

Employers should understand that times have changed, and having specialized developers will bring more value to their projects, users and businesses in general. Also, it will probably reduce the time it takes for a recruiter to find that developer. It’s more probable to find a candidate that is a Python back-end developer willing to learn some Vue.js and a Vue.js front-end developer willing to learn some Python than to find an expert Python/Vue.js developer. Since the recruiting time is reduced, the employer will have the resources to start building the project sooner, delivering value for the end users and creating new income sources faster.

Let’s evolve with our industry. We need to let the full-stack developer title go and move on. Oh! And put your weapon down — I mean it!