6 ms·

Question: at what point does "specializing" in one or the other make you not a "full stack" developer anymore? I can technically do about everything on the web

Question: at what point does "specializing" in one or the other make you not a "full stack" developer anymore? I can technically do about everything on the web, I'm just really bad at front-end, and really good at back-end, which is where I do most of my work. Am I "full stack"? How good to you have to be in...well, everything, to call yourself "full stack"?

chipmonkey75 4y ago
I think this is the flavor of question that should be asked, tho I'd go further. For one thing, I've always really loathed the phrase "full stack" - if you've ever written a UI that has to drive hardware that requires assembly level firmware, built a CI/CD pipeline to run tests, build artifacts, manage infrastructure, update firmware and send it all out into the world, you _might_ be "full stack", for everyone else it's just a colloquial term for a web front end and a database API developer. But I digress. Even in the common context, to be Full Stack, I'd argue that you should be better than the sum of the parts. The lift you get from being able to decide, intelligently and at the speed of thought (without talking to a counterpart on the other end), which pieces of code - optimization, safeguards, business logic, etc. - belong in the front and back end, and how they interact at peak effectiveness, is more valuable than just the ability to build a good API or build a good web page. Further, a full stack engineer, in my experience, is more likely to reach for tools like websockets, memcached, etc. earlier in a project than typical REST APIs (for example) where the line between back- and front- end require a bit more coordinated architecting, to achieve a richer end result. But I doubt this is widely accepted. Anyway, my point is I wouldn't focus on either just because; I'd focus on what makes you better by knowing some of both. What can you learn in the back-end to support problems you're familiar with in the front-end, and what can you do in the front-end to make better use of your knowledge in the back-end? That's where full-stack value really lies.
dec0dedab0de 4y ago
This is a good question. as far as front/back end I think it's probably just good enough to mostly get it working right without breaking anything too often. But what I think really makes it front end is also when you have some server/platform administration skills. You would be surprised how many web developers don't know about tab complete on the shell, or have no idea how DNS works.
- dec0dedab0de 4y ago
  But what I think really makes it front end I meant to say what really makes it full stack, but it's too late to edit
alexfromapex 4y ago
To me, full stack means you're not "really bad" at FE but more like intermediate to advanced at FE and BE. Over the past few years, full stack is becoming more involved with devops, data engineering, and machine learning too so there's now different levels of full stack in my opinion.
throwaway2016a 4y ago
Full stack allows a single dev to "own" the whole ticket. It's great for startups but not so much at larger (or even medium sized) companies. If you're "really bad at front-end" I would say: not a full stack. If you can't own a ticket end to end and create a front-end that is at least comparable in quality to a dedicated front-end developer then you are just a backend developer. Similar to how I know some mobile dev but wouldn't call myself a mobile app developer in a million years. With that said, I have interviewed a lot of people and full-stack is such a buzzword now that probably 2/3 of the people with it on their resume are in that boat. (good at one level of the stack and just a passing knowledge of the others) I have had recruiters tell me so many times: "Oh, I found this awesome candidate, they're a full stack developer!" only to find there idea of full stack is they know how to add a border to a div with CSS or they are a front-end wizard but their only backend knowledge is SQL.
charlie0 4y ago
My own personal definition of Full Stack Dev is similar to the term one man army. It means I can design an app, do the front end, the backend, and handle the deployment. Note that the app itself might not be great because you're doing the job or 4 or 5 specialists, but the idea is you could pull it off and have an ok app at the end without it being complete garbage.

chipmonkey75 4y ago

I think this is the flavor of question that should be asked, tho I'd go further. For one thing, I've always really loathed the phrase "full stack" - if you've ever written a UI that has to drive hardware that requires assembly level firmware, built a CI/CD pipeline to run tests, build artifacts, manage infrastructure, update firmware and send it all out into the world, you _might_ be "full stack", for everyone else it's just a colloquial term for a web front end and a database API developer. But I digress. Even in the common context, to be Full Stack, I'd argue that you should be better than the sum of the parts. The lift you get from being able to decide, intelligently and at the speed of thought (without talking to a counterpart on the other end), which pieces of code - optimization, safeguards, business logic, etc. - belong in the front and back end, and how they interact at peak effectiveness, is more valuable than just the ability to build a good API or build a good web page. Further, a full stack engineer, in my experience, is more likely to reach for tools like websockets, memcached, etc. earlier in a project than typical REST APIs (for example) where the line between back- and front- end require a bit more coordinated architecting, to achieve a richer end result. But I doubt this is widely accepted. Anyway, my point is I wouldn't focus on either just because; I'd focus on what makes you better by knowing some of both. What can you learn in the back-end to support problems you're familiar with in the front-end, and what can you do in the front-end to make better use of your knowledge in the back-end? That's where full-stack value really lies.

dec0dedab0de 4y ago

This is a good question. as far as front/back end I think it's probably just good enough to mostly get it working right without breaking anything too often. But what I think really makes it front end is also when you have some server/platform administration skills. You would be surprised how many web developers don't know about tab complete on the shell, or have no idea how DNS works.

dec0dedab0de 4y ago
But what I think really makes it front end I meant to say what really makes it full stack, but it's too late to edit

alexfromapex 4y ago

To me, full stack means you're not "really bad" at FE but more like intermediate to advanced at FE and BE. Over the past few years, full stack is becoming more involved with devops, data engineering, and machine learning too so there's now different levels of full stack in my opinion.

throwaway2016a 4y ago

Full stack allows a single dev to "own" the whole ticket. It's great for startups but not so much at larger (or even medium sized) companies. If you're "really bad at front-end" I would say: not a full stack. If you can't own a ticket end to end and create a front-end that is at least comparable in quality to a dedicated front-end developer then you are just a backend developer. Similar to how I know some mobile dev but wouldn't call myself a mobile app developer in a million years. With that said, I have interviewed a lot of people and full-stack is such a buzzword now that probably 2/3 of the people with it on their resume are in that boat. (good at one level of the stack and just a passing knowledge of the others) I have had recruiters tell me so many times: "Oh, I found this awesome candidate, they're a full stack developer!" only to find there idea of full stack is they know how to add a border to a div with CSS or they are a front-end wizard but their only backend knowledge is SQL.

charlie0 4y ago

My own personal definition of Full Stack Dev is similar to the term one man army. It means I can design an app, do the front end, the backend, and handle the deployment. Note that the app itself might not be great because you're doing the job or 4 or 5 specialists, but the idea is you could pull it off and have an ok app at the end without it being complete garbage.