The mythical Full Stack developer
Reasons to not hire Full Stack developers and to avoid presenting oneself as a such.
TL;DR, Avoid the “Full Stack idea”. As a company you’ll save money, as a developer you’ll save time.
Context
The ideas expressed in this article refer to the development of software applications in a 3-tier architecture:
- Presentation tier: Top level tier, responsible for the User Interface (client). Front-End developers usually implement it.
- Logic tier: It controls the application logic. Back-End developers usually implement it.
- Data tier: Persistency layer, anything related to storage and management of data. Historically managed by DBA (Database Administrators) but I feel, that due to the massive usage of ORMs the Data tier is frequently led by Back-End developers.
A Full Stack developer is someone that could contribute to any of those three tiers at any given time. In this article when talking about Full Stack developers, I’m referring to the group of developers that have a general understanding, but not expertise in each of those three tiers.
There are Full Stack developers that are experts at every layer of the stack, they are rare to find, and are intentionally left out from this article.
Myth
Full Stack developers are a great asset. They can work in multiple if not all parts of the application. So depending on the business needs, these Full Stack developers can contribute to any part of the stack.
If one week the bulk of the work is in the client (Presentation tier); no problem, the Full Stack developer will deal with it.
If next week, the features to be developed demand more work in the data or logic tier; no problem, the same Full Stack developer will deal with them, providing the same level of proficiency.
Life is wonderful. We are a super agile team able to adapt to the market every single week. We are the epitome of the Lean Startup movement.
Consequences
Three to six weeks after those incredible “super agile” weeks, development of features starts slowing down. Features that used to take a sprint, now take more than double.
Every new product idea gets pushback by the engineering team because of some obscure technical reason, that usually involves a framework or database that was great just a couple of weeks back.
Moreover, motivation and confidence within the engineering team decreases.
The honeymoon is over. It’s time to address these structural deficiencies at the next all-hands meeting.
The 5 Whys (Reality check)
- Why does it take so long to develop new features?
Because there are parts of the codebase that get in the way of developing them.
- Why did the codebase get into this state?
Because there were some suboptimal software architecture decisions made in the past that lead to a convoluted implementation.
- Why did we make those suboptimal software architecture decisions?
Because we don’t have architect level experience in that part of the stack. We just chose what seemed the right tool for the job, which was the easiest tool to use. We copy-pasted the “Quickstart” setup, and for any additional questions on how to effectively use the chosen tool, we went to Stack Overflow.
- Why don’t we have architect level experience in that part of the stack?
Because we have a team of Full Stack developers. That makes us very agile, depending on the business needs, these Full Stack developers can contribute to any part of the stack.
- Why do we have a team of Full Stack developers and why haven’t we hired specific expertise for the different parts of our stack?
Because at that time we didn’t know what to hire for. The only thing we knew is that we needed more developers on the team because we wanted to build x new more features. Instead of thinking in advance what specific developer expertise we needed, we decided to hire Full Stack developers, which seemed like a smart thing to do.
Discussion
I’m not sure what came first, companies looking for Full Stack developers or developers presenting themselves as Full Stack. I guess that the former did as a means to cut corners.
In my experience, software developers that present themselves as Full Stack are usually mid-level developers with two distinct profiles:
- Front End developers that have some experience with the business logic tier and the only exposure that they’ve had with the data tier is by working with ORMs.
- Back End developers that know how to write a little bit of Javascript (+ jQuery) and have read a couple React tutorials.
The reason for software developers to present themselves as Full Stack is to increase their chances of getting hired.
Due to the favorable market conditions for senior developers, as mid-level developers gain expertise, they stop claiming they are Full Stack and start presenting themselves as experts on a specific part of the stack.
On the other hand, companies looking to hire Full Stack developers, don’t know what they are looking for. Either because the person responsible for hiring is not able to architect the workload coming ahead or because the workload is not even defined.
Conclusion
It’s understandable for both sides (developers and companies) to be seduced by the “Full Stack” concept, but it may have negative consequences in the mid-long term.
For developers
Don’t waste your time.
As a mid-level developer, you should look for the best environment to gain expertise at whatever layer of the stack you choose to specialize in.
It’s OK to use the “Full Stack” concept to increase your chances of being hired, but when that happens, make sure that the team has enough expertise at each layer of the stack. If not, sooner than you imagine you’ll be in a room full of overly motivated mid-level developers discussing architecture solutions that none of you have ever implemented. You’ll be wasting much precious time without realizing it.
For companies
Don’t waste your money.
Full Stack developers look very appealing on paper, but the devil is in the details. Be aware that these developers may inadvertently make suboptimal architecture decisions that will increase the technical debt. The company will have to deal with it in the immediate future.
Addendum
Is there a time to hire Full Stack developers?
Yes, whenever there is going to be a team of one developer managing the entire application.
Beyond that, the company would be better off by hiring experts or at least developers just focused on one part of the stack.
Is this important for companies?
Hiring specialized engineers early on is only relevant for companies that being operationally efficient is one of their top priorities.
Most of the companies around the world know that operational efficiency is critical for their survival. However, in the Bay Area, the most crucial priority seems to be raising a massive amount of money.
If you work on one of those super well-funded companies, then your company has much, much more time to figure this out and by hiring experts, someone will probably come in and solve the issue.
If you work or have a small/medium revenue grown company, then operational efficiency and focusing on hiring experts in each layer of the stack as soon as possible proves much more cost-effective on the mid-long run.
Building the system
Building the right engineering team is vital to the success of a software-based company.
In this case, building the system means understanding the technical expertise required by your company and hiring accordingly. There are 10x developers out there, but they’re not the Full Stack mid-level ones.
Inspiration
- All that glitters is not gold. The mythical man-month.
