In the last two year I’ve contributed to the development of Sellf as a full-stack engineer. I worked mainly on the server side (in Ruby on Rails) at the beginning or our adventure, spending more and more time on the client part (in Ember.js) when we focused on the release of our webapp.

In the last months a lot of attention as been brought to the role of an engineer as a full-stack developer (FSD). Techcrunch talked about the rise and fall of the full stack developer, stating that nowadays an FSD needs to be a cross platform dev instead of an end-to-end one. This position has been criticized by some people, whom I agree with, who share the idea that an FSD is a person with a broad range of skills that cover the entire stack needed to release a fully featured app.

A good definition of FSD comes from George Fekete who says that FSDs are comfortable working with both back-end and front-end technologies. This is ok if the comfort-zone not only includes coding but also managing the infrastructure that hosts and runs the app code. Instead, I don’t put in the basket of the FSD skills all the things that concerns UI/UX design, because even if it is determinant for the success of a digital product, it isn’t indispensable for its deployment. I mean, I take into account the UI/UX part in terms of front-end JS/CSS/HTML productions and back-end performances, but I do not strictly consider the ability of design UX patterns or UI elements.

Again, another beautiful definition comes from Laurence Gellert who says that FSDs are good developers who are familiar with the entire stack, people that know how to make life easier for those around them. I quote this definition, because I think that a characteristic of a FSD is to have a comprehension of the whole system. It isn’t necessarily extremely specialized but it has at least the knowledge that can make the difference when a team need clarifications on a topic (either if it’s talking about taking new paths or if there is the urgency of finding solutions that involves different areas). It is like the oracle that can inject trust and confidence, that one who takes the responsibility for a large segment of the product development.

I like the terms “comfortable” and “familiar” because they depict the characteristic of a FSD, novice or not. These are two keywords that I’d use to describe my feelings being a FSD.

So, why I introduced the work “lack” when talking about FSD? When I say “lack” it can be interpreted in two ways. The first one recalls a statement of Andy Shora: The chances of finding a good full-stack developer: LOW. In this post I’m not focused on discussing the meaning of “lack” in terms of the difficulty of finding a FSD, but I mentioned it because it can be considered a consequence of want I really mean with “lack”: the fact that a FSD is useful, if not crucial, in a new-born company – let say a startup – but it is less important, if not awkward, in a SMBs/Enterprise environment.

I think that a FSD is not a good choice when you need to scale but can be necessary when your company is at the minimum viable product or go-to-market level, as it is outlined in the following figure:

Technology start-ups need FSDs first of all because at the beginning they can cut the costs of hiring more people with different skills. They can espouse the motto “buy one get three” letting an employee or founder to develop or improving its own skills as a FSD and to be more versatile. Moreover, the overall management benefits from the fact that in the startup there are fewer people to interact with. I also believe that this kind of role must be assigned to one of the founders, because it is particularly important and because it cannot be easily replaced halfway through. It is normal, especially in an early stage, that all the founders are called not only to do as much as they can but also to work on more than one sector; if we can actually agree that the marketing guy is also the PR one, we can also convene that the back-end developer is in charge of the front-end development too.

On the contrary, when your company grows you need more specialization. You cannot survive with (too) buggy and clumsy code, you know. You slightly move from MVP and beta releases to a working app that your customer expect to be fast and stable, converging to perfection with probability one; while you see your customers increasing, you see their expectations growing too. You cannot avoid to invest time and efforts on refactoring and optimization, considering all the different layers of your app development and deployment. This is particularly emphasized when you need to scale. Scaling means rapid adaptation to the new rules of the game. You need to push your system to a higher level, getting the most and the best from every single line of code (which includes removing the unnecessary ones ;). When you are ready to scale – i.e. when you have to – you need more people with different skills that are able to manage the entire process. It is necessary that each person is dedicated to the development as an amanuensis can do: paying attention to the details, concentrated on a specific part of the entire system.

In a growing company, you need to deep into agile methodologies to boost the performance of your team; you need to cleverly log and monitor all the activities of your application to find expensive queries, failures, bugs, heavy algorithms, unexpected behaviors and so on. Building an efficient logging and alerting system allows your team to find and fix problems quickly.
Moreover you need a specialized person to manage all the infrastructure to cut the costs, because in general you can start using free-tiers of third party services but then you will face the necessity of reducing resources/services consumptions (like APIs calls or loads), whenever you think about replacing these services with your own code. I say, Heroku may not be enough (it won’t be sustainable!) and you’ll better call Saul (which is in our case an infrastructure engineer).
If you didn’t know at the beginning TDD or BDD practices (or your FSD wouldn’t listen about them), you’ll discover that they are as much important as the app code itself. Continuous integration and testing is a must sooner or later.
And what about refactoring? When you look back to your one-year old code you look at it with the same compassion with whom you look at a photo of you a few years before: you wonder how the hell you could get those clothes and have that hairstyle. The reason is that at that time you were a different dev, less skilled for sure, that worked with different (versions of) tools, with frameworks that changed or enriched their structure in the long run. You need a back-end developer that performs the necessary optimizations and stress the convention over configuration to make the growing code more readable and comprehensible.
If you also plan to expose your APIs you have to take into account other several factors, e.g. security and documentation, that can be useful for your internal team too.

The aforementioned aspects are only a few of a series of argumentations that can be brought to support the fact that if on one hand a FSD is a determinant figure in an early-stage startup, on the other it has to devote himself to a specific activity when the going gets tough, collaborating with other (new) people to become a fast growing company.