A few years ago, I was in a meeting at a client’s, and the discussion turned to teamwork. I jokingly said “teamwork is for people who cannot be trusted with complex tasks on their own”, at which point the whole room exploded in laughter (well, everyone laughed except the agile coach).
And even though my joke has since become a pinned tweet, it is in all fairness only true in a limited context. In most of our day-to-day work, we need the help of others, and they rely on ours.
You may think that speaking at usergroups and conferences is reserved for a select group of elite professionals. Let me tell you right away that this is not the case, and that you should seriously consider a rewarding side career as a speaker at usergroups and conferences!
Here’s the why and the how.
You’ll find a lot of people, consultants and peers, liberally dispensing plenty of “best practices” on the Interwebs and in real life. Heck, I’d say that’s pretty much all I do on this blog. But when should you go with the best practice and when should you make your own road?
Remember that time when you accidentally truncated a table in production? Or when you forgot the WHERE clause in your UPDATE statement? You’re not really a seasoned professional if you haven’t. There’s even a very apt name for that moment in time when the realization hits you: The oh-no second.
But what if there was some type of control to prevent this from happening? Like more restrictive controls, perhaps some type of peer-review process before you clicked “go”? Or even…
I’m an outspoken advocate of always using a clustered index on each and every table you create as a matter of best practice. But even I will agree that there’s a case for using the odd heap now and then.
For practically every piece of code you develop, there will be trade-offs. Sometimes, you can combine the best of two worlds, other times it comes down to some hard choices. For T-SQL developers, it typically boils down to a few key questions: