| I started my career in a startup and had a similar FOMO, always thinking that the big corps have figured out all these problems we were struggling with, hoping I can one day learn to how. Then I joined one and had an eye opening experience - it's not true at all. They might have better tooling (although that's not even always the case), and they might have better established ways to do things, but the engineers aren't any better than at a startup and they deal with the same problems as you. A lot of work at large corps is "patchworking", and a lot of code is pretty awful and won't teach you "the right way" to do anything. Like anywhere else, there's a lot of v1 code that doesn't get substantially improved after it's shipped because the team has moved on to something else. There can be a lot of churn where code gets moved between teams, rewritten and discarded as priorities change and people come and go. Only a minority of core systems get the benefit of being iterated on and evolved over a long period of time. I believe that the best way to learn how to do things right is to make mistakes yourself and learn from them. Work on a single project long enough so that you don't just write the v1, but also the v2 and v3 and v4 that make you see the mistakes you previously made and let you figure out how to fix them. Startups can be a good place to do that, because unlike in a bigger place, you might actually be given the scope and responsibility to do that even as a junior engineer. You are right that maintaining things is a good way to learn, but you could equally spend 3 years moving on from one new micro service to another as the roadmap priorities change every 6 months, with very little opportunity to spend some time with your own code and learn from it. If you've worked at 3 different places in 3 years, you might not have seen the benefits yet, but if you try to stay and work on something for long enough, you'll learn a ton. |