Wish these were more 'angry zoomer tears' inducing, matching the meme format. At their best, these memes reveal a controversial opinion of some expert that cuts through industry bullshit that masquerades as 'best practice'.<p>A recent one that I found amusing.<p>IQ55: How much do they read?<p>IQ100: <i>We evaluate people based on a comprehensive survey that aligns their skills and competencies with our needs.</i><p>IQ145: How much do they read?<p>Another one.
I thought this article was going to be about normal distributions and sigma factors in engineering, maybe a bit on the central limit theorem...<p><a href="https://www.thoughtco.com/bell-curve-normal-distribution-defined-2312350" rel="nofollow">https://www.thoughtco.com/bell-curve-normal-distribution-def...</a><p><a href="https://news.mit.edu/2012/explained-sigma-0209" rel="nofollow">https://news.mit.edu/2012/explained-sigma-0209</a><p>One thing to keep in mind, when looking at complex topics like expert vs. beginner opinions and so on:<p>> "<i>When You Shouldn't Use the Bell Curve</i>: There are some types of data that don't follow a normal distribution pattern. These data sets shouldn't be forced to try to fit a bell curve. A classic example would be student grades, which often have two modes. Other types of data that don't follow the curve include income, population growth, and mechanical failures."
My version of this is "test in production".<p>I did that when I was in my early 20s, got taught to use dedicated TST and UAT environments by more experienced engineers, and now in my 40s I'm telling everyone who's willing to listen that isolated testing is nearly worthless.<p>The amount of issues I can uncover by using telemetry from production is just insane. Any half-way decent APM will have a dashboard view that summarises errors by how often they occur, which is an automatic priority list.<p>Some teams I tell this to just blink at me slowly and say they only do testing in UAT, and that after "sign off" they don't see any further need for monitoring. It's <i>signed off</i>, you see! Done. Finished. Released. End. Of. Story.
I’m interested in the last one, specifically pair programming. I think we’ve lost a lot of serendipitous communal wisdom with remote work, and meetings don’t help. Does anyone have experience with pair programming helping with this, or does it always just feel like another long pointless meeting where everything gets done independently later? I would really like to find the best way to do this.
> Spreadsheets are often more maintainable, more usable, and more extensible than most software projects.<p>I would love to see someone successfully bridge the gap between spreadsheets and software. Just some version control and testing would be amazing
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 <i>reason</i> behind the placement that matters.<p>I'll use the OP's first item, Kubernetes, as an example because I'm familiar with it.<p><pre><code> > [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.
</code></pre>
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.<p>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.<p>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):<p><pre><code> > [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.
</code></pre>
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.
<p><pre><code> > WSL is good enough for most things.
</code></pre>
WSL1 is good for maybe 50% of things I tried - as it has rudimentary or nonexistent support for some syscalls - eg more advanced ptrace() commands are not supported, similarly not all clone() options work. And it's just the beginning of problems<p>It's good for stdio/net code, but code which makes use of more arcane OS functionalities will frequently break.
>> Windows has a great desktop environment, and WSL is good enough for most things.<p>I haven't met an expert that would advocate for WSL like that.
Are some of these really beginner opinions? It's ok for the sake of a joke, but some of these reasonings are far more sophisticated that I've seen in practice from people with little or no experience.
Just to clarify for the boomers, the meme is that beginners and experts share similar ideas not that they reason about or execute on them in the same way.<p>Also, the endearing label for those of you in the middle of the bell curve is "midwit".<p>This meme can mostly be boiled down to accepting the constraints of reality and working around them. The midwit component of the meme is often something like "nooo, but everything has to be perfect".