How do the Experts Become Experts?
-
Comments posted to this topic are about the item How do the Experts Become Experts?
Aunt Kathi Data Platform MVP
Author of Expert T-SQL Window Functions
Simple-Talk Editor -
I like this topic. People tend to mythologize experts and I don't think that's beneficial for anyone. For the experts it goes straight to their head and for everyone else they are left feeling inadequate and wondering how someone could know that much. I think a better indicator of this kind of progress is working hard over many years to continually learn. Changing jobs so your skills don't stagnate helps too. Spinning up labs and testing features will help too. It's not so much how many contacts they have a MSFT, VMware, NetApp, etc. So I agree that the main driver here is action over time - just like most anything else.Good topic!
-
Unfortunately, many "experts" are considered to be experts simply because they publish very often or have written a book on a subject that happens to sell well because the people reading the articles or buying the books don't know any better and then those poor minions back them up by touting their exploits.
One of thousands and thousands of examples that exhibit this syndrome was a forum post that was advertised on LinkedIn. It talked about how great Recursive CTEs (rCTEs from here on) were for counting and how they were "set based" . Of course, nothing could be further from the truth. Even a well written While Loop can beat an rCTE that "counts" for performance and resource usage.
When that contrary proof was demonstrated with code, along with 3 different methods (also with demonstrable code) that blew the doors off of the rCTE method of counting, the author still insisted that the rCTE was better, easier, and faster and then also justified it as being "excellent" when row low counts were expected. The really bad part was, this author's minions jumped on the same band wagon even when there was fully demonstrable code that proved otherwise.
Other great examples of this "expert" syndrome come in the form of "holy grail" articles that seem to be (and usually are) very well written with fully automated test data generation, a test harness, and fully demonstrable code. But, under the covers there are "devils in the data" that, apparently, no one even considers. A great example of that problem are the articles that supposedly prove that the "XML Method" for splitting stings is the "best method". Because of the seemingly scientific nature of having a ton of test data and all the code producing repeatable results, no one realizes the impact that simply repeating the same row 10,000 times will have on the optimizer, which has actually made the worst method look like the best and vice versa. Unfortunately, the minions that read it and never make that realization consider the author to be an expert simply because of how well the article was written and previously popularity of the author gained by such articles or posts.
Unfortunately and frequently, when such authors are challenged with such contrary and fully demonstrable facts, they do things like censor the responses and even shut down all replies to their post. I even had one author tell me that he didn't want to take the time to do any additional testing because the article was complete and was moving on and then saw fit to write multiple other articles that contain the same horrible mistake they made in the first article... and their minions love it!
Don't get me wrong... there are true "Experts" out there and they do publish a whole lot but no author that I know of has gone without making a mistake or two. The problem is much like my Dad once said about books... "Half of all that is written is wrong. The other half is written in such a fashion that you can't tell".
So, getting back to what makes an expert? There are only two things, IMHO...
1. Being demonstrably correct most of the time.
2. Being humble enough to admit when they made a mistake and then correct it.--Jeff Moden
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.Change is inevitable... Change for the better is not.
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally) -
While I agree with the "wolves in sheeps clothing" type comments from Jeff, I do want to distinguish between authors and experts. There are lots of individuals I run across that I consider experts in a number of disciplines who don't feel compelled to put pen to paper.
The one common attribute I've seen in those experts is a curious mind. They were not satisfied to simply sling code and call victory when it compiles: They would often give themselves their own "assignments" to figure out how to improve things or make something better, understand how their field works and ultimately how best to tap into the strengths they could find. They are not satisfied with reading code and thinking it was better, they design a way to ensure that the alternative is better than the original design.
Those types of folks develop a much deeper understanding and are the ones to run to when something unexpected goes down, since they are the best equipped to find what went sideways and how to get yourself out of it.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again? - Matt Miller (4) - Tuesday, January 30, 2018 10:00 AM
I could not agree more. It's truly amazing to watch such an expert attack a problem, design something new, or redesign something old. I'm truly one of the luckiest people in the world because most of the folks that I work with every day fit Matt's observations above of what makes an expert. Well said, Mr. Miller!
--Jeff Moden
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.Change is inevitable... Change for the better is not.
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally) -
Jeff and Matt,
You both are spot on for what I see an expert as. All too often it is someone with a title but no substance to it. Or they have there one or two really great concepts in action that really are something amazing. Sadly they lack the ability to comprehend why it is amazing or what makes it so. That lack leaves it so they can't possibly apply what they should have learned to other concepts or technologies.
Curious people, ones that try new things, setup their own environments, those are the people that usually know what's going on and can find solutions to most anything. I've also seen that go south too with some getting too distracted or off task. They can start a project and get it mostly done, but it will never reach that level. Still considered an expert because they can put out that fire, but they can't get the migration done that was started 6 months ago.
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply