3 ms·

I think the attraction of "full-stack engineers" is exactly that they're a jack of all trades, mastery optional. They're incredibly useful for smaller companies

I think the attraction of "full-stack engineers" is exactly that they're a jack of all trades, mastery optional. They're incredibly useful for smaller companies that can't afford, or lack the workload, to separately hire serverside, front end, and devops engineers. As you said, most full stack devs tend to have an area they're strongest in, and know enough to be able to hack things together for the rest. As a team, there should be someone with skills in each field that can be utilised to tackle harder problems and for guidance, while simpler tasks can be completed by any team member. You don't need 5 years of experience as a JS dev to add a loading spinner to the UI or 5 years as a Rails developer to add a CRUD endpoint. I like to describe it as being analogous to an infantry squad, you have the machine-gunner, the grenadier, and the designated marksman, but everyone on the team is capable on some level of using a machine gun, a grenade launcher, or a sniper rifle. The important part is to ensure that there are people with enough experience in each area to be able to provide technical leadership and mentoring. If you have a bunch of backend devs trying to hack away at JS and reviewing each others code, with no concept of best practice, you're going to get an amateur end result.

Vinnl 6y ago
> As a team, there should be someone with skills in each field that can be utilised to tackle harder problems and for guidance, while simpler tasks can be completed by any team member. You don't need 5 years of experience as a JS dev to add a loading spinner to the UI or 5 years as a Rails developer to add a CRUD endpoint. The challenge here is that, at least in the front-end (I'm a front-end engineer), it's not so much the case that there are certain problems that are hard and you need help with, but that there are things you should know you're doing wrong, or at least suboptimal. For example, you can add a loading spinner, but you need to do some extra work to make sure people relying on screen readers, for example, know what is going on. After you've implemented a loading spinner, there is nothing that is really pointing out to you that you forgot that. Though I guess the same holds true for the back-end: if I write a really inefficient database query, everything still appears to me as if it worked just fine. Only when it blows up later will it become clear that I lacked knowledge there - and let's hope that I did have enough knowledge to properly instrument the logs. Of course, this isn't necessarily problematic. When you're a small team, getting something out the door that can load data even though the UX for some people sucks is better than not being able to do anything at all. But if you can afford specialists (at least in the sense that e.g. the front-end will typically only be touched by those who are strong on the front-end), you can get higher-quality products.

Vinnl 6y ago

> As a team, there should be someone with skills in each field that can be utilised to tackle harder problems and for guidance, while simpler tasks can be completed by any team member. You don't need 5 years of experience as a JS dev to add a loading spinner to the UI or 5 years as a Rails developer to add a CRUD endpoint. The challenge here is that, at least in the front-end (I'm a front-end engineer), it's not so much the case that there are certain problems that are hard and you need help with, but that there are things you should know you're doing wrong, or at least suboptimal. For example, you can add a loading spinner, but you need to do some extra work to make sure people relying on screen readers, for example, know what is going on. After you've implemented a loading spinner, there is nothing that is really pointing out to you that you forgot that. Though I guess the same holds true for the back-end: if I write a really inefficient database query, everything still appears to me as if it worked just fine. Only when it blows up later will it become clear that I lacked knowledge there - and let's hope that I did have enough knowledge to properly instrument the logs. Of course, this isn't necessarily problematic. When you're a small team, getting something out the door that can load data even though the UX for some people sucks is better than not being able to do anything at all. But if you can afford specialists (at least in the sense that e.g. the front-end will typically only be touched by those who are strong on the front-end), you can get higher-quality products.