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.
Lead Developer, business owner, US Army veteran. I build things for the web. My website is a bunch of HTML pages that didn't need a framework. Yours can be too!
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.
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!