Fullstack developers are hurting the industry

Dave Rivera
6 min readMar 12, 2018

Platforms are getting bigger and bigger every year, as well as their complexity. Claiming, in our current times, that one can master both front and back end is really bold. It’s so hard to keep up solely with the front-end that not even Eric Elliot is keeping up. Keeping up with the advances in one technology is hard enough, and almost impossible to keep up with two of them, specially if one of them is Javascript. By being a well versed back-end developer and stating that one can master Javascript and the front-end completely, or as good as a specialized front-end developer, is one of the greatest fallacies our industry has ever seen.

Time and time again I see job listings asking for fullstack developers, and it makes me think who in those companies is creating that kind of requests, ‘cause no experienced developer in their right mind would ever do such a thing. I say this due to many conversations I had with experienced and specialized front-end and back-end developers, and I keep hearing the same conclusion: Being a fullstack is utterly impossible.

It really bugs me too that these kind of developers are often categorized higher than specialized developers just because they’re “experts” in both arts, sometimes just as tech leaders but sometimes even as architects just because they claim knowing both. I mean, it’s true that one has to have knowledge on both ends to be a leader or even an architect, but most of the times companies overlook the experience and expertise by hearing these magic words: Fullstack Developer. I’ve seen great developers with not only lots of experience and knowledge in front-end, but also with a wide grasp of back-end (and vice-versa), being disregarded due to the fact of not lying about their scope or focus, by not claiming they’re fullstack but instead saying they’re specialized in one end, when they very well could be claiming they’re fullstack, because they’re not liars.

Why do Fullstack developers exist?

Well… this is fairly simple: Cheap companies.

Is true that within our profession, hiring a developer (no mater their forte) is expensive, and sometimes even overpriced, that’s why companies created the term fullstack, or masters at everything (as some of them like to be called), but is more like experts at nothing, and know-some-things-about-development.

Companies believe that hiring a developer to do everything is gonna save them some big bucks, and that’s true… partially. If a company is building a simple MVP and can’t really afford having two senior developers (back-end and front-end) then yeah, having a fullstack dev is the best they can do. Now, let’s define simple: An application with but a few pages, not heavy on style, a couple of forms, just the necessary data processing exposed through a RESTful service to be fetched via ajax, no frameworks on the front-end side, SQL database, and that’s it; roughly 2 months of development for a single person. Now, that’s a simple app.

Reality is quite different, and way too shocking to be honest. Companies hire fullstack developers to create really complex applications when they should be hiring specialized back and front developers, resulting in unmaintainable code bases, longer development and more expensive than what was foreseen.

In my country, we have an slang for big fat liars, “buque”, that’s spanish for vessel. This buques (vessels) try to convince the naive of what they can achieve, by lying through their teeth. Problem is that when a vessel sinks it drags along everything that’s near. Imagine a big military vessel, the ones that carry planes on top of them, that’s what fullstack developer is. Every time they say they can do this or that “feature” picture a jet being loaded in, up until there’s too much weight over the vessel that it starts sinking ‘cause it has limited capacity. We all know how governments feel when one of those ships sink, is not a pretty picture. All the money lost by adding planes (features) after it sunk, plus the plane, is the same as companies will feel when the apps are all buggy and unmaintainable, and adding a new feature will take over a couple of weeks. But, to be honest, that’s what they get for being cheap.

For the past two years I’ve been exposed to more fullstack developers than ever, and let me tell you, 100% of the front-end code they write needs to be re-written (and I’m not exaggerating… really! I’m not!). And, within this special kind of breed, I’ve encountered the most arrogant developers I’ve ever met, dunno if it’s just a really uncomfortable coincidence or is somehow related to them being fullstack developers… I like to think it is not the latter. Take this case for instance: I used to work in an Angular project and a fullstack pushed a PR, when I did the code review I suggested that we shouldn’t use for loops and opt for using map instead, and specially not using for(i) loops when we were by no means writing mathematical code to be writing i, j, or k all over the place; that it made it harder to understand, specially if the rows and columns are being iterated and then, within those nested loops, more rows or columns were being iterated… see how hard it is to even explain? This was his response:

Completely disagree. for’s are incredibly readable, but prefer a foreach over c-style. The map function can be unreadable for more complex operations.

If data is being mutated a map is as readable as it can be, it’s a explicit function, ‘cause it tells us two things: Data is being mutated and the mutation is pure (with special care to the nested objects mutations, of course). That is clear to anyone who knows JS or functional programming, it’s not that clear, however, to someone who only cares about OOP and ignorant the entire plethora of existent programming paradigms. But that’s not all, another problem arises: What if the data changes its size? How is the for loop looking now? What happens if there’s a million results? A map can handle this without a single line being changed, plus it can even be performed in parallel (well… not natively, but it’s possible) without much work put into it.

Maintaining Fullstack developers code: Welcome to Hell

Have you ever maintained a Fullstack developer’s code? No? Well… let me welcome you to the tenth circle of hell, as if Dante were to write a modern version of the Divine Comedy I’m pretty sure he’d include it.

Be prepared to spend countless hours reading through code and trying to figure out how on earth they could have done such atrocities, that is if you can actually decipher it instead of re-writing it yourself, ’cause it’ll be your first instinct against such an evil hex that was cast upon you. Within these atrocities one can find: Using JQuery to manipulate the DOM whilst using React (because they saw a post in stackoverflow on how to grab an element by its id using JQuery), creating for loops to iterate over arrays with impure data mutations, tons of callback hells, infinite levels of indirection, deep classical inheritance (because we have the fancy not-so-new class feature :), and it can be extended), and many more bad practices.

What can we do to stop this?

We as developers, both back-end and front-end, need to stop requesting for this kind of developers and start valuing specialized developers. If there’s a real need to hire a fullstack developer because money’s tight at the moment, there are plenty of great specialized developers who are willing to work for half of an USA fullstack’s salary (which could well be around 12 grand USD) outside of USA, and it will yield to not only a maintainable software but it will also help improve other countries’ finance, such as third world countries.

To developers who wish to become fullstack developers… please don’t. You people are far more valuable as specialized developers on either side; there’s plenty of gaps to be filled in the industry such as data mining, artificial intelligence, IoT, distributed systems with broker messaging on the back-end side; single page apps, hybrid applications, progressive web apps, and many different languages with multi-paradigm support on the front-end side. But this is just the tip of the iceberg, the deeper it goes the more complex it gets. Focusing in just one subject is how strong knowledge is forged, that’s why masters and doctorates are focused on a single subject, rather than trying to understand everything

--

--