Imho; a fullstack developer is a person who can develop all pieces of an application (or game, or whatever) and put it in production, maintain it, improve it.
I.e. design the database or other persistence, implement the layers that manages the data, the business logic and the user interface.
It can be very different from different applications, of course, since some may not have an ui, or a persistence requirement.
It is a person who not only knows how to write code, but also understands how code communicates with services and humans.
A fullstack developer understands OS and computing in general.
When I build teams, I like to have a mix of fullstack, frontend and backend developers because the experts (i.e specialized Devs) often handle the nitty gritty details of front- or backend, whereas the fullstack glues together the front-, back- and ops.
Usually fullstackers are the kind of people who say "oh, interesting problem, let's explore" rather than "I don't know this technology, I am a (Fe|be) developer.
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.
> 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.
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.
Imho; a fullstack developer is a person who can develop all pieces of an application (or game, or whatever) and put it in production, maintain it, improve it.
I.e. design the database or other persistence, implement the layers that manages the data, the business logic and the user interface.
It can be very different from different applications, of course, since some may not have an ui, or a persistence requirement.
It is a person who not only knows how to write code, but also understands how code communicates with services and humans.
A fullstack developer understands OS and computing in general.
When I build teams, I like to have a mix of fullstack, frontend and backend developers because the experts (i.e specialized Devs) often handle the nitty gritty details of front- or backend, whereas the fullstack glues together the front-, back- and ops.
Usually fullstackers are the kind of people who say "oh, interesting problem, let's explore" rather than "I don't know this technology, I am a (Fe|be) developer.
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.