I think mastery is a game of maximizing nuance/compromise and finding solutions in the middle. When you can take something that already kind of works and make i

I think mastery is a game of maximizing nuance/compromise and finding solutions in the middle. When you can take something that already kind of works and make it work 10% better, that is important. It is rare to find people who can consistently add incremental value to the same thing over and over. Even if you are "good" at something doesn't mean you are able to deliver it in a professional setting. I've seen lack of nuance result in the most incredible architectures. I think the #1 offender still is: "It can NEVER EVER go down". This is the definition of amateur hour in my book. Usually results in a system that goes down far more often than a single node cave man approach. I'd hesitate to imply that pros aren't interested in shiny new tools. The primary difference is that the pros usually go get new tools once every few years and typically wait for market sentiment to shake down first. The amateurs are shopping at Home Depot every weekend. We are just now looking at building a cloud-native stack in 2023. I made us wait a solid ~decade (lambda launched in 2014) before I was willing to go beyond the safety of our vendor-agnostic VM bubbles. So yeah, we are using some shiny new FaaS/serverless tools, but we are using them in a really dumb & conservative way (i.e. serving old-school SSR HTML forms, etc). The tooling change is really only to serve our operational convenience and improve compliance/audit stance. Not because it's fun/new/what everyone else is doing/etc. How many developers do you know will go out of their way on points like those? "I picked this technology primarily to make our audits and compliance conversations easier as we scale". Who does that? This is another example of mastery. Paying attention to and caring about all of the auxiliary things around the software/problem/tools.