September 18, 2014 at 10:24 am
Please write these in stone. It's worth it. Great job.
September 18, 2014 at 10:26 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.
Yeah, sometimes the dumb answer is the right one (not that you are dumb, Colin, but shoehorning 11 into 10 required a little dumbness on my part).
I would argue that 5a is really a sub-commandment of 5 since it primarily applies to what should be done when 5 happens. However, as someone else pointed out, "Step away from the keyboard" is good advice on other occasions as well, such as when given a new task.
September 18, 2014 at 10:36 am
Ed Wagner (9/18/2014)
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."
It ain't ever done. It's just on hold for a bit... 😉
Well, maybe there are a few applications that are genuinely complete and perfect and "done" (and not just because they are limited in scope). Doubt that the number is above 9... I've never written one !
Still, I agree with the premise that the form is (often) an important part of the function... Arkanoid was way better than Pong despite being functionally the same game.
September 18, 2014 at 10:38 am
Gary Varga (9/18/2014)
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:
Did I really need to include RTFM ?
(Or, as I express to my daughter before she does a test, "Read the Question before you answer it")
😀
September 18, 2014 at 10:41 am
SimonHolzman (9/18/2014)
Gary Varga (9/18/2014)
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:Did I really need to include RTFM ?
(Or, as I express to my daughter before she does a test, "Read the Question before you answer it")
😀
Ouch!!! Who reads the numbering? 😉
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
September 18, 2014 at 10:58 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.
If the documentation is not in the code it will NOT be maintained and it WILL get lost. If you want to document it elsewhere, great and good and there are many wonderful tools for exactly that purpose. BUT, one day some poor schlub (who might be yourself) is going to have to fix the program and they will primarily rely on the documentation built into the code.
My intention was not to stop people producing other documentation, it was to ensure that they do not neglect the in-code documentation because they have a stack of Specifications, Entity Relationship Diagrams, Requirement Lists, Manuals and Printouts. Oh, and do not EVER run a utility that strips out all of the comments from your code. If someone wants to steal it, they can do that with or without the comments, but you do not want to experience the embarrassment of trying to fix your own code after the only copy had the comments stripped out (not me, but a good friend !)
OCTom (9/18/2014)
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.
You are right, I expressed that one badly and did not give as much detail as I should have.
When I referred to hard-coding Public Holidays, I did not mean for them to be specified in the code - a Lookup Table is the ideal approach. My point was that it may be possible to calculate the dates of the Public Holidays into the future, but it isn't worthwhile, especially since they could change. Thus, a lookup is a better approach.
I also failed to mention the proviso that, if you do use this approach, you must have a way to alert the users when the information expires or for the users to know what information is hard-coded. Thus, when the lookup has no more dates in the future, you could display an alert stating that the Public Holiday list needs to be updated. Similarly, if you have a hard-codes sales tax rate (this was often done in Britain in the 80s), there should be something that states the rate being used without the user having to go an look for it, perhaps a confirmation prompt or an on-screen display.
September 18, 2014 at 11:13 am
crussell-931424 (9/18/2014)
Very good list, though I'm sure there are other items. But to address your list in light of my experience, here are some comments.7 - Don't multi-task. This is not possible in my job. There are always many small yet hot items that come up throughout the day. We need to be able to stop what we are doing and help. There are others that have come to a stand still until we step in and provide a solution or some kind of direction.
That is actually my point. Stop what you are doing and do the other thing. Do not try to do two things at the same time (including having two applications open that you are doing development work on - close the first before opening the second to avoid accidentally typing into the wrong window, for example). Occasionally it is not possible to do this... All "Commandments" have exceptions.
crussell-931424 (9/18/2014)
9 - Put on that user hat and test like a user before passing it off to testing. I know the old saying that we will simply supply the expected input. But with a little effort we can pull ourselves out of that mode and try to break our own code. The better we get at this the better we get at programming it in the first place, thinking about how to plug the holes from the get go.
You have to actually test your own code, of course. And you will try to test it like a user does. BUT, you do need it to be tested by a real user (or more than one, if possible) before you can consider it ready to be released. And, working with the users while they test it can sometimes give you insights that you would never have gotten otherwise.
On a related note, I love prototyping - releasing applications as version 0.5 initally - most of the core functionality with as few bells and whistles as possible. It is surpising how often functionality that the users demanded when the application was initially specified turns out to be unneeded and how often something that no-one thought would be a problem becomes a serious annoyance. Releasing a version that is explicitly unfinished allows you to get away with doing this and the knowledge gained makes the final version better and it is usually produced faster as well.
September 18, 2014 at 11:20 am
crussell-931424 (9/18/2014)
OCTom (9/18/2014)
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
That reminded me of the time I put a shortcut in my code back in the early 80's having to do with a date. Another programmer asked me about the obvious problem it would cause when the year 2000 arrived. I told him that this software would be in use in 2000 so not to worry about it. Well as you've said above Tom, it's still in use today, corrected of course.
There was one application where the developer got grief because they had calculated leap years by dividing by 4. It took three hours to convince the Y2K supremo that this was not an issue in our lifetime. The Y2K supremo had the 100 and 400 year nuances the wrong way around.
On the other hand, I work with an application that does automatic scheduling sometimes and we still have issues on February 29th since that date doesn't exist in a year's time... <sigh>
September 18, 2014 at 11:28 am
lshanahan (9/18/2014)
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.
My mentor, Paul Collingwood (not the Cricketer), taught me your number 13 (.5) ... He would allow us to spend an hour arguing about how/why/who/when/whatever but, at the end of that hour, it was his job to make the decision and my job to what I was damn well told. Usually, he was right. It was also his job to accept responsibility when the smelly brown stuff hit the rotary air displacement tool, which is why he was my mentor rather than just my boss. I try not to be much of a boss either.
Maybe number 14 should be "It is just a job."
September 18, 2014 at 11:39 am
I really like your step 5a, "When you make a mistake - STEP AWAY FROM THE KEYBOARD". Now, honestly that might not always be possible. There could be people standing around you, requiring you to "sit there until it's fixed". But if you can, stepping away to think about what's happened and why, might save frantic attempts to speedily fix a problem and possibly just making it worse.
Rod
September 18, 2014 at 12:00 pm
Doctor Who 2 (9/18/2014)
I really like your step 5a, "When you make a mistake - STEP AWAY FROM THE KEYBOARD". Now, honestly that might not always be possible. There could be people standing around you, requiring you to "sit there until it's fixed". But if you can, stepping away to think about what's happened and why, might save frantic attempts to speedily fix a problem and possibly just making it worse.
In my experience, stepping away is expecially helpful when there are other people around and actually increases their respect for you - By all means, be honest and explain what has happened and why you need to take a moment before diving in to fix anything. That will help sooth the other people so that they can calm down as well. After all, the main reason your boss stresses out about a mistake that you make is because they are afraid for THEIR job. Yours may already be toast as far as they are concerned, but they don't want to join you under the bus. If you can calm everyone down, work out a practical solution, implement it and then provide your boss with some practical suggestions on how to avoid similar issues in the future (or explain why there is no practical way to prevent similar issues in the future), you may get promoted instead of fired.
If you do work in the sort of environment that demands that you "sit there until it is fixed", find another environment. Even if you are working on software that is really a matter of life and death, there WILL be errors. Unless your name is "God", you are not perfect and will make mistakes. So will everyone else. An environment that does not accept any mistakes is corrosive because there is no way to avoid all of them. The end result will be huge turnover in staffing as people are fired for their mistakes, which prevents anyone actually learning from their mistakes and improving.
September 18, 2014 at 12:08 pm
I'm sure there's a commandment missing.
STUDY. You'll never finish to learn. There's always something else that you must learn and that's why studying is so important. When we're not moving forward, we're moving backwards.
September 18, 2014 at 12:20 pm
Luis Cazares (9/18/2014)
I'm sure there's a commandment missing.STUDY. You'll never finish to learn. There's always something else that you must learn and that's why studying is so important. When we're not moving forward, we're moving backwards.
I think that puts us up to 15 or so...
You are right - there are so many new functions and tools that beginners know about which us old fogies do not because they were not available when we learnt so we had to develop our own ways to perform that task and have never thought to see what new options are available.
A related commandment might be "TEACH". Explaining why you changed the design to the User or suggesting some alternative ways to do something can make a huge difference. In the mid 80's, I worked in an office that used a Word Processor instead of typewriters and the secretary's spelling was not as good as it could have been so I asked her why she did not use the "Spell Checker". And then I had to explain what one of those things was. Things that are obvious to us are not always obvious to the users.
September 18, 2014 at 12:53 pm
SimonHolzman (9/18/2014)
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.
Good Point! Almost anything is possible with sufficient budget. Followed by "...now lets discuss our project priorities..."
The more you are prepared, the less you need it.
September 18, 2014 at 1:07 pm
The first 4 are great. The fifth one should be 'Assume you will make mistakes'
Number 6 and 7 are fine. The last three need new headings or dropped.
Those are my thoughts.
Bob
Viewing 15 posts - 31 through 45 (of 54 total)
You must be logged in to reply to this topic. Login to reply