Last week Andy Warren wrote a great article called revisiting what you know and it got quite a few interesting comments. The gist of the article is that many of us learn certain tenets and techniques because we have to, just in order for us to get a job done. We're focusing on being effective and not necessarily on doing something in the best way. So Andy's advice was that we should periodically revisit the things we believe in and see if the way we are doing things makes sense or if we should consider doing things differently.
In many ways I agree. I used to tell all junior DBAs working for me that no cursors or temp tables were allowed. It was an iron rule for them to work within in the SQL Server v6.5 days and they needed to abide by it. Then one of them saw me using a cursor to perform some administrative update and asked me why.
My answer was that it was a one time thing, the cursor worked and was quick and easy to develop, and it made the best solution. Of course I got queried as to why they couldn't write cursors in code that went into our products. My answer was that most of their code was run over and over and needed to be efficient. In general, cursors and temp tables weren't efficient and if there was another way around, we needed to code it that way.
They were skeptical, but they learned that I wasn't being hypocritical because over the next few months we had a few places where they were stumped with certain problems. We agreed a temp table solved some of them, and decided to implement it. I told them the rule still hadn't changed, and no temp tables would be allowed in other code. We could make exceptions, but it shouldn't be a tool on one of the lower shelves. This one should be a bit higher up, require the stepladder kept in my office, them to ask permission, etc.
I think that we should be effective in our jobs. Getting things done in a timely fashion is the most important thing, but we should also strive for some level of craftsmanship in our code as well. Throwing something together is sometimes necessary, but we can throw something together that has some stability. Something that is able to handle some stress or even just make a refactor easier at a later date. Or we can throw something together that wobbles like a child's bike assembled without wrenches.
Which would you prefer?
Follow me on Twitter: @way0utwestForum Etiquette: How to post data/code on a forum to get the best helpMy Blog: www.voiceofthedba.com
After being an avid reader of articles by Steve Jones and others of his ilk, I am always ready to learn from those who know more than I. But which one do I use? Oh so many ways... with all the sources available we can sometimes get buried under the google searches and the SQL code sites all offering 'The Solution' and depending on the situation, sometimes the expdient becomes the solution and the best solution is overlooked. We all have horror stories of impossible timeframes, impenetrable attitudes or last minute additions, these are part of doing what we as DBA's and developers have to contend with. But as with most things, I find, moderation being the key. Part of what I see as my role is to educate not only myself, but also those with whom I work. I'm not a guru nor a SQL god, but just a humble SQL Server DBA and VB Developer thats been keeping the wolf from the door using that one word. Just because I can do something doesn't mean I should. But that said, we only grow by experimenting and discovering. With that moderation in mind, the more 'arrows' I can put together the better off my working day will be. So where do we go from here ? With more and more functionality and bells and whistles, I keep reminding myself - do the Basics
1. Comment. You will not be the only one who reads your code.
2. Consistant. Be consistant in how you code, like naming variables - i & j for every variable is just takes the fun out my day !!
3. Complete. Complete the code, don't leave a return hanging (nothing assigned to it) or print statements like 'Something needs to go here Code = 9' Yup that a real one !!
4. Cursors. There is a better way.
Finally never be too afraid to ask the question - Is there a better way ?
CodeOn.. and thanks.
I go for quality rather than speed in delivery and I experienced this many times. Whenever we tend to write code fast to deliver early we receive tons of bug fixes of which many are design bugs that take sometimes double time to fix in order to properly work. For this reason, I vote for giving importance to the design and the way things are written. Minimal bugs will result from that and the code will not be patched hundred times.
I too wait for Steve Jones daily articles to learn new stuff to apply them in my code. Across the years, they broadened my knowledge and taught me many new skills.
I tend to overcomment. I agree with the philosphy of documenting why, but in practice it's often helpful to have a short comment that describes what you're doing because we think in English, not sql!