In my exp. being allowed to focus on code instead of "meta-code" (pipelines, routing etc.) has become a luxury though, and I reluctantly dived into a lot of it because the industry expects non-junior devs to be full-stack at least to some extent.
That's an interesting point. I've actually never understood "full-stack" to necessarily include devops-kinda stuff. Like... I can do frontend (many different JS frameworks) and backend scripting (Node, PHP, VB.NET, etc.), and compiled languages (Java & C#), and I'm really solid with all flavors of SQL. And I've always considered this to be "full-stack".
But I do agree that it can be a luxury to only focus on code. At a certain point, if you're really an experienced dev, it's inevitable that someone's gonna want you to set up these pipelines, or that monitoring package, or this server, or that AWS configuration. And... I can do that. And sometimes I do , indeed, do that. I just... don't like it much. And I'm not terribly efficient at it, because I don't have much interest in learning all the crazy details of each environment and their various tools.
For example, I have a friend who's, like, Captain Docker (nee Kubernetes Man). I have Docker running. And I can spin up a new container and configure it. But you can really get into the weeds on that stuff. And I really hate when I get sucked into the weeds on that stuff.
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.
That's an interesting point. I've actually never understood "full-stack" to necessarily include devops-kinda stuff. Like... I can do frontend (many different JS frameworks) and backend scripting (Node, PHP, VB.NET, etc.), and compiled languages (Java & C#), and I'm really solid with all flavors of SQL. And I've always considered this to be "full-stack".
But I do agree that it can be a luxury to only focus on code. At a certain point, if you're really an experienced dev, it's inevitable that someone's gonna want you to set up these pipelines, or that monitoring package, or this server, or that AWS configuration. And... I can do that. And sometimes I do , indeed, do that. I just... don't like it much. And I'm not terribly efficient at it, because I don't have much interest in learning all the crazy details of each environment and their various tools.
For example, I have a friend who's, like, Captain Docker (nee Kubernetes Man). I have Docker running. And I can spin up a new container and configure it. But you can really get into the weeds on that stuff. And I really hate when I get sucked into the weeds on that stuff.
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.