5 ms·

I agree with your definition. But I also observe that a lot of companies have trouble coming to terms with the fact that they do not in fact need a FULL stack

I agree with your definition. But I also observe that a lot of companies have trouble coming to terms with the fact that they do not in fact need a FULL stack developer; they might need a front-end dev who can implement the occasional API endpoint themselves. But that person will never touch DB schemas or such. I think Full-Stack has become a term that's too often used by non-technical people. just my two cents

Grumbledour 4y ago
In addition to that, as someone who has worked in web for quite a while I also find it quite baffling that the to me mostly artificial separation of frontend and backend devs has led to programmers who can only do one of them. Sure, everyone has a specialty, but writing frontend and knowing not one line of SQL or how to structure a database or working in the backend but not knowing a bit of HTML or CSS or how to configure a web server, these examples just seem like bad programmers? You don't need to know everything, but surely you should know enough the have an idea of the system as a whole? How can you avoid doing shoddy work otherwise?
- black_puppydog 4y ago
  I personally have very little idea (read: no idea) of iOS & android development. As in, I have no idea what the execution model is there, how the OS libraries/APIs/ABIs are structured, how storage works (sqlite on both I think...?) I trust our iOS & android devs though that if I speak to them about an API and we agree on a specification, that they are sure it can be implemented cleanly & efficiently on their side. But yeah, that requires an abstract understanding of computing as a whole, and good comms. FWIW I wouldn't consider myself full-stack by any stretch :P
- macintux 4y ago
  Front-end work today seems less like "knowing a bit of HTML or CSS" and more like "knowing a bit about these 5 competing front-end JavaScript frameworks" (and that list changes every few years). But that's just the perspective of someone firmly wedded to the backend.
  - ratww 4y ago
    The list of competing frameworks hasn't really changed in a long long time. And often people have to know only one of them to have a very stable frontend career, and 99% of the time it is one of the top 3 (React/Vue/Angular). These 3 have been staples for what, 7, 8 years now?
    - Izkata 4y ago
      What React is capable of hasn't really changed (code from back then will still work), but recommendations in that whole ecosystem have changed so massively in that time it can look like 2-3 different frameworks depending on what era it's from. Angular is a total rewrite of AngularJS, that as far as I know is incompatible with the original (no firsthand experience, going off what I remember others saying about it). It was first released ~6 years ago, while AngularJS's last release was ~2 years ago. No comments on Vue, never used it and I don't hear about it as much as the others.
      - ratww 4y ago
        Angular 2+ is almost six years old at this point too, and the devs who knew v1 still could use it perfectly. And people did successfully migrate back then. And for real: this is "a framework that got a breaking change between major versions". If that’s the worst example we have, I would say the JS ecosystem is doing jolly fine! I've had worst breaking changes in backend frameworks, to be honest. About the other two: like you said, both React and Vue can still run old code, almost unmodified. The track record of those two is way better than most backend frameworks, by miles. It’s not even a fair fight. Sure there's new concepts, but it's not arbitrary stuff or old patterns, it's legitimate stuff that makes writing UIs better. But the old ways are still there too.
  - spyke112 4y ago
    You could make the same strawman argument in the backend world. Backend work today seems less like "knowing a bit of SQL and PHP" and more like "knowing a bit about these 5 competing new programming languages". I find it frustrating when my clients employees actively refuse to dive deeper because they "don't know how/I'm not experienced enough", well, then it's your job to figure it out, that's why they pay you money. As long as most of us are "just" implementing bog standard web frontends and bog standard backends using some sort of SQL, then I find there's no excuse for not being able to pick up the slack, if you're asked to.
ratww 4y ago
In my experience that the frontend/backend separation was something that came out of developers who only wanted (or only knew how) to work on specific areas of the system and got business to adapt to that. Business and non-technical people eventually accepted, but many still long for the days of full-stack devs. And I'm with business people here: coordination between multiple devs is definitely an overhead that impacts businesses and heavily limits possibilities of experimenting and iterating with ideas. The separation is also often a kick the teeth of Agile ("we gotta do the backend before frontend starts") and performance ("just call those 5 endpoints N times, we don't have time to make an aggregated endpoint, should have told us before"). You can still have specialists for micro-optimisations and fine-tuning that SQL query, but the initial implementation phase really suffers from the separation. There's also lots of "prejudice" and pedantry around the term "full-stack", and that's almost always from less experienced developers or students (which is why you don't see it here in HN but see a lot on Reddit), but that's another discussion. It's even worse with developers who had some design training, IME. "Oh you say you had design training but I'm 100% sure you're absolute garbage in either that or in database modelling. Or perhaps in both!"
iamdbtoo 4y ago
Somewhat opposite of that, I find companies also expect full-stack devs to encompass skills that are not developer related. I'm routinely expected to do a lot of product development work in order to define what it is I'm supposed to build.

Grumbledour 4y ago

In addition to that, as someone who has worked in web for quite a while I also find it quite baffling that the to me mostly artificial separation of frontend and backend devs has led to programmers who can only do one of them. Sure, everyone has a specialty, but writing frontend and knowing not one line of SQL or how to structure a database or working in the backend but not knowing a bit of HTML or CSS or how to configure a web server, these examples just seem like bad programmers? You don't need to know everything, but surely you should know enough the have an idea of the system as a whole? How can you avoid doing shoddy work otherwise?

black_puppydog 4y ago
I personally have very little idea (read: no idea) of iOS & android development. As in, I have no idea what the execution model is there, how the OS libraries/APIs/ABIs are structured, how storage works (sqlite on both I think...?) I trust our iOS & android devs though that if I speak to them about an API and we agree on a specification, that they are sure it can be implemented cleanly & efficiently on their side. But yeah, that requires an abstract understanding of computing as a whole, and good comms. FWIW I wouldn't consider myself full-stack by any stretch :P
macintux 4y ago
Front-end work today seems less like "knowing a bit of HTML or CSS" and more like "knowing a bit about these 5 competing front-end JavaScript frameworks" (and that list changes every few years). But that's just the perspective of someone firmly wedded to the backend.
- ratww 4y ago
  The list of competing frameworks hasn't really changed in a long long time. And often people have to know only one of them to have a very stable frontend career, and 99% of the time it is one of the top 3 (React/Vue/Angular). These 3 have been staples for what, 7, 8 years now?
  - Izkata 4y ago
    What React is capable of hasn't really changed (code from back then will still work), but recommendations in that whole ecosystem have changed so massively in that time it can look like 2-3 different frameworks depending on what era it's from. Angular is a total rewrite of AngularJS, that as far as I know is incompatible with the original (no firsthand experience, going off what I remember others saying about it). It was first released ~6 years ago, while AngularJS's last release was ~2 years ago. No comments on Vue, never used it and I don't hear about it as much as the others.
    - ratww 4y ago
      Angular 2+ is almost six years old at this point too, and the devs who knew v1 still could use it perfectly. And people did successfully migrate back then. And for real: this is "a framework that got a breaking change between major versions". If that’s the worst example we have, I would say the JS ecosystem is doing jolly fine! I've had worst breaking changes in backend frameworks, to be honest. About the other two: like you said, both React and Vue can still run old code, almost unmodified. The track record of those two is way better than most backend frameworks, by miles. It’s not even a fair fight. Sure there's new concepts, but it's not arbitrary stuff or old patterns, it's legitimate stuff that makes writing UIs better. But the old ways are still there too.
- spyke112 4y ago
  You could make the same strawman argument in the backend world. Backend work today seems less like "knowing a bit of SQL and PHP" and more like "knowing a bit about these 5 competing new programming languages". I find it frustrating when my clients employees actively refuse to dive deeper because they "don't know how/I'm not experienced enough", well, then it's your job to figure it out, that's why they pay you money. As long as most of us are "just" implementing bog standard web frontends and bog standard backends using some sort of SQL, then I find there's no excuse for not being able to pick up the slack, if you're asked to.

ratww 4y ago

In my experience that the frontend/backend separation was something that came out of developers who only wanted (or only knew how) to work on specific areas of the system and got business to adapt to that. Business and non-technical people eventually accepted, but many still long for the days of full-stack devs. And I'm with business people here: coordination between multiple devs is definitely an overhead that impacts businesses and heavily limits possibilities of experimenting and iterating with ideas. The separation is also often a kick the teeth of Agile ("we gotta do the backend before frontend starts") and performance ("just call those 5 endpoints N times, we don't have time to make an aggregated endpoint, should have told us before"). You can still have specialists for micro-optimisations and fine-tuning that SQL query, but the initial implementation phase really suffers from the separation. There's also lots of "prejudice" and pedantry around the term "full-stack", and that's almost always from less experienced developers or students (which is why you don't see it here in HN but see a lot on Reddit), but that's another discussion. It's even worse with developers who had some design training, IME. "Oh you say you had design training but I'm 100% sure you're absolute garbage in either that or in database modelling. Or perhaps in both!"

iamdbtoo 4y ago

Somewhat opposite of that, I find companies also expect full-stack devs to encompass skills that are not developer related. I'm routinely expected to do a lot of product development work in order to define what it is I'm supposed to build.