Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked
 
PerlMonks  

Seven habits of highly careful coders

by mandog (Curate)
on Sep 13, 2003 at 22:34 UTC ( #291302=perlmeditation: print w/ replies, xml ) Need Help??

With apologies to the other 7 habits people .

I work with a person who is often NOT careful in his work. Beyond that he does well. When he asks “How can I be more careful?”, We usually answer. “That is up to you to figure out” After some thought, I’m not sure this is the right approach.

Those of us who think of ourselves as careful and methodical sometimes assume this habit is innate. We forget what it was that made us careful. Perhaps it was a teacher who kept returning our work until it was without error. Perhaps was it getting tired of spending years of flailing around. Perhaps it was a textbook on mathematics.

Because we forget what made us careful, we assume people who are not careful can never learn this habit.

Here is a list of questions, a sort of checklist to help a person become more careful.

  1. Am I responsible for getting it right?
  2. Did I take the needed time?
  3. Did I read the docs well enough?
  4. Did I make a backup?
  5. How can I test this hypothesis?
  6. Am I following the reason for the rules?
  7. Did I read what is on the screen?

updated: removed non AsCII chars & added a missing verb



email: mandog

Comment on Seven habits of highly careful coders
Re: Seven habits of highly careful coders
by gryphon (Abbot) on Sep 13, 2003 at 22:58 UTC

    Greetings mandog,

    At my job, I've instituted a lot of standard coding practices for our department. Here are a few that I think are habits of careful coders:

    1. use strict;
    2. use warnings;
    3. Use CPAN for as much of the work as possible
    4. Use tainting when dealing with CGIs
    5. POD or otherwise document everything (if not in POD, have a good reason why)
    6. $CGI::DISABLE_UPLOADS = 1;
    7. $CGI::POST_MAX = 4092; (or some other appropriate number)

    gryphon
    code('Perl') || die;

Re: Seven habits of highly careful coders
by adrianh (Chancellor) on Sep 13, 2003 at 23:23 UTC
    Did I read what is on the screen

    After some particularly egregious mistake I made about ten years ago I added the following to the end of my .login script:

    echo "REMEMBER: place brain between eyes and fingers before beginning +to type..."

    It's advice I still need to read on a daily basis :-)

Re: Seven habits of highly careful coders
by Plankton (Priest) on Sep 14, 2003 at 03:25 UTC
    When writing code, imagine that programmers that will have to maintain your code are psychotic axe murders that know where you live!

    Plankton: 1% Evil, 99% Hot Gas.

      Personally, I find it better to imagine that I will have to maintain my code, six months from now. Finding the intersection between yourself and the psychotic axe murderer is left as an exercise for the reader...

      Chris
      M-x auto-bs-mode

Re: Seven habits of highly careful coders
by Anonymous Monk on Sep 14, 2003 at 15:30 UTC
    When I first read this title, I thought it was going to be a meditation on "defensive programming". When I think "careful", I think of safe practices. Wearing condoms, chroot()ing daemons and such.
    7. Did I read what is on the screen?
    This is tough to take seriously.

    -- am
      Not really.   I've worked with people who can describe at length what they are doing and why it works and how wonderful it is... but what they've typed in isn't that.   There is a pattern of failure, not seeing the actual code for the glow of what it was _meant_ to be.

      I've sometimes wanted to ask them to get up, walk around the room, sit down again and *read* what they've typed.

        By experience, I found out that my best coding used to come at ocassions when I lost my papers and I had to write all over again by memory...
      This is tough to take seriously.

      Not really. I've certainly spent many an hour in the past looking right at a buggy piece of code, but missing it because I'm seeing what should be there, rather than what actually is there.

Re: Seven habits of highly careful coders
by Theo (Priest) on Sep 15, 2003 at 01:13 UTC
    There are some folks who seem obsessed with the details of whatever they are doing and others that really don't even see that level of detail. It can be a personallity trait. Those who see only the details are not generally good at being in charge of a bunch of others, and those who are good leaders are frequently poor at details. It's important for people to work in areas where there personalities fit what they do.

    -ted-

Re: Seven habits of highly careful coders
by dthacker (Deacon) on Sep 15, 2003 at 02:37 UTC
    "...We usually answer. “That is up to you to figure out”
    Speaking as a person who always wants to improve, I would raise this simple point:
    1. The person who is asking you wants to be a better coder.
    2. You have information that will make him a better coder.
    3. Your irritation level will likely decrease if his code is better.
    4. His frustration level will likely decrease if his code is better
    5. Your workplace needs better coders.
    6. The universe in general needs better code.
    7. You gain nothing by withholding this information and much by passing it on.

    Dave
    Code On!
Re: Seven habits of highly careful coders
by bwelch (Curate) on Sep 15, 2003 at 15:08 UTC
    Relating this to recent projects involving updates and additions to other people's code, it reminds me of ways to both test legacy code and document my own.

    In testing legacy code:
    - Is it still in use? If not, why?
    - What's the scope? Exactly where will this work and where will it fail?
    - Is the author still around so I may ask questions?
    - Is it worth figuring this out and updating it, or would I be better off starting over?

    In documenting my own code:
    - What does this code do and why was it created?
    - Include a history section that documents changes and dates.
    - Add a simple outline if it's complex so it's easy to understand it without studying all the code.
    - Document the code assuming you'll be trying to understand it two years in the future and you don't remember anything about it.

      - Include a history section that documents changes and dates.

      Isn't this what change-control (such as CVS or SourceForge) is for? I would use CHANGES sections for release notes and keep version changes relegated to source control. Otherwise, the source file gets too cluttered up!

      ------
      We are the carpenters and bricklayers of the Information Age.

      The idea is a little like C++ templates, except not quite so brain-meltingly complicated. -- TheDamian, Exegesis 6

      Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

Re: Seven habits of highly careful coders
by johndageek (Hermit) on Sep 16, 2003 at 14:35 UTC
    Is the question "How to be a more careful coder" or the more general "How can I be more careful in my work?". One is much broader than the other.

    let's try a few broad rules

    1) Put the user's shoe on. Listen and understand what is being requested of you, and why it is imoportant to the requestor.

    2) First do no harm. Does everything you didn't intend to touch work just like it did before?

    3) Make personal back ups of all things to be changed BEFORE working on them. Paranoia is the basis of good programming, trusting backups of others is like asking someone else to do your tiedown in mountain climbing.

    4) Users shoes again - Test the software pretending you will be able to do your job ONLY through this software. test over and over. Remember those little annoyances that would make you crazy, will make the user crazy.

    5) No surprises. Pretend I am doing some work for you. When would you prefer to hear the following:
    I'm running late.
    It works differently than discussed.
    It's slower than anticipated.
    Your changes will affect the due date
    ** bad news early allows the user to plan accordingly, bad news late allows/forces the user to blame you.

    Good luck
    dageek

Four habits of somewhat careful sysadmin :-) [Re: Seven habits of highly careful coders]
by bronto (Priest) on Sep 18, 2003 at 07:27 UTC

    System administration is sometimes the art of solving problems of which you don't know the source. For that kind of problems, I wrote my own checklist based on my personal experience: it's a four-phase analysis I run through until I find the problem.

    • at first, don't trust the user;
    • then, don't trust the computer;
    • then, don't trust the OS;
    • if all this fails, don't trust yourself.

    Ciao!
    --bronto


    The very nature of Perl to be like natural language--inconsistant and full of dwim and special cases--makes it impossible to know it all without simply memorizing the documentation (which is not complete or totally correct anyway).
    --John M. Dlugosz

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://291302]
Approved by phydeauxarff
Front-paged by gjb
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (8)
As of 2014-12-26 20:01 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (175 votes), past polls