+1 for specialization, in my experience working on a fullstack team is significantly more painful than having a specialized role. Of course it’s partially because you have to learn a bunch of stuff, but I’ve also found that fullstack teams tend to have poor planning, e.g. it’s structured as fullstack to constantly fill gaps in a not well defined project / roadmap. Fullstack is good experience if you want to do your own projects / startup, but not a peaceful job.
Maybe underestimating how different people can ramp up in different parts of the stack, or underestimating the context switch, or the amount of glue between the different parts of the stack.
You're not wrong, but the root issue is that most of the time the team are not actually full stack devs or they are full stack devs that haven't worked in a team.
There should be no context switch if you're full stack.
The context is the feature you're implementing. It involves backend, frontend and ops, and assuming you're actually full stack there is no 'mental switch' between those, the feature is still the same.
Devs that aren't actually full stack are the ones that require a mental context switch between backend/frontend/ops and this is where the issue is.
My first question to a full stack dev is ask them to outline the steps involved for a feature that requires all of these. The way they will answer and describe the flow will give you all the information if they are actually full stack or a frontend dev with backend experience.
Full stack devs are rare, I'd say to become one requires at least 5 years experience working actual full stack, a position that usually only solo devs get to experience. Solo devs lack the team experience and that's the other part of the problem.
Full stack devs that can work in a team are holy grail territory.
Which is why the most important thing after you find a true full stack dev is to focus on teaching them on how to work in a team.
> There should be no context switch if you're full stack.
I’ve always considered myself full stack but I’m currently struggling pretty hard with parts of the codebase written in OCaml. There are challenges that are unlike others, so I don’t think it’s a good idea to generalize.
