April 15, 2002 at 7:56 am
Always think about the poor techie who may have to follow you. Your all singing all dancing Set-Oriented SQL may appear to be the cleverest most elegant solution at the time. However if it breaks and you're not around, the one who follows you will probably fix it, in time, but would definetely have fixed it sooner if you had made it simpler.
Cursor based solutions are not ALWAYS worst. They might run slower, or be less clever/elegant, but sometimes they are much easier to debug and correct (Sorry Andy! Set-based is normally but not always best)
I have found it is possible to please all of the people all of the time if you do exactly what they want. Harold Macmillan 1961
April 15, 2002 at 8:30 am
1) Do what you know. When you know better, do better. Make it a point to learn better 24x7x365.
2) Ask someone who isn't a pro to look at your work. Sometimes sitting through a bunch of stupid questions can lead to a couple of really good ones. Naivety can be as beneficial as experience.
3) Question everything. Most IT shops are stovepipes. Standards are necessary for consistency. However, we live in a world of constant change. The app we released yesterday is already old news. Keep the standards updated.
4) Use discussion forums/threads. They give you a nice variety of style and concept that you can't get any other way.
5) Learn your client's business. Client's are never going to learn about what you do, so it's up to you to bridge the gap. I routinely tell my clients how to run their businesses. If they shoot me down, at least I can say "I told you so". Too often, client's decide what they want to offer without asking ops how it will be supported and then once ops figures it out, IT is left to clean up the mess. Sometimes, we can't do it effectively or efficiently and the client is left wishing they had requested "Not for Profit" status.
6) Think ahead. Build apps like you will die tomorrow and no one will be around to understand or support them. Make sure the client can control as much of the app as reasonable, add in functionality that they may not use now, but you have that strong feeling they will want later - disable it to start, then enable it when they call. They'll think you hung the moon!
7) Embrace new technology with caution. Remember DIVIX?
8) Don't take things personally. Most people will never have a clue about the intricate nature of what we do. It's as confusing to them as brain surgery or rocket science. They don't understand the difference between what you did wrong and what they did wrong. They just know it's broken. Hold out for the kind words and take those to heart.
9) Document everything. If you do what's in writing, you can at least get Unemployment when Mgmt. fires you for their stupidity. It also serves as a lovely reminder for why you did what you did when someone questions it down the road and you're tempted to change it.
10) Learn to love change. Something about your life changes everyday (even if it's just that you got older between yesterday and today) and you learn to get over it. Apply that same philosophy to work and it makes the day go by so much easier. Never assume that what you did yesterday will work for today and you'll keep some of your sanity (cause you need it much more when you get home and your toddler has colored your freshly painted walls with your $20 tube of lipstick and wants you to tell them what a good job they did).
April 16, 2002 at 3:19 pm
As a developer or DBA, the most important think you can know is "where to look". You don't know everything. You can't know everything so don't try; that is what documentation is for.
I can't tell you how many times I looked up the syntax for a RESTORE DATABASE statement before I started trusting myself to memorize it; I am sure that it saved me several bad situations as well.
Bryant E. Byrd, MCDBA
SQL Server DBA/Systems Engineer
Intellithought, Inc.
[font="Tahoma"]Bryant E. Byrd, BSSE MCDBA MCAD[/font]
Business Intelligence Administrator
MSBI Administration Blog
April 18, 2002 at 3:06 am
Write code so clearly that you can still understand it in a year.
That way, someone else will.
Jon Reade
Jon
April 18, 2002 at 3:08 am
If you can't explain how it works, there's probably a better, simpler, clearer solution which you should adopt instead.
Jon Reade
Jon
April 18, 2002 at 3:22 am
Every program can be shortened by at least one statement and contains at least one bug, from which - by induction - one can deduce that each program can be reduced to a single statement which doesn't work.
Ergo: Murphy was right, and you'd better remember it.
April 18, 2002 at 6:46 am
"Count the pennies and the dollars count themselves." A little bit of I/O, network traffic, memory, etc. saved whenever possible will make a difference in the long run.
April 19, 2002 at 5:11 pm
Please follow these, it always helps
1. INDENTATION
2. Define all variables at the very top
3. Document history of changes, at the very begining
paul
paul
April 22, 2002 at 7:49 am
Know your business. Keep in mind that business is more important than technical. Don't do anything just because you saw it in some forum or magazine. Think how it will affect your business.
Give me a fish, you feed me for a day! Teach me to fish, you feed me for a life time.
April 22, 2002 at 6:37 pm
After logging into Query Analyzer make sure you are in the right database before issuing any query especially DDLs, and DMLs.
This is very true when the same user shares multiple databases on the same server.
Or always use USE <database_name_you_want> without fail.
Viewing 10 posts - 16 through 24 (of 24 total)
You must be logged in to reply to this topic. Login to reply