The beginner/journeyman/expert bell-curve meme images benefit from being posted in context with an existing discussion. By themselves, they don't carry enough i

The beginner/journeyman/expert bell-curve meme images benefit from being posted in context with an existing discussion. By themselves, they don't carry enough information to be useful. It's the reason behind the placement that matters. I'll use the OP's first item, Kubernetes, as an example because I'm familiar with it. > [Common Practice]: You should always use Kubernetes and other > "correct" infrastructure. > > Beginners/Experts: Don't Use Kubernetes, Yet. Use the simplest > abstraction you need for now. So, first, is that really common practice? Overwhelmingly I've seen Kubernetes struggle for adoption among intermediate-level engineers because they're familiar with local development but still getting used to the basics of running software "in the cloud", and find the complication around replicated distributed systems off-putting. Second, the reasons for "don't use Kubernetes" are often vastly different between the two "tails" of the bell-curve. A bad reason to reject universal Kubernetes is because the person wants to build everything out of Puppet and bash scripts, held together by human suffering (aka "on-call"). A good reason is to note that some bits of infra are adjacent to (or below) Kubernetes in the dependency graph; you don't necessarily want your distributed scheduler to be a hard dependency for log ingestion or certificate issuing. Third, I'm suspicious of any sort of advice that can be inverted without being obviously incorrect. Let's try that here (and also split/elaborate the tails): > [Common Practice]: Don't Use Kubernetes, Yet. Use the simplest > abstraction you need for now. > > Beginners: You should always use Kubernetes and other > "correct" infrastructure. Best practices exist and should be > followed without wasting time on the "why". > > Experts: Kubernetes should be the standard API between product > and infrastructure. The additional local complexity introduced > by containers pays off by reducing global complexity and > enforcing shared technical contracts between teams. This more closely matches my experience in the industry (beginners and experts both pushing for Kubernetes, with rejection of it by the "middle"). But! Big but! Note that both versions could be a sample of the same bell curve, depending on where you sliced it. Trying to allocate positions to beginner/journeyman/expert contains an implicit parameter of the writer's own location on the global curve, and which portions of it they have visibility into.