In recent years a new skill introduced itself to the software industry - the full-stack developer.
While back in the days there was a clear dichotomy between front-end and back-end developers, nowadays we find more job positions requiring the full-stack skill, where full-stack means mastery of both disciplines.
This new reality got me thinking -
When talking "teams" the first thing which pops to mind is sport. Sport teams are a familiar model we all know and can relate to. We fully understand how teams should work and more so, how each team member's role contributes to the joined effort of gaining the best outcome.
We can all agree that sport teams have evolved across many years to become what they are now, while what shaped them was the end goal of gaining more points and thus winning the game.
The member roles of, say, a basketball team are well defined. Sure, they all are "basketball players" but each has his/her own role in the team. Each knows where to be in offense or defense time and what's his/her part in preventing or scoring game points. The same applies to soccer, baseball, volleyball and the list go on. Each player, while mastering the basic skills of the game, is specialized in a certain role s/he has.
Comparing this model to the software teams model started raising questions in my mind -
We see that more and more software teams are constructed from full-stack/generalist developers, which, if to refer to the sports analogy, means that each member of the team masters all the roles the team requires.
To make the argument stronger, imagine that the striker of a soccer team will be replaced by the fullback during the game and the team's overall game will not be affected whatsoever.
This just does not make sense, right?
Yes, both players know to kick the ball and fully master the rules of the game play, but we also know that fullback is lacking the required skill and experience the striker has and
if the fullback will replace the striker the chances of the team scoring a goal will dramatically reduce.
So how come we feel that the situation and outcome are different when it comes to software teams?
Each skill of a software development role requires immense amount of knowledge and experience. Although many claim to master both front-end and back-end skills (as a full-stack developer) the harsh truth is that it is never the case, simply because BE and FE are 2 different disciplines which require a different set of skills, experience and some might say - different developer's characteristics.
Is it possible that the software industry started taking the team different roles lightly?
Is mastery not relevant anymore in the software industry?
Can a software team made of full-stack developers produce the same products, both in velocity and quality, as a heterogenic team can?
WDYT?
Oldest comments (23)
There is no way around it. If a team consists of only full stack developers who each can process any of the tasks on the product log the result won't be as good as you get with specialists. The tools used by fullstacks are likely to be constructed so that they don't even need to concern themselves with all the specialist issues.
I like to think a bit more out of the box and go beyond frontend vs. backend vs. fullstack, because I would argue in reality a good team needs a variety of personas.
You need a person who supports and listens others. You need a person who get others excited. You need a person who knows what looks good and how to create good looking things. You need a person with taste for small technical details. You need a person who likes the architectures and bigger pictures. You need a person who can make things feel good. You need a person who cares to know the business side of things. You need a person who cares about the customer viewpoint. You need persons who like to push out features. You need a person who likes to refactor and improve. You need a person who likes to write. You need a person who likes to talk. You need a person who likes the organization and stability achievable in the "backend". You need a person who likes the chaos and evolution of the "frontend".
These things mix and match very differently in people and finding someone who can handle it all is very rare, and some of these things do go a bit against each other and there is a limitation of time anyway if one single person wanted to put the effort and excel in being "the most perfect and complete developer persona ever". It is a false individualistic focused dream. The price of remaining great in a variety of skills is to keep using all of the skills. You want people dedicate their life to other things than only being the greatest programmer. Besides not all sorts of persona features are needed in every team.
While the listed person features above can't realistically be all obtained into a single person it makes sense to grow as much into each as possible, because it is valuable to at least have basics nailed as that helps a single person to know where their weaknesses and interests are.
From the perspective of creation of a great team placing people together with various backgrounds each with their different "core focus" is likely to give good results. Let people grow into roles, keep the option open to switch if needed so they can accelerate learning new stuff to avoid staleness, make sure everyone is happy with how they're doing.
Okay this became a slightly odd late night post but I let this be what it has become and just submit it now :)
I totally agree with pretty much everything you've written.
So if that is the case, and the software insustry knows that "full-stack" means compreomising over quality and mastery - does that mean that the software industry is knowingly giving up on quality and professionalism?
each member of the team masters all the roles the team requires.This is actually a misunderstanding. I work full-stack, but I haven't mastered all the roles.
I'm decent, but not great at QA and devops.
My backend is not as great as my frontend, because I started as a frontend specialist.
Full stack doesn't indicate or expect mastery in all things. You still have specialization. It requires an honest assessment of your own skillset and those around you to work to get it done as efficiently as possible 🙂
How come the industry is willing to accept work from someone who declares s/he has no experience in the field? would you let someone who never saw a pipe (but is familiar with some tools) to do your house plumbing? I guess not. So why do is it acceptable in software?
I don't think it is acceptable. The industry might accept it, but at the same time we all started somewhere, and we all should depend on our teammates.
My first backend PR was when I was already a UI Lead. And I asked a million questions of the BE team to make sure I didn't screw it up, had it code-reviewed by the BE team and it went through the same QA process.
That's the same thing that should be happening to each junior, mid and senior BE engineer and the same would happen if a BE specialist issues a PR for the FE.
It's all about teamwork and growth. I wouldn't hire someone with zero BE experience to come in and implement my BE stack, but I wouldn't deny them the ability to learn more about it and grow their skills in a different direction if the team has the capacity or need, as long as everyone understands it's a learning experience.
A few years later I think that person could confidently claim to be full-stack, but I'm not the gatekeeper of when that is.
Side-note: Full Stack is not new and means different things to different people. When I was first coming up full-stack was a goal to achieve, an evolution from the old "web admin" role of the late ninties/early aughts.
Then it turned into a phrase that could be fairly interpreted as "a company that doesn't want to pay for two devs" and now is something that borders on the impossible to developers that started in the age of frameworks and npm libraries... No one should start-out as a "full-stack" engineer, but eventually a lot of us become one out of necessity or curiosity, but they should still have a primary specialization.
That I can relate to.
hmm, though I get what your saying.
I think there will always be a demand for developers that have a general interest and knowledge in both skill sets....but that doesn't mean they are doing two people's job at the same time. They can only do one thing at a time.
Many employers don't necessary need pure specialists in either ecosystem. They just need a team of developers to work on FE and BE tasks as needed.
I think the problem started when companies start looking for people and evaluating them during the interview process as having a high level of in-depth knowledge in both FE and BE at the same time. This processed eliminated people with just FE experience (or those enjoy only FE work), but have enough BE experience to get by their day to day work.
A company which does not require specialists is knowingly putting the quality of its product at risk. That may be fine for new startup which need to get to the market and prove value fast, but large scale companies? I think this says something on the development culture of that company.
hmm, I don't fully agree with the black and white of your statement. I think I would need to see real life proof to back up a statement where "a company produces bad produces unless they only hire FE and BE specialists".
I've been and seen many great places deliver good products but do not have have a divided FE vs BE. Instead, they have a team of people who enjoy and are willing to work on both sides. While I agree I don't think someone without any React experience can design a React UI, I do believe (and have seen) very good React apps built by people who call themselves fullstack.
So I think saying something to one extreme is not correct, because I've also seen poor UI work by FE specialists. I think it's not about the moniker about FE vs BE, but the skills of the developer themselves.
I think the argument is a bit leading too..what I experience is some FE developers don't want to work as BE tasks but are forced to...or have disagreements on how some things should be implemented. Some people hate the term 'fullstack' because in a fullstack world, you can't just work on the parts you enjoy (and I can relate to that). A divided world of FE and BE satisfy those who only want to work on once side or the other....and if a company runs like that, its ok.
But I wouldn't say having a mix of talented devs who enjoy working on both sides is any worse off automatically because they don't have specialist. The skills are there, but distributed across the team.
Enjoying something you do is great. Enjoying the work that you do is even better, but enjoyment does not mean professionalism.
Yeah, I don't agree at ALL that a fullstack team will produce a bad product. An INEXPERIENCED team will likely produce a bad product, so if the company is only hiring engineers that have only ever experienced one side or one aspect of engineering (Say a Java engineer who only learned Java in school and has never touched JS) and expecting them to write FE code, it's not a problem of specialization, it's a problem of experience.
Everyone has a specialty (In my example, that person's specialty is BE Java). But as engineers learn and grow they develop their skills and 3 years from now maybe that new grad is a Python specialist who has had to make a few changes on the FE and knows a little bit more about JS/FE work.
Put that (experienced) engineer on a team with someone that loves building React apps and has learned a bit about APIs in Python and then add a new grad who learned Python at University into the mix and you can expect all three to be able to contribute across the BE/FE divide, but again the new grad would need more mentorship and help with FE, the FE engineer might need mentorship and help with DBs and our Python engineer might need mentorship and help with some aspects they aren't familiar with when working FE stories.
That could be an effective team that does quality work. Everyone has something that drew them into programming (The thing they really enjoy doing/know really well/specialize in), but nothing is stopping them from contributing anywhere in the solution. The key is everyone has to know themselves AND their teammates. Be willing to ask for help and communicate, and that team will work out just fine.
Addendum: When I said "Full stack" was a way to get one person to work two jobs, there WAS a time (Around 2010 - 2015 iirc) when job boards were flooded with people looking for "Full stack engineers" but a LOT of people (in my bubble at least) were complaining about companies wanting to hire one person to do the job of 2 or 3. This was also around the time that the myth of the 10x engineer was being re-popularized and my personal experience was that companies were letting engineers go and not replacing them, then coming back to the team and saying "We can handle this without them, we're all full-stack, right?"
The term got a little dirty around that time for me personally, but it seems to have evolved past that since then.
Very nice comment, enjoyed reading it!
Hi!
I identify with fullstack and not as a specialist in a specific area.
Over the years I’ve worked on both sides frequently, even when there was no dichotomy of backend and frontend.
I’ve always worked on both ends.
Regarding your questions I think you didn’t mention the various stages of companies, projects and teams.
For example, early stage projects tend to need devs that can wear many hats due to limited budget.
On the other hand, having a broad understanding and knowledge about both ends means full stacks can serve as liaison between more specialized teams.
I don’t think any of it is a threat to anyone on any of the “camps”.
I’d say that the most important trait for anyone in any “camp” is to know where their edge resides and work together with their peers to reach the best outcome within the time+budget constraints in place.
Personally, I don’t want to master 3D animation or design. Or database engine implementations. All my career has been focused on web software. That’s what I want to know as much of as possible.
In summary I think most companies need all types of devs and teams need to be hybrid according to the project they’re addressing.
Actually it's the other way 'round. Back in the days (of PHP and Ruby'on'Rails) a single developer could build frontend+backend since it was all done in the same framework (server-side rendering, of course).
But requirements for the frontend increased over time: responsive, reactive, progressive, more beautiful... so the frontend became more complex, thus you need specialists. The same goes for the backend: building an event-driven microservice architecture running on Kubernetes with a fully automated CI/CD pipelines most likely requires more than one specialist.
If someone is looking for a full-stack developer nowadays he/she is basically saying that they don't have sophisticated requirements or they simply don't care. Because expecting a single developer to master all the technologies I mentioned is crazy.
I agree. Both disciplines have become much more complex these days and require more experience and mastery to achieve better quality product
In IT, everything is ultimately market driven. There are just two aspects 1) What the customer wants, and when. 2) How much profit is to be made.
Those that can do the work for the lowest price and highest quality drive the winning model.
We are in global competition. For example I heard once that the top 10% of the best programmers in India represent more people than the entire U.S. programmer population. So that means that the models are set by the largest and best programming teams worldwide. Marketing hype aside, the word gets out on the best models for today.
What's interesting is that with respect to Compositional front and back end techniques, we as programmers should be assembly line workers putting parts together. This means that we should be able to assemble anything anywhere.
Specializations are still needed but focus should be on parts development for the majority of the work to be done. Until this concept is the norm, we'll be continuing to reinvent every wheel required ad nauseum.
Opinion matters much less than perceived need. Those needs are rooted in the current trend of the year. One thing is certain, if we steer our career in the right way following the trends, we will maximize our goals, halfstack or full stack.
Nope. Sorry. I can't regard "Programming" as assembly line work, though I sadly agree that in many companies that is the case.
That's proof to me that the concepts of WebComponents has never taken off. We use all of these super duper frameworks (for front-end) and few are creating reusable libraries. I've been in IT for a long time and this lack of reusable components is a common theme. It's programming as it was 20 years ago.
I think it was uncle Bob who said that every 5 years the developers number is multiplied. That means that every 5 years you get 50% of the developers with less than 5 years of experience. They are bound to repeat the mistakes done before.
I was BE 3 years and 2 years I have been FE, now I can say this article is totally wrong. Coding is a science and every year there can be new languages and frameworks but the principles remain. I personally have bacame an essential member of the team, I am the bridge between both worlds and even sometimes I develop issues that involve both-world skills. The FE is not so complicated as the BE, so after a year and a half you have learnt the most useful concepts of React. BE is a different story, you need skills and knowledge like database managing, hierarchy, functional programming, patterns etc. So I would say, for a BE is easier to become a Fullstack than a FE
hm,
I don't think the term full stack is new, it has been around for a while. In fact, I would say the relatively recent introduction of new powerful front-end frameworks coupled by the rise of coding camps (that lean towards front-end technologies) created a influx of developers with skills in front-end technologies with less 'backend' experience. Those that wanted to focus and differentiate themselves from the sea of other developers started emphasizing the front-end term.
In addition, many new front-end developers seemed irritated that many employers at the time was still were looking for ideal talent with both frontend and back-end skills. This created a backlash towards the 'full-stack' moniker.
Comparing 7 years ago to today, I think today's front-end technologies and its fast past 'may' lean towards specialization but I think there is still a need and demand for developers that can do both and enjoy working on the front-end and backend.