Wow, hard for me to believe it has been a little bit since the last T-SQL Tuesday block party. This month Raul Gonzalez (b|t) has chosen the topic of what lessons one has learned the hard way. Before we get into the story, however, let’s take a look at who, what, when, and why of T-SQL Tuesday.
What Is T-SQL Tuesday?
T-SQL Tuesday was started by Adam Machanic (b|t) and is a monthly blog party. It occurs on the second Tuesday of each month; where a designated host picks a topic and fellow community bloggers publish a piece. It has been a very useful tool in my opinion and I’m looking forward to doing many more of these. It has been one avenue for others to share their experiences while learning something new along the way.
If you are interested in hosting a T-SQL Tuesday on your blog then reach out to Adam.
Lessons Learned The Hard Way
A lot has transpired over a sixteen-year career thus far. Many lessons have been learned along the way some were more difficult than others. I think it is important to note that not all lessons learned by a data professional have to be of a technical nature as well. Let me see if I can split some up technical vs. non-technical that I’ve learned over the years.
Technical
- Unit testing – who knew that this would be so important right? As a developer starting out and then becoming a DBA I have an appreciation for making sure things test out as they should; rigorous testing. Earlier in my career, I thought that’s what we have QA for, right?
- Backups – yeah I’ve been burned before early on regarding backups and not having them in place as they should have been. You want a dose of reality real fast? That’s a good way to start.
- Blinders On – become so focused that you only take into account a certain area of the picture when in essence what is being changed can affect a multitude of things.
- Knowing vs. Doing – putting comments in code such as “this is probably not the best way to things” is not the attitude to have when fixing the problem – been there done that.
Non-Technical
- Listening/Heeding Advice – this is key and something I did not learn until later on in my career. It’s not a skill set that I came out of the gate with, having a mentality that you are always right is not the best approach to take.
- SME (Subject Matter Expert) – I enjoy helping people; it’s part of who I am. This is both a good and bad trait to have at times. If you are not careful you can find yourself overextending into areas where you think you know something but you don’t. Over the past several years I’ve learned that it’s okay to help people even if it is pointing them in the right direction to someone else. But be as sure as I’m typing this, I’ll always be willing to help and will never apologize for that.
- Conflict Management – over the years I’ve seen many data professionals and worked with various people. All of these experiences have equipped me over time to become a better professional in dealing with conflict which is never easy. A lot of lessons learned along the way on this one.
Failure
I want to bring this topic up in a section all by itself. Having a sports background for most of my life, and then morphing into an avid runner I’ve had “failure is not an option” instilled within me since a very early age. This saying is okay, but in the same token, one cannot be afraid of failure. Some of the best lessons I’ve learned both professionally and non-professionally have come of a result of something I’ve tried and failed out. The key is not staying knocked down, but look at it in a light of if you aren’t trying then you aren’t failing and pushing the envelope.
In Summary
This is a great topic this month. Don’t be ashamed or afraid of your journey and past failures or lessons learned. These are the things that mold and shape us into being the people are to become in the future. May we continue to push the envelope both in technology and beyond; impacting and coaching others along the way. Always remember you started somewhere; remember how that felt? Pay it forward.