3 ms·

You confirmed my statement exactly: > You will rarely hear a full stack developer say "I'm unable to continue, because I have to wait for the (dba|integration

You confirmed my statement exactly: > You will rarely hear a full stack developer say "I'm unable to continue, because I have to wait for the (dba|integration team|ops team)". They will solve their problems and often has enough experience to do it well. There are many of us like this who will never take a fullstack role because the reality is, we'd rather work at places that solve that problem by... - properly sizing the integration/ops/db team for example? - setting timelines up so that developers aren't blocked as often? - account for downtime with things like codebase maintenance? It's not like in theory a company can't have their ducks in a row and benefit from a "fullstack dev"... The problem is if they're explicitly looking for full stack it tends to be a negative signal.

brimstedt 5y ago
But it's not a question of "taking a role". It's a question of where your expertise is. You should definitely have proper time lines, that has nothing to do with full stack developers. Downtime? If downtime is an issue for your system, most likely you can build it so it can be live with some parts off and do maintainenance during working hours. (Redundancy, etc) Integration and dB teams, imo, is an antipattern. But what I really did not agree with with your original comment was that managers look for full stack devs because of cost. I look for the right people, and I build my teams with a mix of frontend, backend and fullstack devs. It has nothing to do with cost, it has to do with building efficient and dependentless teams.