|
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. |