4 ms·

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 work

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.

PragmaticPulp 4y ago
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.
- charlie0 4y ago
  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.
  - bradwood 4y ago
    This. Getting a good appreciation for infra is key.
mountainriver 4y ago
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
solardev 4y ago
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/ 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).
- karmakaze 4y ago
  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.
  - solardev 4y ago
    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.

PragmaticPulp 4y ago

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.

charlie0 4y ago
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.
- bradwood 4y ago
  This. Getting a good appreciation for infra is key.

mountainriver 4y ago

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

solardev 4y ago

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

karmakaze 4y ago
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.
- solardev 4y ago
  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.