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 dichot...
For further actions, you may consider blocking this person and/or reporting abuse
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 🙂
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.
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!
That I can relate to.
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.
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?
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
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.
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.
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.
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