Fullstack is not a myth

I will prefix this whole post by stating that this, like all other conversations on this subject, is an opinion and is based off of anecdotal evidence.

Nearly every weekend there is some sort of big discussion on Twitter, and the weekend just gone, it was about the term "Fullstack", with some claiming that the Fullstack developer does not exist.

This main complaint seems to be coming from a section of the front end community. Their main grievance around the term fullstack, seems to stem from an impression (again, this an opinion held by some people) that fullstack developers have not done a good job of developing for the browser. We often see sites that do not need to be single-page apps, developed as single-page apps. In fact, only yesterday, I came across a technical blog that was built this way. It was downloading a few hundred kilobytes of JavaScript just to deliver a trivial blog post to the client.

This is a case of the wrong tool being used for the job - a blog does not need to be a single-page application. A server side framework or a plain old html file with the content already present would have done a far better job. It would have loaded quicker and would have been a lot more accessible. But a few examples of this does not mean that the fullstack developer does not exist.

Most of the teams I've worked on has been a number of developers that have been employed as fullstack developers. As with all teams, there is a different range of competencies and skills across the team. For example, one of the developers might be more knowledgeable than the other developers about back end data access. Another may be more knowledgeable about CSS3.

The key in these teams has always been around collaboration and knowledge sharing. When we create a pull request, we anticipate feedback from our team mates. Given that they have a diverse range of competencies, we can expect that our team mates will suggest improvements in areas that we may not have considered. In doing so, they are spreading some of their knowledge.

This of course is not the only vector for knowledge sharing - pairing will also inevitably happen in a team of developers like this.

The silo does not work

The opposite to the fullstack developer is a chain of siloed developers. In place of one developer, you might have:

• A database developer
• An API developer
• A front end developer

So now, when we need a single feature developed, we need to get three developers aligned on what the requirements are, or we have a 4th lead developer there to break the work down and spell all of the changes out for the developers. The lead developer ironically needs some fullstack knowledge.

Having worked on teams where the developers were much more siloed, we often encountered integration problems at the boundaries. The front end developer may pick up their part of work only to find out that the API developer hasn't included a particular field that the front end developer was expecting. Rather than the front end developer quickly making a change to the API, the work now needs to go back up the chain, and the front end developer is now blocked.

Conclusion

There are plenty of competent fullstack developers out there that read documentation and are eager to deliver the best experience to their end users. Team collaboration, access to training, and a good spread of skills can help to achieve this. Strong technical leads can help to put this in place, and stop any skillset skew from degrading the in app experience.