Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot
 
PerlMonks  

Tricking Our Egos

by dws (Chancellor)
on Feb 15, 2001 at 15:02 UTC ( #58597=perlmeditation: print w/ replies, xml ) Need Help??

Many of us have blind spots when it comes to reviewing or debugging our own code. We readily see problems in others' code that we're blind to in our own. We know what we just wrote, but our brains can't let go of our intent long enough for our eyes to really see what our fingers just typed. Peer review is the standard way around this, but often we're working alone, without ready access to qualified reviewers, and need to go it alone. Somehow, we need get our minds into a place where we can get past our blind spots.

Several years ago I picked up a way to trick my ego into getting out of the way. I offer it here in the hope that it'll resonate, or at least get others thinking.

My trick is to imagine that I had a fever when I wrote the code I'm now looking at, and that someone else had looked at it and pointed out that there were problems, but hadn't explain what they were.
This has a couple of effects. First, it gets my brain out of "there's no problem here" mode and into search-and-destroy mode. I really, really don't like having others find bugs in my code. (It's that damn perfectionist upbringing.) And to have somebody spot a bug and then not tell me... that gets me fired up even more.

By imagining that I'd had a fever, I sidestep overconfidence, and open my mind to the possibility that I was actually fallible at the time my hands were busily typing. I also pre-excuse myself for any problems that I find. (When I run a fever, my mind can play some mean tricks. I've learned to triple-check anything I try to do while sick.)

Thus tricked, my ego stays out of the way long enough for me to find lurking problems. When I remember to use this technique, my code comes out a lot cleaner.

That's what works for me. What works for you? How do you get your ego our your way?

Comment on Tricking Our Egos
Re: Tricking Our Egos
by arhuman (Vicar) on Feb 15, 2001 at 15:13 UTC

    Interesting point of view, especially the 'psychological' aspect ('fever' excuse).

    And even If I'm sure it works, for my part I rather use a methodical approach :

    1) Don't assume everything even OBVIOUS things
    2) Find where the code begin to diverge from what is expected.
    (I use a kind of dichotomic process with print to ensure that the values produced are those expected until I find the point where it begins to mess)
    3) print is the coder's friend.
    print everything possible during each step around the spot where you think the problem is...

    But as I've discovered that the psychological aspect is VERY important.
    I try to handle it like a challenge (finding bugs IS A GOAL); I've decided that coding with bug is normal(ie: I'm normal ;-) and that finding bug quickly is a skill...
    This used with my formal method helps me to debug my code with pleasure (I'm improving my skills) and without a 'ego lock'...

    As you see even if our excuse (for not being 'guilty' of finding a bug) is different the point is that we only have to manage to believe it, to prevent 'ego lock'...

    Sorry but my poor english doesn't allow me to translate 'ego lock' efficiently, anyone got an idea?
      'ego lock' is great. Maybe 'blinded by ego' or something would be more conventional, but it would not be an improvement.

      p
Re: Tricking Our Egos
by MeowChow (Vicar) on Feb 15, 2001 at 16:47 UTC
    I don't think I have ego tricks. When I find myself confronted with a problem that I'm unable to resolve, I just go do something else for a while, so that I'll have to re-acquaint myself with the problem when I return. Since I tend to forget things rather quickly, I'm often lucky enough to have forgetten the mistaken assumption that impaired me from solving the problem in the first place :-)
       MeowChow                                   
                   s aamecha.s a..a\u$&owag.print

      I'm sure I'm not the only one who finds that explaining the problem out loud to another programmer often gets me past blocks like this.

      --
      <http://www.dave.org.uk>

      "Perl makes the fun jobs fun
      and the boring jobs bearable" - me

        I've heard this referred to as the `mannequin effect', so named because it would appear to be useful to have a mannequin on a trolley that one could simply get up, go fetch, and talk to about the problem (as opposed to bothering a presumably busy human about it).

        Update: Of course, the mention was right here on PerlMonks (not Advogato as I'd previously thought). See this node, by lemming.

(ichimunki) Ego Tricks
by ichimunki (Priest) on Feb 15, 2001 at 18:44 UTC
    Two things I've learned:

    1. Write all code as if someone else is going to have to go through it without your assistance. I made the mistake of assuming no one would ever see the backend code to something I wrote. Completely wrong. It's no fun having someone actually laugh at you for routine or variable name choices-- even if you find out later that you're a better programmer than they are.

    A consequent of this mindset is that you have the ability to go back into code later and expect that you don't have to dredge through frail memories of why you did what where.

    2. Ego? I make enough completely stupid mistakes that I figure every bug is my fault, even after I've tested it upsidedown, backwards, and inside-out. It's actually a relief to run against some undocumented feature/failing of a language, module, or (most often in my case) database interface application.

Re: Tricking Our Egos
by mothra (Hermit) on Feb 15, 2001 at 19:06 UTC
    That's what works for me. What works for you? How do you get your ego our your way?

    I don't think debugging your own code is so much an ego problem as it is a problem with tunnel vision. When you initially apply yourself to coming up with the solution to a problem, each person develops there own perspective on the situation and it can be hard to get out of that.

    When I debug my own code, "ego" isn't generally an issue. It's usually a matter of methodical elimination of everything that's working properly, to get to the stuff that ISN'T working properly.

    For example, I'm working on a Powerbuilder + ASE application right now. Often the bugs come in the form of data not being correctly displayed, often due to not retrieving the right data to begin with. To eliminate this, I'll step through to the point in the code where I'll see something like:

                   ltr_procs.p_someproc(param1, param2, param3, ..., paramN)

    This is an object through which stored procs (ie. p_someproc) can be called. At this point I'll open up my SQL Editor, connect to the database, and exec the proc with the parameters it's getting passed when I step through, having in mind what data to expect, and comparing it to what actually gets returned. From here, I'll place SELECT's within the SQL code at critical points until I see that the results are no longer making sense.

    I seem to do this at LEAST once, if not twice a week, and it always works like a charm. :) So in conclusion, my advice (and my practice) is to forget about ego, and concentrate on developing debugging skills that will leave nothing to chance.

Re: Tricking Our Egos
by Albannach (Prior) on Feb 15, 2001 at 19:31 UTC
    I really like your idea and will certainly try it! If I can still fool myself by setting my watch fast then your trick is sure to work on me.

    One thing that I learned long ago from a venerable old C hacker I worked for was the simple yet for me effective admonition that goes something like: "never stop at one bug" - I can still hear this in my head when I'm debugging (and no, the meds haven't helped ;-)! I have evolved two ideas from this:

    • if you're reading code and see something wrong (or you think is wrong), don't just "fix" it (possibly breaking it or something else more in the process) but keep reading until you fully understand what is going on.
    • even if you do fully understand a bug and fix it, keep looking as there could be more than one (well not in my code but there are people... ;-)
    This was great advice back when compiling almost anything was at least a "get a coffee" event, if not a "come back after lunch" event, but I think this approach still saves me time even today when most of my stuff compiles in seconds. I often see people find a bug/error, edit the code to fix that one thing, then re-compile/run to get the next bug/error... that gets me cranky!

    --
    I'd like to be able to assign to an luser

Re: Tricking Our Egos
by merlyn (Sage) on Feb 15, 2001 at 20:06 UTC
    The trick I've used is no trick: 90% of the code I've written over the past 10 years has been on public display one way or the other, so I get a very public code review every time. I also end up explaining most of it in what I hope are simple terms, so if it's too hard to explain, it doesn't stay.

    And then there's the constant fear that some of my worst code will end up as evidence in a future court appearance. That's not an irrational fear: it's already happened. The stupid port-bender code I wrote to permit me to get my Intel mail while I was outside the firewall ended up as part of evidence, and it's some of my worst-written code (it was a quick hack!).

    So I now write like someone's looking over my shoulder. Always. {grin}

    -- Randal L. Schwartz, Perl hacker

Re: Tricking Our Egos
by lachoy (Parson) on Feb 15, 2001 at 20:38 UTC

    If you've ever worked with a smart programmer looking over your shoulder as you code, you may find later that his or her presence sticks around far longer than the actual person. I had an extremely good experience coding/designing/documenting closely with another programmer for only a week and find that, when needed, I can call him up to sit on my shoulder (like those angel vs. devil images) and tell me how to work through a problem or untangle a knotted design.

    (That sounds kind of weird. It's not, really, just a form of talking to the cat or thinking yourself to have a fever just to say out loud what you're thinking.)

    I think XP's reliance on pair programming is one of its most attractive features. Even if it's one of the most difficult to implement since many people think of their code as art that can't be defiled.

    Chris

    M-x auto-bs-mode

Re: Tricking Our Egos
by extremely (Priest) on Feb 15, 2001 at 22:06 UTC
    I try and mentally explain the code to my mom. Seriously, if you can explain what the code does and why to your mom, you likely aren't doing anything that you are uncertain about.

    --
    $you = new YOU;
    honk() if $you->love(perl)

      Yeah, but how does this help me when I'm trying to write CGI scripts for my pr0n site? =)

      Philosophy can be made out of anything. Or less -- Jerry A. Fodor

        Then try and explain it to Nina Hartley or Julie Strain's Mother. =P

        --
        $you = new YOU;
        honk() if $you->love(perl)

      My dad used to explain his problems to the dog.
Re: Tricking Our Egos
by LD2 (Curate) on Feb 15, 2001 at 23:10 UTC

    I think that's an interesting idea... I may try that next time. :> But, I usually do one of two things..

    • Hack at it - which is not the best of ways..
    • OR take a break from it and work on something else.. and when I come back to it with a fresh start.. I can most often times find my errors.

Re: Tricking Our Egos
by ok (Beadle) on Feb 15, 2001 at 23:35 UTC
    Step 1 Accept that I am a moron.
    Step 2 Accept the counsel of another programmer.

    Egos are just obstacles to productivity and learning. If you were the best in the world at anything, we'd know it by now.
Re: Tricking Our Egos
by jynx (Priest) on Feb 16, 2001 at 02:47 UTC

    Thinking about it, i suppose that is a proper way to explain what is happening for a lot of programmers when they debug. Don't know if i qualify as a programmer but i usually try something like the following:

    1) make every block of code simple and direct
    A block of code can be a subroutine, a script, or sometimes just one line. Just make sure that that block does exactly what it says and no more (this usually requires double checking while writing the code)

    2) when debugging, find the blocks of code that relate to the problem
    Since we know that blocks of code only do their one thing (hopefully well), we can narrow it down to certain parts relatively quickly

    3) Pat yourself on the back for the blocks of code that didn't cause a problem.
    This is an ego boost for a job well done, at least on part of the code.

    4) Triple check that your solution worked
    This will assure that you will have less problems next time something goes wrong

    5) Look for the next bug
    It's probably in that block that didn't have an error last time, but now you can pat yourself on the back for a different piece of code.

    Me thinks my main problem is that i will always assume there are unsolved bugs in my code, even when it's fully working, even if it's only one line. So patting myself on the back is a way to get myself to continue since i'll know that at least one piece of code is ok.

    to each their own, TIMTOWTDI
    jynx

Re: Tricking Our Egos
by Lexicon (Chaplain) on Feb 16, 2001 at 05:35 UTC
    This actually reminds me of a book called "The Ecstacy Club". I recommend everyone read it, of course. The relevant part is one of the characters was brainwashed so that, upon receiving a stimulus (seeing a certain number, IIRC), he would forget the last few hours or so.

    Being a programmer, the guy started using this to help him develop code: whenever he couldn't find a bug he'd flash himself so he could have a fresh look at it. ;)

    -Lexicon

Re: Tricking Our Egos
by Nooks (Monk) on Feb 16, 2001 at 06:17 UTC
    A friend of mine writes all his code as though the -T switch was turned on: he tests all user input, cleans the environment, so on and so forth. Then, when he thinks he's done, he runs the code under -T to see if there would have been problems.

    This doesn't find all bugs in all code, but it appears to help---many subtle bugs can pop up in Perl because of incorrectly checked user input.

    Personally, I prefer to cut and paste the code somewhere else, (or check it in to a branch with CVS or RCS) and rewrite what I think is incorrect. This helps me find stuff like testing for equality with `=' or `eq' where I should have used `=='.

Re: Tricking Our Egos
by Anonymous Monk on Feb 16, 2001 at 08:49 UTC
    The easiest trap to fall into when trying to figure out what's wrong with a piece of code is to look for all the things that are right with it. It goes something like this: "Okay, if $i is zero we'll get through this loop okay, ... the substitute will change the 'barf' in $string to 'arf' ... yeah ... and when it gets here it should print 77 ... right." This mental dialog always ends with, "Well, shoot, that should work!" If I ever find myself saying this, I know I need to back up and realize, "Hey, it doesn't work, that's why you're going through this in the first place!" That's usually enough to kick me into a different groove.
Re: Tricking Our Egos
by danichka (Hermit) on Feb 16, 2001 at 10:06 UTC
    I don't have to trick my ego because I expect to find problems, but I also -usually- don't have someone to talk the code over with like others have suggested. So I will print out a copy and go somewhere else with a pen. I'm not sure if it's the change of environment or the hard copy that helps more, but it works pretty well.

    Update: No wonder I am not very good yet...I've only got 2 out of 3.

    • laziness
    • impatience
    • hubris
      Exactly, the librarian here at school often wonders why I'm printing at least 20 pages of cryptic words. It's during boring classes when I pull out the stack and begin to either decypher it (to learn from, begin to hack, etc) or to pen-code my own. Who ever said Art History is boring?
Re: Tricking Our Egos
by wufnik (Friar) on Sep 03, 2003 at 21:49 UTC
    that may work for you, but with the amount of mistakes i introduce it is a sure fire recipe for acute hypochondria. fever? possibly a particularly delirious one...

    on a more serious note, my own personal way is to concentrate very hard on the image of a load of monkeys hacking via their proverbial typewriters into the wireless lan and taking over my emacs session. i have been tasked with recovering the code-temples they wrote over, and sadly time never permits me to see them again in all their splendour. hey, works for me,TIMTOWTDI, etc, etc...

    cheerio,

    ...wufnik

    ...in the world of the mules there are no rules

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (13)
As of 2014-07-31 15:45 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (249 votes), past polls