June 10, 2026 at 12:00 am
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
June 10, 2026 at 7:25 am
When I was in my 20s, I worked with a bloke who had retired twice, got bored twice and gone back to work each time. He was full of wisdom. His summation of the stages of someone's career was
He taught me that there is a lot of cross-pollination between disciplines within a business. The best thing you can do is to embrace the opportunities for cross-pollination. It's the things you learn around your discipline that strengthen your core.
I learned lots at SQL Bits and exponentially more at Q-Con because these exposed me to ideas and concepts that I would not have experienced in my normal work.
Being known for a breadth of experience tends to result in opportunities for yet more experience.
Learn to hear to listen rather as opposed to hearing for the gap so you can speak. There are times to demonstrate expertise (a few) and times to absorb it (many).
There's a saying, "Teach once, learn twice". I've found that to be true. There's also the saying that it is OK to hold strong opinions, but hold them loosely.
June 10, 2026 at 2:55 pm
Digging in and experimenting. I did that quite a bit early in my career to learn the finer aspects of Access (that was a thing in the 90s) and MSSQL.
June 10, 2026 at 4:22 pm
Short answer: the F5 button.
Back in the day, like the 90's, I worked for a music "record label" where the talent reps could send an email to request@datalab.xyx (not the real domain which I forget anyway) with requests for data. Many days there were maybe a dozen different requests for every kind of data shape imaginable, and some I couldn't imagine. I wrote many hundreds or maybe thousands of queries in Oracle PL/SQL.
Then I got a different job and the databases were all in the SAS System which is the polar opposite of a relational database. In SAS the whole program, or "data step", runs against each row of data and the physical ordering of the rows matters greatly. Converting from Oracle to SAS used to give me headaches at night. In a lot of ways SAS is as good or a better way to organize data then a relational database imo. But SAS didn't work well with MS Office and the kinds of analytical applications that were being requested. So they brought in SQL Server to build "data marts" which was awesome. That was SQL Server 2000. Yikes that's scary to type now. Then we upgraded over the years to 2005, 2008, and finally 2008R2
Then I talked myself into an "application development" job at the same company using Java at first and then C#. Before that when building analytical applications I would try to convince the "app dev" people we should use the database to do more things and to improve the data models. Which gets you labelled as a problem and they took pains to explain to me that I didn't know what I was talking about and they had a superior way of doing things. So it occurred to me that either it was true or it wasn't and I wanted to find out which. For about 3 or 4 years I never even opened SSMS or wrote any SQL. I totally missed the release of SQL Server 2012.
So which was it? Was I an idiot or were the other guys the ones with competency issues? It was more me being an idiot than the other guys lol. My early Java programing was laughable and my boss would really take the time to teach me how to do things in a better way. I (wrongly) wrote monolithically the way I did with SQL. It was awesome in terms of learning and he was a saintly patient person. I'm still grateful. But I came to the conclusion that the technical reason database wasn't being used the logical, database way was almost entirely due to the method(s) of data access and the data types impedance mismatch issue. The technical reasons became set in stone by the legacy code and that became the organizational reason too. Meaning because it was difficult and involved extra steps and the expense of a DBA and extra complication due to mismatched data types the "db first" reasoning was essentially impossible to implement with the real constraints of time and expense.
So I got another job doing analytical programming using SQL Server. Which is what I liked doing and still do. This is when I started to answer Forum questions on SSC. I wanted to write a whole bunch of queries and to get back up to speed with SQL Server and to learn from the experts. When I started back I didn't know windowing functions (because I had missed SQL Server 2012) and I wasn't familiar with CROSS/OUTER APPLY even though it was available back in the day.
Then I noticed a sort of strange thing started happening. All of the individual technical reasons the "db first" way of doing things was impractical began to go away. The SQL Server data types library in C# was released in like 2015. Then Microsoft released OWIN for .NET Framework with an orderable middleware pipeline and I read online about people building SQL+XML based OWIN systems that skipped over or obviated the impedance mismatch problem. But there was still the issue of needing to parse request parameters with type safety. But then Microsoft released .NET Core (which after .NET5 became just .NET again lol). With .NET Core the http pipeline parameters became available in the HttpContext and they were made type safe. That's all you need to build simple but also insanely powerful memory+persistence systems the "db first" way without any of the old frictions. For a while I've been hoping there would be new frameworks that jumped on this but it hasn't happened afaik. Now it's my goal to bring it about. We'll see soon how it goes
Aus dem Paradies, das Cantor uns geschaffen, soll uns niemand vertreiben können
June 11, 2026 at 8:38 pm
Don't ever call yourself an expert. That is for others to determine and decide.
Rick
If you do a half-assed job of things, folks will ask 'why did this ass only do half the job?'
Viewing 5 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply