We need T-Shaped full-stack developers
There is a train of thought that full-stack is not a good thing and that great developers specialise and work in a single area to become experts.
After all, mastery might be the ultimate goal of every great developer and a successful career means mastery of Android, iOS or Scala to become a specialist.
You can’t be good at everything and deep focus is needed to achieve zen of development. Some people say it takes 10 years to really master C# and the CLR.
It might be true that a lousy full-stack developer is dangerous and does not bring deep knowledge to the table, but it would be a lie to claim full-stack developers are the same.
I have personally worked with both lousy and great full-stack developers.
A lousy full-stack developer is a master of nothing, and he doesn’t know any area of software engineering in sufficient depth. He knows basics of everything and doesn’t have advanced knowledge. He can’t solve hard problems when they arise.
Who is going to solve the hardest problems? Nobody, since you have full-sucks developers in your team.
Don’t be a Full-Sucks developer
A hiring problem
A “Full-Sucks” developer is a big problem in a team, but i believe that it’s a hiring and training problem, because there are many great full-stack developers out there that can solve the hardest problems.
It’s a hiring and cultural problem because a “Full-Sucks” developer is someone that has the wrong attitude and mentality.
A “Full-Sucks” developer is a person that hasn’t invested time into mastery. This kind of developer is just building software that works even if it means stitching NPM modules together into a Node.js app and copying code from stack-overflow while not caring for quality. Making it work is more important than making it perfect.
Full-suck is not a focus and specialization problem, it’s a problem of attitude.
Are all full-stack developers the same? No.
Once upon a time, I worked with a guy that was apt in WPF and Backend and Cloud and DevOps. However, his specialization was WPF, and he was one of the best in the world, proven by the most popular WPF blog on the planet, but he knew very well how to configure a great CI/CD pipeline too.
Actually, he was able to solve any problem thrown at him.
How is that even possible? he was smart and hard-working. He went deep into every problem, regardless of the technology involved. Given the time he would fix the hardest C++ issue.
He was a polyglot programmer that was caring about products and customers, and he took responsibility for the whole codebase.
If your back-end code sucks and your front-end code is beautiful, your total product still sucks. Is your job to deliver holistic products and services or to maintain and defend your area?
Lousy specialists and technical debt
A lousy specialist produces the same outcome as a lousy full-stack developer, and technical debt is not a function of knowledge, focus and specialisation, but a function of team organisation and enforcement of quality through well-designed mechanisms of careful software design and quality control.
Technical debt is also demonised without reason, because we forget that Entropy is a fact of software and every system tends to drift into chaos. Chaos and not order is the natural state.
Technical debt can be managed, but not removed and prevented. Why demonise something that is there, all the time, and it just needs to be properly handled?
There is even a case for actually maintaining a certain technical debt in companies, since caring too much for quality slows down delivery, but that will be a topic for a different article.
Quality is a process and it does not depend on an individual, unless you are an indie developer.
Having a specialist is not going to save your code from drifting into chaos, and that is just wishful thinking. A bad Android developer produces bad java code.
A great developer cares for any code in the codebase and understands that it’s all about teamwork and taking care of the code.
The T-Shaped full-stack developer
There is a special type of full-stack developers that specialise in one discipline but don’t ignore the others.
A T-shaped full-stack developer knows one thing very well and in depth.
He could be an expert in React, Vue or Node.js, but he also knows many other things to be able to contribute across the code-base. He is an adaptable and versatile individual.
A great developer knows his focus, which might be the backend, but can also contribute to the infrastructure or even to the front-end if needed.
Redundancy is good in bad times, and bad times will come.
A high-performing team is a composition of T-Shaped individuals that fill all the gaps in an organization.
Why is this useful? Let’s take a look at typical layered teams and silos, an army of specialists.
Even though the layered organisation is very comforting and it sounds great at first, it is a residue of the dreaded waterfall model.
Every team has clean responsibilities and can master a different area. But is this really what a business needs? separation of roles and responsibilities is common in traditional management but it does have consequences too. Nothing is perfect.
Producing waste and inefficiency
A front-end developer might be useful when there is actual work on the front-end, but what happens when there is no work on the front-end?
What if a dev-ops engineer is on vacation. Who is going to take care of the deployment?
If a backend developer is focused on the server-side, what happens when there is more work on the front-end than the back-end due to the business needs?
Are we going to employ more people since the front-end is under-utilized? what about the back-end developer that is working at 20% of his capacity on the API. He doesn’t do front-end so he might do some random tasks or just watch youtube videos all day.
A layered organization that doesn’t have full-stack developers produces huge amounts of waste over time.
In fact, layered teams are actually silos and they live in their own micro-environments. They are committed to the success of their own layer, and they ignore the rest. Many of the layers don’t care about the front-end, but the reality is that for the customer the front-end is the application. The same applies to front-end and a beautiful front-end with a lousy backend will not deliver value.
Any system is the composition of its parts and even more. How can you design a part of the system and understand all of the implications for the overall system if you don’t understand how other parts are built? Is it sufficient to have a chat with the front-end team? or should you know more to find chances for optimization and improvement?
Silo teams are a DevOps anti-pattern and they shouldn’t exist in any modern software organization. Every team needs at least 1 full stack developer.
According to the theory of constraints, siloed teams are the perfect spot to create bottlenecks and prevent an optimal flow of work across the organization.
Is full-stack really that bad?
Detachment from reality
The lower you go in the waterfall hierarchy of front-end, back-end and devops engineers, there is less contact with the customers, customer feedback and analytics.
Detachment from reality and customers contributes to even more waste, because back-end and dev-ops engineers might end up working on optimisations and tasks that have a very questionable ROI for the business or project they are contributing to.
Refactoring is a task that is very often on the plate, even if it’s not needed.
“There is nothing to do in this sprint, so let’s refactor the code and make it more scalable” — Wasteful developer
The best organisations in the world, including Amazon and Google try to make all teams have as much contact with customers as possible. Why is this? because customers and analytics are the north-star for any product.
Having a back-end engineer look at support tickets, analytics and customer feedback is a good thing, since he would understand the real status and impact of his work, but also real needs of the customers.
Why are you optimizing the DevOps pipeline if the business is having a very satisfactory Deployment frequency and low MTTR and Change failure rate?
You are just wasting time and money.
Maybe you think your role is to have good uptime and low bugs, but that’s not real value, that’s just maintenance of the status quo, and your salary is still a cost and a risk for the business.
The truth is that in every good company there is more work than the team can handle and that work is not distributed evenly across the roles in an organisation and it can’t be. You can’t do always what you want, but you should do what is needed.
Work is dynamic and unevenly distributed across functions in an organisation depending on the business priorities.
You might be better contributing on the front-end where you can bring real value, but the problem is that you are not full-stack and you can’t do that. You are bitching about the lack of work on the back-end and watching plural-sight and doing wasteful refactoring that is not bringing real value.
Isn’t that waste?
Specialisation brings motivational problems
After i worked as a WPF developer for 3 years until 2015 i felt that i was not learning too much.
After some time i realised i was getting diminishing returns in knowledge gains and i felt like i was detached from the trends across the industry.
What usually happens is that a developer in my situation would think that changing the product that he is working on is a good solution to challenge himself, but long-term what happens is big inertia and lack of improvement.
Sometimes bored developers change the area of specialisation.
An iOS developer might switch to Android and a Vue developer would switch to React.
The problem is that even though specialisation is challenging, it is challenging up to some point and then learning and challenge flats out and boredom kicks in.
It’s very unsatisfying to go through the day and repeat the same movements to code on autopilot. It’s the opposite of what neuroscience advocates us to do to increase our mental capacity.
We need to try to do things that are uncomfortable to grow our grey matter.
Isn’t the zen of development to learn all the time and be challenged? T-shaped full-stack development is the ultimate challenge, and the opportunities for learning are endless.
Wrong psychology
Mastering a single area makes sense in academics, but not in production.
In production shit happens across all areas, and it’s very unpredictable.
There is also an underlying psychological challenge in being full-stack and that is the realisation that you need to learn a shitload of things to perform at work.
Our mind and body is programmed to avoid pain and conserve energy, and it’s very painful to get outside of your personal bias and comfort zone and learn more things when you know it’s very painful and time consuming.
However, your resistance to learning and the lack of time doesn’t mean it’s not manageable.
Learning across different areas is a challenge of planning and prioritisation of your learning schedule and making sure that you are focusing on the right things at the right time.
You can learn React and Devops at the same time. It’s just a matter of focus and persistence.
You can be a polyglot programmer. You can be a software version of Leonardo da Vinci.
The case for specialists
Specialists are needed in some situations, and it might make sense to have a dedicated devops engineer or a QA engineer that is focused on very specific things, especially in larger teams and very complex systems.
However, every business should question the value delivered and cost-benefit at all times.
What is the distribution of advanced problems vs normal problems to be solved during a 12-month period? how often do you need specialists in your business to solve problems that a vanilla developer can’t solve? would it be easier hiring a consultant X hours per year to solve those problems?
Specialists might thrive in an academic environment and open-source projects, since they can choose what they want to work on and they are not under pressure from a dynamic business environment.
Specialists were needed to develop protocols, operating systems and drivers, but is that something you are doing day to day? or you are developing business applications and looking for an excuse not to do front-end?
Having a specialist on your team might be useful, but what happens when a specialist is obsolete? technologies change all the time and you need to be careful to pre-qualify on time, otherwise you grow into a Cobol dinosaur in your team.
Conclusion
Full-Stack is the reality of any successful business. Cross-functional teams, feature-teams and similar are the best way to success. These teams need full-stack developers.
Frequent contact with the customer and access to analytics is a way to make good decisions.
Efficiency and utilisation is good. Boredom and wasteful refactoring is not.
Why do you think that a T-Shaped full-stack individual is a bad thing? I don’t think so.
Startup teams might never have layering and specialists, because i want everyone to work very closely with customers and have contact with reality, which often means being close to the front-end, analytics and customer feedback, but also being redundant and efficient to utilise the company budget in an optimal way.
Maybe you are one of the 1% specialists that is really needed in a team, but make sure to question if that is really good for your product/project long-term.
Thank You for reading
If you learned something and want to buy me a coffee or beer — Donate with Crypto
