There are two reasons that I feel are the most important to me:
- How can I mentor others if I am not being mentored?
- For me to really enjoy and excel at something I need to know "How to think"
To Mentor you need to be mentored
Many years ago I attended a financial planning conference in Cape Town. I went down expecting to learn all sorts of ways to get rich and plan for the future. What I wasn't expecting was to be challenged about my mentoring of the people in my business!
One of the talks was given by a man who was in his 80s and he said that he still had a mentor! I thought that by the time you got that old, there was not much people could teach you about life. He said something that has radically changed my thinking about mentoring:
"How can you mentor people if you are not being mentored yourself?"
I started my career of 29 years after finishing my BSC Computer Science degree, working for Edgars, a clothing company in South Africa, as an Adabas Database Administrator on an IBM mainframe. The learning curve was very steep and I enjoyed every minute of the long climb. The technical support department was very lucky to have a man called Dennis Murray. He challenged everything I said and I soon realized that I couldn't open my mouth before I knew what I was talking about.
Dennis was in charge of MVS and didn't really understand the world of Data. To my surprise he didn't need to! If I presented what I had researched and understood and what I didn't understand, he could help me without fail. The process of preparing for a discussion with him and then watching him detect my incorrect or lack of understanding was intense, mainly because I thought I had prepared properly. After spending 3 years with him I had grown a lot technically and today I still attribute much of my success to this time spent with Dennis.
I learnt how to think and work through the issue facing me. The first point was always, do you really understand what you are talking about. If not, go back and find out where you lost the plot. This meant that I had to break down my understanding to the simplest level. Many years later I read about Occam's razor:
"The principle states that among competing hypotheses, the one with the fewest assumptions should be selected. Other, more complicated solutions may ultimately prove correct, but—in the absence of certainty—the fewer assumptions that are made, the better."
As I progressed through the ranks, the people that could mentor me in the way that Dennis could got smaller and smaller. Living in South Africa made it harder and harder and I stopped searching for a wise man. This is one of the bigger mistakes I have made in my life.
Last year, I received a call from my brother who has a software development company, saying, "We really, really need help!" For some reason, I have always got involved in difficult and stretching engagements. This was no different, the learning curve was similar to the early days with Edgars. Fortunately, the internet was the fire hydrant that would provide the water I needed to drink. The #sqlfamily was HUGE and for months I could read enough about the "accidental DBA"! As my knowledge on the how and what of SQL Server progressed I started to realize that my foundation was not deep enough.
I would listen to myself talk to the developers and constantly hear Dennis say – really? This pushed me learn more and more but I still feel that I don't really know how to think like the SQL Engine. And this is where I need help to get my thinking right.
I read a fascinating article on "Dashboard visualizations", it discussed and explained the thinking behind the dials in an aeroplane cockpit. An inexperienced person just sees 100s of dials and wonders what do I look at? The article then explained that the main dials are always at eye-level and then the other dials are positioned according to a well-defined story of events. This means that the next dial is dependent on what the previous dial told you. This was a lovely analogue of what we should all strive for when building a feedback system to management and other readers.
Then something else struck me, words that another brother challenged me with: "If you can't explain something simply then you probably don't understand it well enough to teach me!"
I need to know "How to think"!
I spend a lot of time training people to "take over" from me and it is really worrying that I am still not sure that I fully understand "How to think" about the SQL Engine. I need to be able to work things out from first principles and build on to facts / hypotheses that I have collected and developed, knowing that I am building on stone and not sand.
I have been developing MS SQL Server software solutions for customers for the last 10 years and I am constantly amazed at how I continue to learn on a daily basis. As the software development community progressed from Cobol, C to C++ I quickly realized that just learning the new C++ syntax was not good enough. I had to learn about Object-Oriented design and development. The change was radical, and I can see with T-SQL how my coding has changed from RBAR to "thinking in sets". I had to force myself to learn and not just code to be "DONE"!
On-Time Delivery is important but I also had to be CORRECT for the world I was living in.
Now I find myself in the uncomfortable position of knowing that my thinking is not real and flaky in some areas.
I am at an age now where the need for success is not as importance as significance is, and I would love to help people more and more. Whilst I am comfortable admitting that I don't really understand, I want to really understand so that I can help others around me. South Africa still suffers from a small knowledge base. This in no ways means that we are not capable, just we are limited in the people that we can rub shoulders with and exchange ideas and understanding.
What we don't need is the sharing of "flawed thinking" and this bothers me. Fortunately the #sqlfamily community is not lacking in the ability and desire to help in the areas that I am short in.