+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.
That is something I immediately noticed. There's no follow up as to whether any of this actually worked. This just seems like a way for management to rationalize understaffing and shift the blame to anything but the lack of adequate staff.
The article paradoxically argues against specialization but then goes on to say generalist must choose a team and specialize in certain team tasks. The entire article just smacks of managerial double-speak that puts employees in a situation that's unwinnable by design while alleviating management of any responsibility for their decisions. Don't specialize enough? Well that's the employees fault. And if they over specialize? Well that's their fault too.
Just hire more people. And if you can't afford to adequately staff your own company, that's your fault not your employees. Your poor management skills is what got you into that situation. You have no one to blame but yourself.
It's so refreshing to be reminded that much of what we're looking at may just be the equivalent of useless self help books. Nobody goes broke oversimplifying problems and selling cheap fixes, and as technologists who have seen the power of technologies to exceed the power of magic, we're vulnerable to believing too much. Churn is not progress, and easy is rarely right.
I can't speak for TFA, but for the team I'm working on, I think the split is going well.
Each of the subteams works on their part of the problem, and works closely with the members of the other subteam when there is overlap. But because the subteams are smaller, the stand ups are a lot shorter, the meetings are fewer and shorter, and we can get more real work done.
I love it when the objection I'm thinking about while reading an article is directly addressed - in this case I was skeptical of the impact on on-call rotation, and then I got to the "shared oncall" section.
