Challenge Yourself
-
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?
-
I agree with you. That is the reason why I visit this website so often so I can learn something, or someone can help me to solve a problem with much better solution.
However not everyone thinks that way, some people even have a template and they use it to write procedure, they know that way will work, they don't care to find a better way. Actually this is the way my other teammates work. 🙁
I just feel so boring to work with this kind of people.
-
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.
Thank you
-
I go for quality over speed myself too. My motto is code will be written once and used many times thereafter, will a few extra hours/days/weeks/etc of development really impair anything.
-
Very true. That supports a lot of what I've been saying in the C#/C++ wars. If you challenge yourself to learn C#, and then you still think it's crap, then fine... but I don't put any stock in the opinions of people who haven't tried it. I challenge myself in many ways with hobbies stuff, but at work I'm pretty reluctant to try new things sometimes. I usually end up doing it eventually when I realize that the new thing would have saved me a lot of grief. I have to balance quality and speed of development though, because I am usually behind on my work... ugh...
-
After all these years, I am embarrassed to say that I don't write too much comments in my procedures.
I try not to use cursor, probably because when I first learned SQL Server SQL, every time I wrote a cursor, the DBA cursed me and refused to put in production until I changed it so I just used not using it.
When I write my code, I try to make it easy to read also try to make it more generic and dynamic. For example when I created the reporting system, I wrote the procedure and the DTS package so when I add a new report, it did not need to change anything. The developer did not need to write a new DTS package to extract the data and put it into the table. The generic procedure I wrote taking care of it. All the developer needed was putting the report, the format file, the report file, the table name into a Reporting table. Also the DTS package I created, when the DBAs moved from one server to another server, they don't need to open the package and changed the server name. I had an environment table. It would read the table and change the server when it ran the package.
This kind of things challenge me, how to make the procedure easy to change or more dynamic, how to make it run faster, what kind of index I should put in the table to get the best performance.
Of course my manager and my company disagrees with me, they just want more and more projects put in production as fast as possible, who cares about hard coding, as long as it works, that is fine. 🙁
-
I don't either. Comments are only for the purpose of documentation, not explanation. If someone is reading the code and they can't tell from the code what it's supposed to do... then they don't really know the language do they? After all, that's what code is for... it IS an explanation of what the computer is supposed to do.
A lot of times, I will find myself wanting to put a comment like "has to be done this way because of FK in table X" - and I realize that what's really going on is a case of bad design, and luckily I'm usually in a position to fix that. If not, then yeah the comment is appropriate.
-
I tend to agree with Jasmine. I comment stuff that isn't inherently obvious about why the code is written this way. A business rule, fix a bug, etc. I expect whoever follows me can read the code.
I do drop a note when something changes, usually "fixed bug" so that if it breaks something else, the next person can tell something was changed on xx date.
-
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!
-
Naw, I think in SQL just fine. Steve mentioned business rules and that is another good thing to comment, but that's part of documentation, not explanation of the code. It's pretty important to document why you did something especially if you did it in an unorthodox way.
-
But only if it's not obvious. Don't want to read comments about "used a left join because we have missing rows"
Use something like "some orders don't have a shipper, so left joined with Shippers table"
-
I suppose in comment on the reason for this post is to 'Challenge Yourself'. Not only in those things we thought we knew, as software changes and evolves, maybe some idioms are no longer valid. I've been using SQL Server since Sybase was sucked up into the MS stable and there are still more things to learn (Thankfully !). I thought that I knew dates but Itzik Ben-Gan's articles on Datetime calculation were a cool breeze throught the dusty portions of my briefcase. So I suppose the challange is being open and prepared to be challanged. and for those wondering ....
Last Monday (inclusive)
SELECT DATEADD(day, DATEDIFF
(day, 0, -- Base Monday date
GETDATE()) /7*7, 0); -- Base Monday date.
Pure genius....
CodeOn
-
I've always thought that comments were a description of what you intended the code to do. You don't get this info by reading the code - you just get what the code actually does.
There is no problem so great that it can not be solved by caffeine and chocolate. -
Hopefully they're the same thing
I think that most comments are what you intend the code to do, but not explaining what a knowledgable person should be able to decipher. There should only be comments on something that's not obvious.
Or I sometimes make comments on a change in behavior as a reminder to myself or someone that comes along later.
Viewing 15 posts - 1 through 15 (of 16 total)
You must be logged in to reply to this topic. Login to reply