Hacker News Reader

Comment by PragmaticPulp | Hacker News Reader

Which do you enjoy more?

It’s always easier to learn and excel in a subject that you prefer. Don’t force yourself into a specialty you don’t like because you think it will help your career more. Doing work you don’t enjoy every day is not good for your career.

As for specialties, both front-end and back-end are too broad of categories. There’s a huge difference between a back-end developer writing simple CRUD apps to serve 1 request per second and a back-end developer writing complex distributed, high-availability applications that serve huge numbers of requests per second. Don’t listen to anyone who tells you “everything is just a CRUD app”.

Pick the domain you like most and then work toward the companies doing the most interesting work in that domain.

View on HN

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.

You’re only a couple years into your career. They’re not going to throw you into the deep end right away. You have to work up toward it over time and usually change companies a few times to get there.

Which is the sad part. It's difficult to get good unless you have the responsibility of doing something challenging. I have similar experience to OP but am now tech lead and managing the infra, which has given me the confidence to take on other devops stuff.

This. Getting a good appreciation for infra is key.

The best way to get into distributed systems is to start building them. Create an OSS project in the space, put it on your resume and whatnot, blog about it, and they will come

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 reimplementing the same things in various cloud providers, so you can get a basic understanding of a shared/sharded data model in various frameworks.

Or, if you want to leapfrog all that, you can jump straight to serverless stores like Firebase or https://www.cloudflare.com/products/workers-kv/ that abstract away the infrastructure and let you focus on writing business logic on top of that.

But IMO you will learn more quickly from one year on the job, during professional backend work in a capable team, than self-learning willy-nilly (where you can pick up a lot of bad practices, or outdated/inappropriate architectures).

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.

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.

I work at a fairly complex distributed system (lots of infrastructure, mostly event-based system with milli-seconds latency for interactions between services managed mainly through queues, either managed externally or internally, 90 million MAU) and I cannot agree more.

Also, I would say that the difference is not much "scaling" a CRUD app for request/seconds, but for engineers on a single codebase/service, also architecturally. It's one thing to work alone on your project (which will probably handle k req/s, it's very easy nowadays with classic PostgreSQL and some other queues like RabbitMQ if you need event-based system). It's another to work on the same system with 100x more features, complexity (either in the same monolith or in different micro-services), and especially understand how to be pragmatic and solve problems you did not account for.

No amount of study can prepare you, other than first years at work. Afterwards, in my opinion, the challenges become improving the technology to scale more, and management.

Reply on news.ycombinator.com