DEV Community

loading...

Discussion on: The full-stack dilemma

Collapse
scott_yeatts profile image
Scott Yeatts • Edited

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 🙂

Collapse
scott_yeatts profile image
Scott Yeatts • Edited

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.

Collapse
jennrmillerdev profile image
Jen Miller

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.

Thread Thread
mbarzeev profile image
Matti Bar-Zeev Author

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.

Thread Thread
jennrmillerdev profile image
Jen Miller • Edited

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.

Thread Thread
mbarzeev profile image
Matti Bar-Zeev Author

Enjoying something you do is great. Enjoying the work that you do is even better, but enjoyment does not mean professionalism.

Thread Thread
scott_yeatts profile image
Scott Yeatts

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.

Thread Thread
jennrmillerdev profile image
Jen Miller

Very nice comment, enjoyed reading it!

Collapse
mbarzeev profile image
Matti Bar-Zeev Author

That I can relate to.

Collapse
mbarzeev profile image
Matti Bar-Zeev Author

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?

Collapse
scott_yeatts profile image
Scott Yeatts

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.