![[Pasted image 20250131163920.png]] There was a big argument in the Gophers slack recently. A junior developer came in and asked why 10 years of experience was needed to become a senior developer. - What actually is being learned in those final 7 years after mastering the basics? - Why are all the seniors in the channel so "evasive" about it? - Why can no one give me hard examples on the things that a junior needs to know to get to the next level. There were a lot of personal insults and back and forth comments. Ultimately, the seniors said "its hard to explain", or "you learn the entire lifecycle of software development". Not very satisfying answers. Here is my answer: Basically every single thing you decide to do while developing an application has tradeoffs. So its not as quantifiable as a junior developer roadmap. Because “it depends” is always part of the answer. Some hard examples: - **Database**: - Is performance, features, flexibility or compliance more important? - Are migrations really important? What about when migrations run out of order due to stale PRs? - Maybe sqlite will get you all the way? - What if you need to decouple your database performance from your server performance? What if you don’t? - **Object storage**: - Do you choose between convenience (file storage) vs scale (s3)? Why? - If you choose file storage, how would you migrate to cloud object storage? - **Asynchronous services**: - Long running go routines good enough? - Or should we split it into separate binaries? - Do we need to make sure it can scale across many machines? - Can they communicate in-process via channels or maybe via network? HTTP/RPC/Message bus? - **Programming language** - Go/Rust/Node/Python and all of their tradeoffs between simplicity, developer onboarding, performance - **Architecture** - Microservices? - Modular monolith? - Monorepo? - **Rewrites** - Should we keep using backbonejs? - Should we upgrade our React version? - What about TypeScript for the frontend? - Will changing to HTMX *really* improve our developer productivity? Those are a few off the top of my head. We have to make decisions that improve some things while sacrificing other things. Performance, convenience, team velocity, cost, time to market, maintainability, deployability, observability. You can never, ever have everything at once. So which do you choose? Knowing which one to choose comes with years of experience choosing the wrong thing, and seeing how it turns out. None of this have anything to do with learning how to use a framework X or library Y. Instead its more, _why_ should we use X or Y? What do we lose, and what do we gain?