I think the definition of full-stack is relative to being able to set up an app/ tool/ site from A-Z (or from D-Z, depending on what responsibilities the team has). So in a team that manages a Drupal website (front-and backend) on their server but whose connection is proxied through a Varnish server and connects to an externally managed DB, full-stack would be: Linux, Apache, deploy pipelines, PHP, Drupal & front-end.
In a team that manages a bigger-scale Java-backend SaaS, the "full-stack" might include: Linux, ansible, server monitoring tools, database & cache mgmt, and ofc front-end. I know it is common for these responsibilities to be split up at larger scale, but in my current project for example, I am expected to work on all of: frontend (React, SCSS, storybook), Git pipelines, NPM mgmt, Linux (bash, deploys, processes), ansible, Redis, Node (express). It doesn't include database but I would still consider it full-stack.
Yeah, I don't disagree with you, although I think the "definition" is a bit fluid from one job, and one environment, to another. The first time I ever heard the word "stack" used in a tech context was with regard to the LAMP "stack". I'm not a Linux or Apache guru, but I'm definitely comfortable grepping around in Linux and I've done a lot with regard to Apache installations and configurations. And I've, for many years, been extremely comfortable with PHP and MySQL. So, from my perspective, I'm a dev who's very competent in that particular "full stack". I wouldn't tell someone with strong experience in each of the LAMP components that they're not "full stack" just because they don't have, say... Kubernetes experience - although I realize that in some environments, the LAMP stack would absolutely be used in conjunction with Kubernetes.
I've long since gone on to become quite comfortable in other "stacks" - which I often see annotated as A) operating system/environment, B) web/application server, C) programming language, and D) data access language/method. In more recent times, I've been very heavily into the "full" MEAN/MERN stacks. But "MEAN" and "MERN" don't really say much about how the app is hosted or deployed.
As you pointed out, I think the key is that, at larger scales, the entire app pipeline gets split up between teams. At one job, I was working on jQuery/Angular/React on the frontend and on Java/Oracle on the backend. And all of the web services (that I was writing) were required to go through a broker called DataPower (from IBM). I had absolutely no expertise in DataPower. Nor did I need to (or want to), because that was all handled explicitly by a separate team. In that paradigm, DataPower was a critical part of the application infrastructure, that I suppose you could define as being part of the "stack". But I don't think it'd be accurate to say that I wasn't a "full stack" developer there, just because the DataPower aspect was a black box (to me).
Again, I know this is all kinda semantic. I just think it's interesting to ponder the different ways that we all define these terms in our particular environments/experiences. It's useful for me to be more cognizant of these terms because I realize that sometimes, when I say something like "full stack", someone else understands it very differently.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I think the definition of full-stack is relative to being able to set up an app/ tool/ site from A-Z (or from D-Z, depending on what responsibilities the team has). So in a team that manages a Drupal website (front-and backend) on their server but whose connection is proxied through a Varnish server and connects to an externally managed DB, full-stack would be: Linux, Apache, deploy pipelines, PHP, Drupal & front-end.
In a team that manages a bigger-scale Java-backend SaaS, the "full-stack" might include: Linux, ansible, server monitoring tools, database & cache mgmt, and ofc front-end. I know it is common for these responsibilities to be split up at larger scale, but in my current project for example, I am expected to work on all of: frontend (React, SCSS, storybook), Git pipelines, NPM mgmt, Linux (bash, deploys, processes), ansible, Redis, Node (express). It doesn't include database but I would still consider it full-stack.
Yeah, I don't disagree with you, although I think the "definition" is a bit fluid from one job, and one environment, to another. The first time I ever heard the word "stack" used in a tech context was with regard to the LAMP "stack". I'm not a Linux or Apache guru, but I'm definitely comfortable grepping around in Linux and I've done a lot with regard to Apache installations and configurations. And I've, for many years, been extremely comfortable with PHP and MySQL. So, from my perspective, I'm a dev who's very competent in that particular "full stack". I wouldn't tell someone with strong experience in each of the LAMP components that they're not "full stack" just because they don't have, say... Kubernetes experience - although I realize that in some environments, the LAMP stack would absolutely be used in conjunction with Kubernetes.
I've long since gone on to become quite comfortable in other "stacks" - which I often see annotated as A) operating system/environment, B) web/application server, C) programming language, and D) data access language/method. In more recent times, I've been very heavily into the "full" MEAN/MERN stacks. But "MEAN" and "MERN" don't really say much about how the app is hosted or deployed.
As you pointed out, I think the key is that, at larger scales, the entire app pipeline gets split up between teams. At one job, I was working on jQuery/Angular/React on the frontend and on Java/Oracle on the backend. And all of the web services (that I was writing) were required to go through a broker called DataPower (from IBM). I had absolutely no expertise in DataPower. Nor did I need to (or want to), because that was all handled explicitly by a separate team. In that paradigm, DataPower was a critical part of the application infrastructure, that I suppose you could define as being part of the "stack". But I don't think it'd be accurate to say that I wasn't a "full stack" developer there, just because the DataPower aspect was a black box (to me).
Again, I know this is all kinda semantic. I just think it's interesting to ponder the different ways that we all define these terms in our particular environments/experiences. It's useful for me to be more cognizant of these terms because I realize that sometimes, when I say something like "full stack", someone else understands it very differently.