A little less than two decades ago, things were simple. Software developers were primarily engaged with developing software end-to-end. There was no major distinction between the people creating the UI, and those developing the backend. Most applications were either desktop monoliths, or desktop “clients” that communicated with some kind of server backend, over the network:

Photo credits: Microsoft

In either case, early development tools provided enough building blocks, for developers to create everything under the same project. This resulted in homogenous, but boring, and unappealingly looking applications. Back in those days, Web was, for the most part, a bunch of static pages, linking to one another. With some eccentric exceptions, most of them resembled the look and feel of their blocky Windows counterparts.

A few years later, during the early and mid-2000s, came the Web 2.0 revolution, which swept everything away. Rather than remaining single-purpose monoliths, software applications turned into distributed “services”. The traditional model of installing hundreds of megabytes on one’s computer, got replaced by typing the URL of one’s favourite web app in a Web browser. With time, the relevance of the underlying operating system diminished. In a little less than a decade, the browser became the OS — for many, the one and only window kept open at all times.

Web 2.0, and the following foray into mobile, forced significant changes, into how the new wave of software applications was supposed to be built. For once, backend and frontend development became separate disciplines, each requiring a different set of skills and expertise. In fact, in recent years, the gap between frontend and backend has become became so huge, that a new discipline has arrived, intended to glue those pieces back together — the role of the full stack developer.

Misconceptions

If you look at job listings nowadays, it seems like just about everyone is looking for developers who can work on all aspects of a project. Many companies call this a “full stack” position, and in fact many organizations already have opened such “full stack” positions across their teams. I find this idea of a “full stack” developer being a “know-it-all” whiz, flawed, and dare believe that relatively few organizations have managed to raise the new role to its full potential. This post tries to shed some light on where the full stack developer should ideally stay within a team, hoping to help dissolve those misconceptions.

There are two very contradicting misconceptions that get tossed around, when it comes to defining what a full stack developer is, and the full stack is supposed to do:

The full stack developer knows a bit of everything, so our company will save on human resources, by hiring a few of them.

or

The full stack developer knows a bit of everything, but nothing in particular. A full stack developer would only be a burden for our team. She would never be able to go into the the level of detail, the way a frontend, or a backend guy would do.

Neither of these is 100% wrong, but neither is correct either. A full stack developer is not a whiz kid, who could magically replace a team of backend and frontend experts. No. Though a full stack developer is supposed to understand both worlds, her role is not to replace, but help bring those two groups closer together. In fact, a good full-stack developer is a bit like the bass player in a rock band:

Flea from Red Hot Chili Peppers. Photo credits: Wikipedia

Full Stack = Bass Player?!?

Playing bass in a rock band is an often underrated, but an incredibly important role. Unlike the vocalist or the guitar player, the bassist takes little credit for her performance. With the exception of jazz and funk music, the bassist rarely does have a prime time on her own. She won’t always pull out a breathtaking solo, the way the lead guitar would do. She also won’t always engage the fans, the way only the vocalist could do. Yet, a good bass player will always be there, gluing the entire band together.

“A bass player is a bit like the mortar between the bricks.” (David Elefson, Megadeth)

Have you ever seen a good rock band with a bad bass player? Or worse, a self-respecting rock band with no bass player at all? No? Well, there are a few good reasons for this:

First of all, there is a huge sound spectrum gap between drums at the low end, and high-pitched guitars and vocals at the other one. This gap is usually filled by the bass. Taking the bass out of the equation, leaves a shallow tune, left of “soul and spirit”. You can still listen to it, but it will always feel as if something is missing.

Having a skilled bass player in the band though, is just as important for the other band mates, as it is for the audience. One of the hardest things in playing in a band, is playing in tune and sync with the others. This is where the role of the bass player as a coordinator and a hub between the players is so important. She keeps the tempo and rhythm set by the drummer at all times, laying out a foundation of the main melody, which stays pretty much the same throughout the song. This allows the guitar player to pull off a beautiful solo, without fear of the sound breaking loose.

Back to the Team

A software team nowadays, looks pretty similar to the rock band, I have been describing so far. You usually have pure backend and frontend developers, covering their own spectra of tasks. If the project at hand is well specified, both sides typically agree on an API and keep doing what they do best, sharing little concern of how the other side is doing things.

As we all know though, very few things in life work in their ideal state. Much of the time, developers spend clearing out the misunderstandings in their communication. They do this at lengthy meetings. If you have been in such a meeting, you know how little respect a frontend guy would pay to your detailed proposals for speeding up the backend. Let’s be honest though, when it comes to frontend guys explaining their problems, it’s your turn to start looking at your phone. That’s just the reality. More often than not, the visions of the two sides deviate, and the only way to bring them back on track are more meetings, and refactoring efforts.