The exponential growth of technologies makes me pretty nervous when I see job ads for full-stack developer positions.
Four of the top five worldwide programming languages are older than the average junior developer I see applying for a job interviews.
Just looking at my career – I’ve mostly worked with JVM-based languages, it went through 13 versions. And I don’t even want to mention framework versions or different libraries I have been using…
What Does the Full-Stack Developer Position Mean?
You can say, why not call them full-stack if they scope it to one or two back-end technologies and one of the mainstream front-end frameworks with state management libraries and UI component libraries?
True, but then you are looking for something other than a full-stack developer. In that case, you are looking for someone fit for your next project. In other words, when I see a full-stack developer position opening, I always think of the well-known catchy phrase:
A jack of all trades, master of none!
Which in most cases is true.
Answering My Own Question
I have found so many different definitions on what being a full-stack developer means and even worse explanations on how to become one. Those varied from defining it as a person knowing the backend and frontend aspects of development to those saying it as someone who could be described as a software architect.
In any case, you are looking for a person with a whole spectrum of competencies. In the case of juniors, interests in that same set of competencies.
More than six years ago, I attended a conference where one of my older colleagues talked about what to expect from Junior developers in a job interview, given the exponential growth of technologies, languages, frameworks, libraries… To that point, I was ignoring the obvious. I hadn’t even thought about how things were becoming complex – I grew up with them. Until I saw the obvious expressed as an exponential graph with big numbers.
But, let’s not concentrate on pure code crunching knowledge. All supporting competencies expected from full-stack developers to know have widened dramatically.
There are many flavors of relational databases; there is a whole garrison of NoSQL databases out there. Deployment processes have changed drastically. Infrastructure has gone from running software on, from bare metal to virtualization, and today to running stuff in a cloud.
There are so many more options today on what to specialize in or what things to do, and not do. What would be easiest, fun, ideal, trending, efficient, or even just looking at what would bring more money?
Whatever lens you take, you can still choose from so many things.
I might be biased now, but looking at the everlasting battle of front-end and back-end development pros and cons from the perspective of a developer, this is what I can conclude:
- The frontend is fun and creative, bringing the results quicker and more vividly. There is so much user interaction, and the feedback is immediate. However, you have to deal with things like browser compatibility. Also, you can’t be too playful if clients’ wishes limit you. In the end, the front end is on the front of everlasting and rapid technological changes.
- Backend makes you a problem solver; you have fun with different data structures and architectures that need to be scalable. There is no better feeling than when you see that pieces fit perfectly in your code or in the design of a whole system. But then, there are so many things to watch out for to make it work. I don’t have to remind you about all those hidden bugs you must find and security risks. In the end, no one sees your work. Everyone is looking at what those front-end guys did from the data you provided.
That is just a start, this main split between Frontend and Backend. If you dig further into different flavors of technologies, languages, frameworks, and libraries…
- I am afraid to bisect backend technologies because there are so many different branches we could talk about. Then, this blog would go in a direction that it just can’t go right now.
These are pure facts; what about real-world examples?
A Full-Stack Notch View
At Notch, we care about the competence and interest of our employees. For this purpose, we have developed a Competence Matrix.
Using the Competence Matrix, our employees can state their knowledge rank in different technical and non-technical competencies. More importantly, they can express their interest in other competencies. Either about those they are proficient in or those they have only read about.
Looking at all the data gathered from Notch employees in our Competence Matrix and then filtering out only employees that stated they have the highest interest in some of the back-end or front-end technologies, 13% have marked only the back-end technologies with the highest interest, while 10% marked only some of the front-end technologies with the highest interest. The remaining 77% of employees have the highest interest in the frontend and the backend. Again, this data filtering is done only on people who have marked technologies with the highest interest, without looking at their ranking for the competency of that technology.
Interestingly, most people have high sympathy for both. Looking at those results, I reflected on myself. It made me realize being a full-stack developer is not about being the best on all fronts. There is no such thing as a master of all trades, especially not today and not anymore.
Full-Stack: Coin Edge between Front-End and Back-End Developer
The thing is, if you are a good developer, you are probably a highly creative person, good at problem-solving, and you have a distinct analytical mind with good attention to detail. At the same time, you are probably a team player and pretty preserved and determined to tackle all those nasty bugs or problems that come under your fingertips.
Ultimately, you love to learn; there is a continuous process of learning new things as you work. And then, there is curiosity about how things work and learning about what is under the hood.
If we add to that a great urge to dig deeper, explore and understand things, it has a natural consequence of you becoming a full-stack developer in the end.
For example, if you are leaning towards the frontend, you have probably scratched the surface of some back-end technologies to see how the things you are presenting on a UI get there. If you are leaning towards the backend, you have probably asked yourself how I can make the data more convenient for the front-end representation.
In reality, it just takes a bit of curiosity and willingness to learn and to dig in further. You become a piece of both worlds.
It is good to be curious; it is good to widen your technology base. Sometimes it gets hard or, maybe at the beginning, even repulsive. However, I have learned that a hard start brought me more knowledge and ideas than staying put in a little warm puddle of mud.
Ultimately, this is a good description of what being a true engineer means.
Don’t Stop Being Curious
While I was thinking about this blog and started writing it on more than a few occasions (honestly, for more than a year now)… I had a lot of different stages, mindsets, and thoughts, from what the full stack developer is now and what it was a decade ago to all those definitions of professionals using letters I, T, X, M, and E.
It has become clear to me now:
I have stopped putting people’s competencies into letter shapes and stopped thinking about how it might have been easier for us a few decades ago.
I would instead paraphrase the analogy of a fully functional system from Russell Ackoff’s lecture he did back in 1994 when explaining supercar assembly. A fully functional system is not just about the best parts put together but more about how they fit together and say:
Being a full-stack developer is not about taking different technologies, both backend, and frontend, and being the best in all of them. It is about being curious about technologies, understanding them, and fitting them together.