What would you tell your younger self?

, 2017-07-11




Well, it’s T-SQL Tuesday time again  -the blog party started by Adam Machanic (blog | twitter) and this month hosted by  Raul Gonzalez. This month we’re talking about “those important lessons that you learned the hard way.”  - but what does that mean. The lessons that you instantly know that you’ve learnt – like the realization that you just removed a load of logons that you shouldn’t have or that you just dropped a crucial database and if you could only turn the clock back just 30 seconds you’d take steps to ensure your mistake was impossible! Or does it mean the more gentle realization that if you’d have gained certain knowledge over time then you’d be a better person today.

Well, I decided to re-frame that question – a little more positively  (something I probably should have learnt how to do a lot earlier in my career than I actually did) and say “hey Martin, if you could go back in time and meet your younger self, what advise would you give them?”

The list could go on and on – but in the interests of time here’s just a few.

  • Always consult your crystal ball – or at least try and take a long term view of anything you create.
  • Get a mentor – they have value beyond what you could probably imagine. Advice from somebody who’s been around the block a couple of times can be invaluable
  • Avoid being critical of other peoples past work – they did stuff for a reason. Sometimes you’ll even find you were the past author – how embarrassing!
  • Collaborate with others and learn from them – look at problems from their point of view and not just your own. Use their insights to strengthen your knowledge. Walk a mile in somebody else’s shoes (as the saying goes)
  • If you try to learn everything then you’re probably going to fail – and that’ll make you unhappy.
  • Remember there’s more to life than technology (really there is!)

And here’s the final piece of advise I’d give my younger self – know when something is finished (can you check it off against the requirements? I hope you had requirements to begin with – else how will you know when you are done?). Most times you could go on and on refining your code, or your document or whatever. But knowing when something is done and can be comfortably handed over is a skill in itself.

Which reminds me that I should probably wrap this post up and wish you all a happy T-SQL Tuesday!

Have a great day.








Related content

Database Mirroring FAQ: Can a 2008 SQL instance be used as the witness for a 2005 database mirroring setup?

Question: Can a 2008 SQL instance be used as the witness for a 2005 database mirroring setup? This question was sent to me via email. My reply follows. Can a 2008 SQL instance be used as the witness for a 2005 database mirroring setup? Databases to be mirrored are currently running on 2005 SQL instances but will be upgraded to 2008 SQL in the near future.


1,567 reads

Networking - Part 4

You may want to read Part 1 , Part 2 , and Part 3 before continuing. This time around I'd like to talk about social networking. We'll start with social networking. Facebook, MySpace, and Twitter are all good examples of using technology to let...


1,530 reads

Speaking at Community Events - More Thoughts

Last week I posted Speaking at Community Events - Time to Raise the Bar?, a first cut at talking about to what degree we should require experience for speakers at events like SQLSaturday as well as when it might be appropriate to add additional focus/limitations on the presentations that are accepted. I've got a few more thoughts on the topic this week, and I look forward to your comments.


360 reads