Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

Challenge Yourself Expand / Collapse
Author
Message
Posted Sunday, August 5, 2007 5:22 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Today @ 7:17 AM
Points: 31,080, Visits: 15,526
Ironman Challenge


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?

Post #388049
Posted Sunday, August 5, 2007 7:45 PM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Thursday, September 11, 2014 10:39 AM
Points: 2,803, Visits: 3,068
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.
Post #388053
Posted Sunday, August 5, 2007 9:42 PM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Thursday, September 20, 2007 10:10 PM
Points: 22, Visits: 1

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.

Post #388055
Posted Monday, August 6, 2007 1:19 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Thursday, September 13, 2007 3:20 AM
Points: 28, Visits: 1

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

Post #388065
Posted Monday, August 6, 2007 6:54 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Tuesday, October 29, 2013 5:29 AM
Points: 104, Visits: 721
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.
Post #388128
Posted Monday, August 6, 2007 8:46 AM


SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Thursday, May 16, 2013 3:56 PM
Points: 280, Visits: 140
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...
Post #388183
Posted Monday, August 6, 2007 3:40 PM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Thursday, September 11, 2014 10:39 AM
Points: 2,803, Visits: 3,068
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. :-(
Post #388304
Posted Monday, August 6, 2007 4:08 PM


SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Thursday, May 16, 2013 3:56 PM
Points: 280, Visits: 140
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.
Post #388310
Posted Monday, August 6, 2007 6:53 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Today @ 7:17 AM
Points: 31,080, Visits: 15,526
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.







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #388345
Posted Monday, August 6, 2007 7:18 PM
SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: Moderators
Last Login: Yesterday @ 2:30 PM
Points: 6,784, Visits: 1,899

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!



Andy
SQLAndy - My Blog!
Connect with me on LinkedIn
Follow me on Twitter
Post #388347
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse