Great article, Louis.
I've found that you have to be very, very careful in studying. It's really spooky out there.
For example... I've seen several articles from people that supposedly know what they're doing that said using recursive CTEs is a best practice set-based method for replacing while loops that operated based on single-row incremental computations. I've seen people create "Holy Grail" articles that "prove" that XML splitters will beat Tally Table-like splitters hands down. And almost the whole world (including the previous me) adopted some "Best Practices" for index maintenance more than 20 years ago because of some super-simple, super-unfortunate miswording in official Microsoft-supported documentation that has also mistakenly poo-poo'd the use of a remarkable datatype, its remarkable uses, and some incredible methods for performance. How about the "Best Practice" of doing things like lowering a Fill Factor until fragmentation stops, always using IDENTITY columns for virtually everything. or even defragging indexes just because they have logical fragmentation (which should never be done if they have a "0" Fill Factor, BTW). Of course, it's a "Best Practice" to not use Random GUIDs on a Clustered Index, right? Use NEWSEQUENTIALID() instead, right?
And then there are the "expert" changes that have been made by Microsoft such as the equivalent of the permanent invocation of Trace Flag 1117 on TempDB with no way to disable it even on a necessary temporary basis or how about LOBs defaulting to in-row which permanently destroys page density of the Clustered Index. Yeah... both of those are just two examples of how supposed "Best Practices" have put the screws to people without them even knowing about it.
I agree that forum sites like SSC (not SO) are wonderful for learning because you get the best of both worlds and those are real life problems and multiple solutions along with discussions that explain the pro's and con's of everything, even the original question itself.
With all that, the only way to flourish is to remember to doubt opinions enough to test them with code and doubt other people's tests and the data they used to conduct the test. Remember that if the test data doesn't look like production data, the code might fail miserably when it does go to production no matter how many tests you've run. A classic example of this is poor people that have been duped into thinking the use of what people call "XML Splitters" to split (for example) is better than Tally-based splitters. Several "Holy Grail" articles have been written on the subject where the tests "prove" it. The problem is, the test data used even on million row test table has a cardinality of somewhere between 1 and 10 because the authors either didn't know how to build life-like test data or were too lazy to. It turns out that XML absolutely shines on large rowcounts that have a super low cardinality. That's usually not anything like what your real data looks like.
So, question everything, learn how to do your own tests, and learn how to build lots of test data correctly. That will help you to develop two of the most important skills a DBA can ever have... very strong bullshit baffles and the ability to prove it in no uncertain terms. 😀 There's only one way to get there... taking the time to practice.
If you don't spend the time, then you should add "victim" to your resume. 😀