Nothing breeds success like tenacity. Pete Townshend put it well in The Who song “Guitar and Pen”. “When you sing through the verse and you end in a scream; And you swear and you curse ’cause the rhyming ain’t clean; But it suddenly comes after years of delay; You pick up your guitar, you can suddenly play”. Notice, “years” of delay? That is tenacity. In much the same way, the best programmers design and then attempt solutions, and if it isn’t right, they retry until the solution works repeatedly, correctly, and comfortably in all necessary situations: verified with testing, testing, and then more testing to make sure.

Naturally, tenacity can be overdone if you become deluded into thinking solving problems is a solitary struggle, human against machine, as if it would be cheating by getting help. After working through a problem logically, exhausting one’s skills and knowledge, it is sheer prideful stubbornness to not seek out help. In reality, often the most important lesson that a professional person learns is to use every resource around to its fullest. In practical terms, that means doing research on the web, in books, and getting help from coworkers or even strangers on the Internet. The tenacious keeps going until the problem is solved, using whatever means possible to their advantage. Like I stated initially, the goal is successful completion, not glory.

DBAs must face many problems with tenacity. Problems come constantly; sometimes they are spurious environmental issues, and quite often not repeatable in your test environment. There are a myriad of failure types: backups fail, index builds fail, blocking causes timeouts, deadlocks, hardware failures, data quality issues causing constraint failures; the list is long as it is wide. All of this complexity (plus the real realities of time) means that it is difficult to approach the goal of perfection. Sometimes you succeed because you’ve know an obvious solution to the problem from the store of details and techniques you’ve squirrelled away because they just might come in handy one day; other times you succeed by methodically considering all possible causes and solutions, not just the ones that you already know or have seen before. Sometimes it will drive you quite mad, and you will want to quit. Of course, instead of a smashing a guitar, you uninstall SQL Server and swear to never code again (don’t smash your computer, you know don’t make as much as Pete Townshend does!). Then an hour later you are reinstalling and trying again (and possibly again.)