Brief Progressive Perspectives to Rethink the Full-Stack Developer
It’s not about how many things fit your mind, it’s a mindset
What is a full-stack developer? There are many answers out there. In this article, I propose an individual resignification by exposing some of the usual definitions of the full-stack concept.
The Stack Perspective
It all begins with a typical glossary entry like this:
“Stack” refers to “solution stack”, a set of software components required for an application.
As software engineering layers everything, there are two stack abstractions based on the client-server model: the front end (on the client-side) and the back end (server-side). In simple terms, stage and backstage.
So, while front-end and back-end developers deal with only one-half, full-stack developers dominate all components of a whole stack.
Ok, it’s good when you’re in a hurry.
The Generalist Perspective
Despite the etymology, mastering everything is impossible and full-stack developers just work around this:
“As we cannot be universal by knowing everything there is to know about everything, we must know a little about everything, because it is much better to know something about everything than everything about something. Such universality is the finest. It would be still better if we could have both together, but, if a choice must be made, this is the one to choose. The world knows this and does so, for the world is often a good judge.”— Blaise Pascal
So far, so good.
The Versatile Perspective
The myth of the know-it-all is always close to the full-stack developer. The criticism happens by not discerning between the two. Some say the full-stack developer is just another buzzword and others say: “You call yourself a full-stack and you don’t know that? Pff!”
But, there’s an element of truth here.
In fact, knowing a little about something can give us the wrong impression of expertise — the Dunning-Kruger effect. Being a Jack of all trades, master of none will not be enough, sooner or later.
So, now come the “real” full-stack developers who can hold both together.
The full-stack developers overcome the specialist-generalist tension by keeping both things efficiently together.
For example, I have co-workers who know a lot about Spring and Angular frameworks, but they get by with DevOps, UX, and QA. They’re experts in one or two things but they’re familiar with other stuff. It’s pragmatic.
People like that have already been well labeled: versatilists, or, according to the set of their specialties, the t-shaped, pi-shaped, or comb-shaped professionals.
These people are the future and we can scratch them in charts like this:
Just coaching bullshit?
The Soft Perspective
Graphs for people remind the class of understanding poetry through the Pritchard scale in Dead Poets Society. We need more than two axes to understand the full-stack developer. Rip it out!
Above all, developers are problem solvers.
In fact, the HackerRank Developer Skills Report 2018 showed that 94.9% of employers look for problem-solving skills, more than programming languages proficiency (56.6%), debugging (47.1%), and system design (40.3%).
One reason for this is the interdisciplinarity of problem-solving. Think of it as a master key that can be used across multiple domains.
Well, it fits perfectly with the full-stack developer profile, doesn’t it? But if problem-solving is his soul, then hard skills are only half the story.
No matter which thinking you use to solve your problems, something is always involved:
- Computational thinking, for Google, is supported and enhanced by confidence in dealing with complexity, persistence in working with difficult problems, tolerance for ambiguity, the ability to deal with open-ended problems, and the ability to communicate and work with others to achieve a common goal or solution.
- Design thinking, according to the guys of Virtual Crash Course in Design Thinking from Stanford d.school, has to do with “being human-centered in the way you work” and “having empathy” to solve problems, for example.
- Systems thinking, as described in the book The Fifth Discipline by Peter Senge, needs the disciplines of building a shared vision, mental models, team learning, and personal mastery to realize its potential, as well as what is called a “shift of mind”.
Communication, creativity, humility… Soft skills are clearly related to problem-solving. Only with this complement are full-stack developers complete, a complete person, a fulfilled person with hard and soft skills.
And now we’re talking! That’s it.
If it works for you.
The Ever-Learning Perspective
Everything here was about skill sets. It’s ok. But it’s poor.
Today, full-stack developers are the majority (51.9% in Developer Survey Results 2019), but 15 years ago that was quite different.
It was only from 2009 to 2014 that the front-end developer and the full-stack developer, respectively, gained a growth trend. And that last curve went twice as fast.
Curiously, in a 2004–2014 survey, a major uptick in agile adoption began to occur in 2009 through to full in 2014. It’s easy to link the rise of full-stack with agile. And this is due to organizational changes.
There’s a relation between team organization and software organization.
For example, it’s possible to separate development teams by the software layers (front-end and back-end teams). But, for Martin Fowler, it’s an antipattern.
It’s better if the teams are complete by themselves.
“Developers don’t have to be full-stack (although that is laudable) but teams should be.”— Martin Fowler
This is the proposal of the most used agile methodologies today:
- Scrum teams, according to the Scrum Guide, “have all competencies needed to accomplish the work without depending on others not part of the team”. They are cross-functional teams.
- A primary practice of XP is the whole team: teams have all the skills needed to develop a product. For Kent Beck, “this is really nothing more than the old idea of cross-functional teams”.
- In a brief introduction to Kanban, the Atlassian, owner of Jira and Trello, has dedicated a considerable paragraph to saying that overlapping of skill sets is important to avoid bottlenecks in the workflow.
Cross-functional teams enable much more interesting group dynamics. And individually, it pushes the developer to continually learn more skills. Often, as a matter of survival.
However, this doesn’t mean that skills are more important than people. Quite the reverse: the Agile Manifesto puts individuals and interactions above processes and tools. People have changed.
Gareth Morgan, in Images of Organization, helps us better understand this emphasis by talking about the principle of redundancy in self-organized systems (like agile teams) in the metaphor of organizations as brains.
The redundancy is “a kind of excess capacity that can create room for innovation and development to occur”. It “can be built into the skills and mindsets within an organization”, in two ways, according to Fred Emery:
- Redundancy of parts (many persons per function).
- Redundancy of functions (many functions per person).
It’s precisely the second one that works in agile, in a design that:
[…] encourages people to get involved in the challenges at hand, whatever they may be and wherever they come from, rather than focusing on narrow job descriptions and adopting the “that’s not my responsibility” attitude typical of more mechanistic approaches to management.
This is ownership.
Ownership isn’t just another soft skill, it’s a principle. For Amazon, ownership is one of the leadership principles used to decide the best approach to solving a problem. For full-stack developers, it’s what keeps them moving.
I wrote the words of these five perspectives in a golden ratio to represent progressive thinking. It’s similar to the continuous learning of full-stack developers. Not someone “ready”.
If you’re a full-stack developer or an aspiring one and you don’t have all the skills in the world, remember it’s not about how many things fit your mind, it’s a mindset.
So take ownership and keep moving.