September 18, 2014 at 5:15 am
Ah yes, completely missed that 5a.
So 10.5 means ten and half commandments.
So 5a is half a commandment.
I guess, once you reach 11 you can't pretend to have 10 any more.
Thus if you have 10 of something you can call them commandments - to get people to laugh.:-D
Otherwise it's just a list of things...
OK.
September 18, 2014 at 5:19 am
Yup. You got it...
September 18, 2014 at 5:34 am
I'd say those are right. I also like the one in the forum about not rushing in with a knee-jerk reaction.
The one I would add is a Modenism: "Make it work, make it fast, make it pretty. It ain't done until it's pretty."
September 18, 2014 at 5:51 am
Loved it, especially 5a. I wish someone could have helped me get this in my head about 20 years ago. I'd probably have a lot more hair left.
September 18, 2014 at 6:13 am
Well written. I like number 9 especially. I can't tell you how many times I've said that no matter how much I test a new piece of code it isn't fully tested until the users get their hands on it!
September 18, 2014 at 6:20 am
robertm-772679 (9/18/2014)
Well written. I like number 9 especially. I can't tell you how many times I've said that no matter how much I test a new piece of code it isn't fully tested until the users get their hands on it!
Having a good idea of how end-users use your software is often difficult to obtain.
And yet it's vitally important to have this information to do effective testing.
September 18, 2014 at 6:22 am
colin.counsell (9/18/2014)
He wanted to make the analogy to the biblical '10 commandments' but he actually had 11 points to make, so squeezed another one in as 5a.I don't think it's any more complicated than that.
Ah!!! I read each in turn assuming that the numbering was sequential from the first one I saw (1) until the final one (10) and paid little attention to the numbers. I think that as I was focussed on the content random numbers could have been employed and I might not have noticed. Or a list of 13 items. :blush:
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
September 18, 2014 at 6:42 am
I only have a couple of issues:
3. Documentation in code... So, if a non-programmer needs to know what's going on and does not have access to the code, how are they supposed to get at the documentation. Documentation is not only for developers, it is for those who need to know how to install it, how to perform any set up. Put documentation in a repository so those who need it can get at it. Word and Visio work great for documentation.
8. DO NOT EVER hard code dates. Or, most anything else. EVER! (Yes. I did intend to shout). When the program fails and you are not around, it will be bad for whomever is around to handle the issue. Put them in a table and reference that. And, don't calculate dates for only 10 years. Programs I wrote in 1989 are still in use. Do not assume that your code will be replaced within a certain period of time.
Tom
September 18, 2014 at 6:51 am
OCTom (9/18/2014)
I only have a couple of issues:3. Documentation in code... So, if a non-programmer needs to know what's going on and does not have access to the code, how are they supposed to get at the documentation. Documentation is not only for developers, it is for those who need to know how to install it, how to perform any set up. Put documentation in a repository so those who need it can get at it. Word and Visio work great for documentation.
8. DO NOT EVER hard code dates. Or, most anything else. EVER! (Yes. I did intend to shout). When the program fails and you are not around, it will be bad for whomever is around to handle the issue. Put them in a table and reference that. And, don't calculate dates for only 10 years. Programs I wrote in 1989 are still in use. Do not assume that your code will be replaced within a certain period of time.
Tom
In a recent editorial (http://www.sqlservercentral.com/articles/Editorial/65439/) we discussed comments and many people agreed that documentation should be part of the related artifacts where possible. For code documentation that means inline comments, however, a system needs overall documentation too.
Oh and I am with Tom on the hard coded dates. You can always soft code them into a file or a table which is setup manually but can be changed WITHOUT a code change and deployment.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
September 18, 2014 at 7:44 am
This very nicely sums up just about everything I have learned in nearly 30 years in this business. Many thanks!
September 18, 2014 at 8:39 am
If I may be so bold as to add a couple:
Grin and Bear It - Sometimes despite all your informed, documented reasons why a certain course of action is unwise if not downright stupid, people who make more money than you do will insist upon taking it. Sometimes you have to salute, say "Aye-aye Cap'n Bligh" and do what is requested. (Yes, that has limits but I think they're obvious).
Which leads to the corollary: Thou Shalt Keep a Mop and Bucket Handy. When the above happens be ready to clean up the mess when the train wreck hits.
And can I give a hearty "AMEN" to no. 6? I'm smack in the middle of one of these now with overtones of the two above.
It ain't pretty.
____________
Just my $0.02 from over here in the cheap seats of the peanut gallery - please adjust for inflation and/or your local currency.
September 18, 2014 at 8:58 am
Shhh, these are like the secrets of the magician. And now they are out.
The more you are prepared, the less you need it.
September 18, 2014 at 10:08 am
xsevensinzx (9/18/2014)
Someone forgot an important commandment that a lot of people get their feet shot off for.That's being honest. When someone asks you if you can do something or if some cool new awesome thing can be done, then be honest if you can do it or if you SHOULD do it.
A very good point... My response is often "Of course I CAN, but..." because 'No' is not usually an acceptable answer although it is sometimes necessary. Instead the best option is usually to identify what the user is trying to acheive and then discuss with the user different ways to acheive this or whether it is actually worthwhile at all. Often they realise that they are asking the wrong question. Sometimes, they accept that it is simply not practical to answer the question no matter how good it is. Occasionally, they convince you that they really do need that answer and you have to find a way to make it happen. Those are the good days !
September 18, 2014 at 10:12 am
Michael Meierruth (9/18/2014)
Forgive my ignorance, but I can't quite grasp the (.5) in 10 (.5)?I tried to lay back and relax and read that thing.
I tried to lay my head down to the left - then to the right.
I tried taking a deep breath.
I even closed my eyes and tried to read it from my brain.
I tried reading it with sun glasses.
😎
All to no avail!
The .5 is the point that when you fail
and, despite your best, a mistake is made
a sub-command or contingent advice
is to wait a bit before trying a fix.
September 18, 2014 at 10:19 am
colin.counsell (9/18/2014)
I would add no 11.When given a new piece of work, study the requirements, then do nothing for a while. Step away from the keyboard (again!). Lean back in your chair and put your hands behind your head. Look out of the window if you have one. Use the time to think about what you've just studied and how you are going to about it. Formulate a plan in your head. Write the plan down if you prefer, but whatever your method, think it through properly. How often have you seen a junior programmer read the specification you've given him/her and then launch straight into the coding, which invariably leads to poorly constructed code which needs re-working.
Spend some time to think about it and plan it first, then hopefully you can achieve commandment number 1. Be lazy and get it right first time.
Very true. We're up to 12(.5) now !
One tool I find useful here is to talk it over with someone or, if necessary, something. They don't need to understand what you are saying (or to be sentient), but the act of explaining the requirement out loud usually helps me to simplify my understanding of it and focus on the basic design without being distracted by the details.
Viewing 15 posts - 16 through 30 (of 54 total)
You must be logged in to reply to this topic. Login to reply