Hum... That's a tricky subject. While I aknowledge your points I guess it really depends on what your company is producing.
I completely agree if your company has tightly coupled backends and frontends (a web service per web site). In that case having a "full stack team" implementing the cultural points you gave makes complete sense.
That being said, I think that this tends to be less and less common. You can be in a situation where you have to develop/maintain a web service accessible by the end user throught both a website and a mobile app. In this situation I don't see how you could get an efficient "full stack team". The frontends technologies vary too much. I would probably go for three independant teams and some people acting as bridges to synchronize all the efforts.
As you might have guessed I have mostly been in this second situation. That's probably why, without any context, I don't understand this meme as criticism for the developers and rather see it as a criticism of companies/recruters who are only interested in "full stack developers" even when this requirement doesn't match their needs. Thus they end up with apps that are perfectly illustrated by this meme because the developers they hired, as "full stack" as they are, do not master the specific frontend technology they had to use. I'm probably wrong with this interpretation but that's definitely how this meme resonates with me.
Thank you for the thoughtful, measured response. I think the second case (the separate UI and API teams) works best in the case of a product that is heavily API focused, like traffic data, weather data, analytics etc. and those companies tend to monitize their APIs. But if your company is selling a tool as opposed an API, then I tend to favor the “full stack team” so the whole team can focus on getting value to the user instead of having conference calls about the value of “separation of concerns.” I see that all the time at the companies I’ve worked at and it’s a big sign that the team division is hurting not helping. When those teams have reorganized, the work is completed faster. And I don’t think the separation of concerns or the architecture suffers too much.
But I hadn’t thought about native mobile UIs like you mentioned. It is a real problem to source talent in Swift, Java, and JS/TS. So yea you’ve got me thinking now.
Maybe it works sometimes but not all the time?
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hum... That's a tricky subject. While I aknowledge your points I guess it really depends on what your company is producing.
I completely agree if your company has tightly coupled backends and frontends (a web service per web site). In that case having a "full stack team" implementing the cultural points you gave makes complete sense.
That being said, I think that this tends to be less and less common. You can be in a situation where you have to develop/maintain a web service accessible by the end user throught both a website and a mobile app. In this situation I don't see how you could get an efficient "full stack team". The frontends technologies vary too much. I would probably go for three independant teams and some people acting as bridges to synchronize all the efforts.
As you might have guessed I have mostly been in this second situation. That's probably why, without any context, I don't understand this meme as criticism for the developers and rather see it as a criticism of companies/recruters who are only interested in "full stack developers" even when this requirement doesn't match their needs. Thus they end up with apps that are perfectly illustrated by this meme because the developers they hired, as "full stack" as they are, do not master the specific frontend technology they had to use. I'm probably wrong with this interpretation but that's definitely how this meme resonates with me.
Thank you for the thoughtful, measured response. I think the second case (the separate UI and API teams) works best in the case of a product that is heavily API focused, like traffic data, weather data, analytics etc. and those companies tend to monitize their APIs. But if your company is selling a tool as opposed an API, then I tend to favor the “full stack team” so the whole team can focus on getting value to the user instead of having conference calls about the value of “separation of concerns.” I see that all the time at the companies I’ve worked at and it’s a big sign that the team division is hurting not helping. When those teams have reorganized, the work is completed faster. And I don’t think the separation of concerns or the architecture suffers too much.
But I hadn’t thought about native mobile UIs like you mentioned. It is a real problem to source talent in Swift, Java, and JS/TS. So yea you’ve got me thinking now.
Maybe it works sometimes but not all the time?