Ask HN: Should I be specializing in either front end or back end as full-stack? • Hacker News Board

Re: Ask HN: Should I be specializing in either front end or back end as full-stack?

#41

Post by chipmonkey75 » Wed, Jun 22, 2022, 10:26 PM UTC

deanebarker wrote: post #9

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"?

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.

Re: Ask HN: Should I be specializing in either front end or back end as full-stack?

#42

Post by karmakaze » Wed, Jun 22, 2022, 10:33 PM UTC

solardev wrote: post #32

yernarak wrote: post #6

Earlier quoted context omitted.

I think I enjoy backend work more, however in my 3 years of working I didn't really experience those complex distributed apps to work on. I've been mainly working with really simple CRUD apps. 1 server apps kind of things. That's why I'm also afraid that I won'be fit and good enough to work on those big complex apps.

Complex distributed apps are incredibly difficult to get started with, at first. They are a huge leap up from simple CRUD because of the atomicity and consistency requirements. Can you look for a junior position in a medium to big company, or a startup, with enough engineers to help mentor you? If you want to try it yourself, you can start by experimenting with database clones, redis shards, K8s, etc., and then try r…

It may not be common, but I don't think it's inherently not doable. I worked at a Ruby/Rails startup that had a monolithic API codebase, but also a number of new microservices written in Go using various AWS products. The Platform team that maintained all of this was small like 3-pizza-small and we hired both junior devs as well as interns if they showed an appropriate aptitude. So I wouldn't rule it out. Btw the example company is gone for this intent/purpose but did exist as such.

In general I think working at (very) small startups is the best way for very capable, self-learner types to be exposed and allowed to do lots of things in a short time as it's basically a free-for-all matching tasks with anyone who can get it done.

Edit: after writing this, I realize that the other Ruby/Rails place I'm working at (Shopify) does let non-senior devs do some complicated stuff in the core monolith and jobs that gets reviewed by senior devs. The team I'm on runs Kanban-style 2-week minicycles (didn't like Sprint'ing) and encourage different people to try tackling different things, often with pairing or review of proposed approach.

Re: Ask HN: Should I be specializing in either front end or back end as full-stack?

#43

Post by solardev » Thu, Jun 23, 2022, 1:20 AM UTC

karmakaze wrote: post #42

solardev wrote: post #32

Earlier quoted context omitted.

Complex distributed apps are incredibly difficult to get started with, at first. They are a huge leap up from simple CRUD because of the atomicity and consistency requirements. Can you look for a junior position in a medium to big company, or a startup, with enough engineers to help mentor you? If you want to try it yourself, you can start by experimenting with database clones, redis shards, K8s, etc., and then try r…

It may not be common, but I don't think it's inherently not doable. I worked at a Ruby/Rails startup that had a monolithic API codebase, but also a number of new microservices written in Go using various AWS products. The Platform team that maintained all of this was small like 3-pizza-small and we hired both junior devs as well as interns if they showed an appropriate aptitude. So I wouldn't rule it out. Btw the exa…

Just using microservices doesn't automatically mean your app is distributed, though, or resilient/reliable/maintainable/scalable/consistent/atomic, etc. Microservices increase complexity but don't automatically guarantee improved quality.

More to the point: The tricky part of doing it all yourself is you have no idea if you're doing it well, and whether it would survive heavy real-world use and other devs/teams/companies/APIs/user agents. It's not easy for a solo dev to catch pitfalls that more experienced devs, or just more # of devs, might notice in a pair programming sesh or code review.

By all means experiment on your own, but IMO I found teams to be much more helpful for actually learning best practices rather than barebones spaghetti code. Startups count too! What you may lose in learning architectural best practices (depending on if you have any seniors and how good they are), you gain in problem-solving and research abilities, not to mention learning to do a lot of things at low cost.