@bytebodger this article resonates a lot with me, especially the parts on timed exercises, nomenclature mismatches and dev-ops. 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.
From the part on "Nomenclature mismatches", is it safe to suppose that you are in big part self-taught? I've witnessed such between uni grads & self-taught (=me) devs. The former learn the concepts upfront, the latter by encountering them in existing code.
I find that React is also responsible for a lot of 'nomenclature confusion', as the React team loves to re-appropriate/ repurpose patterns and name them differently, which tricks devs into believing it is something unique to React. I wonder how many devs are aware that HOC's are higher order funcs, and "render props" are just callbacks that happen to return DOM elements. I don't know who chose to call it Hooks in React, but it doesn't conform to what is understood under Hooking in programming at all.
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.
The former learn the concepts upfront, the latter by encountering them in existing code.
Bingo. Whenever I'm introduced to a new concept in coding, I'm inevitably confronted with some sort of online documentation. And that's great. So I read through it for about... 30 minutes. That's usually sufficient to give me a (very high level) understanding of what the concept does. But if I'm to truly learn the concept, I need to quickly transition into trying to play with it. I gotta install the package or try to use it in some existing code. I have to find a way to make it useful. Because, if I don't, it just sits in my brain as some sort of esoteric, abstract concept.
the React team loves to re-appropriate/ repurpose patterns and name them differently
This isn't a unique problem to react though; a similar thing is the concept of "tree shaking", and how it tricks many beginners into thinking this is some super-high-tech thing that's unique to javascript, when in reality, dead code elimination has been around since forever.
Everywhere you look, developers make up new names for known tools or use known names for different tools. Sometimes they even do both at the same time (aka. they get their terminology wrong).
This definitely doesn't make IT easier to navigate for newcomers and self-taught people, but to a large extent we could counteract it by spending a bit more time clarifying our use of terminology when we explain concepts.
Also, obligatory: "a monad is a monoid in the category of endofunctors, what's the problem?"
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.
@bytebodger this article resonates a lot with me, especially the parts on timed exercises, nomenclature mismatches and dev-ops. 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.
From the part on "Nomenclature mismatches", is it safe to suppose that you are in big part self-taught? I've witnessed such between uni grads & self-taught (=me) devs. The former learn the concepts upfront, the latter by encountering them in existing code.
I find that React is also responsible for a lot of 'nomenclature confusion', as the React team loves to re-appropriate/ repurpose patterns and name them differently, which tricks devs into believing it is something unique to React. I wonder how many devs are aware that HOC's are higher order funcs, and "render props" are just callbacks that happen to return DOM elements. I don't know who chose to call it Hooks in React, but it doesn't conform to what is understood under Hooking in programming at all.
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.
Bingo. Whenever I'm introduced to a new concept in coding, I'm inevitably confronted with some sort of online documentation. And that's great. So I read through it for about... 30 minutes. That's usually sufficient to give me a (very high level) understanding of what the concept does. But if I'm to truly learn the concept, I need to quickly transition into trying to play with it. I gotta install the package or try to use it in some existing code. I have to find a way to make it useful. Because, if I don't, it just sits in my brain as some sort of esoteric, abstract concept.
This isn't a unique problem to react though; a similar thing is the concept of "tree shaking", and how it tricks many beginners into thinking this is some super-high-tech thing that's unique to javascript, when in reality, dead code elimination has been around since forever.
Everywhere you look, developers make up new names for known tools or use known names for different tools. Sometimes they even do both at the same time (aka. they get their terminology wrong).
This definitely doesn't make IT easier to navigate for newcomers and self-taught people, but to a large extent we could counteract it by spending a bit more time clarifying our use of terminology when we explain concepts.
Also, obligatory: "a monad is a monoid in the category of endofunctors, what's the problem?"