Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery

Programming Mantras

by dws (Chancellor)
on Jan 21, 2002 at 05:54 UTC ( #140282=perlmeditation: print w/replies, xml ) Need Help??

Do you have a coding mantra? Some phrase or saying (or question) that you repeat to yourself while coding?

In a recent rare moment of self-awareness while coding, I noticed a little voice repeating "How am I going to debug this? How am I going to debug this?" while my fingers were typing

... my $html = $template->expand(\%bindings); return $html; }
I stopped and looked at what I'd typed, and considered for a moment why I hadn't typed
return $template->expand(\%bindings); }
or just
$template->expand(\%bindings); }
The reason goes way, way back to having looked over the shoulder of a really good programmer early in my career. I asked him why he was seemingly wasting a short-lived variable, and he answered that he was always on the lookout for places where he would later need to place breakpoints to examine intermediate results while debugging, and that sometimes he had to make opportunities. He went on to explain that debugging time was part of overall productivity (duh, once you've gotten that point), and that planning for debugging kept debugging time down. It seemed like a really good explanation, and from then on I would mutter "How am I going to debug this?" to myself. Over time, that voice faded into the background, but it's still there, chanting away. The funny thing is that I rarely have to use breakpoints when debugging, even though I automatically make opportunities for them.

What is your programming mantra?

Replies are listed 'Best First'.
Re: Programming Mantras
by japhy (Canon) on Jan 21, 2002 at 06:53 UTC
    I often think "I've come a long way."

    I've come a long way from emailing Larry Wall that his language is cool and that I've written a gcd() and lcm() function that I think he should add.

    I've come a long way from writing &foo(...) everywhere, and using @array[$x], and calling external programs where Perl was obviously the better choice.

    I've come a long way from writing 20 lines of code where 10 would do, and writing 10 lines of code when 5 would do.

    I've come a long way from hand-rolling half-assed overly-specific solutions to problems, instead of using well-written, well-documented modules.

    I've come a long way from pissing off Tom Christiansen on EFnet #perl. I've come a long way from sitting at my computer in awe of the fact that I was just talking to the author of the Perl book on my desk.

    I've come a long way fro-- wow, what a silly way to code that. I can do that much better... (and off he goes to code some more)

    Jeff[japhy]Pinyan: Perl, regex, and perl hacker.
    s++=END;++y(;-P)}y js++=;shajsj<++y(p-q)}?print:??;

      Very recognisable at almost every point (hoewever, I never emailed Larry and I really wonder what gcd and lcm did :).

      My code used to be like the example code in Acme::Inline::PERL :)

      2;0 juerd@ouranos:~$ perl -e'undef christmas' Segmentation fault 2;139 juerd@ouranos:~$

Re: Programming Mantras
by Albannach (Monsignor) on Jan 21, 2002 at 06:19 UTC
    I don't know if it's really a mantra but the voice in my head when I'm debugging often says "don't stop at one". This comes from my boss/mentor during a work term at a really cool shop in 1984. I was coding on a Cray 1S at the time, and as compiling was a long term process, he explained that just fixing the one error that the compiler spat out was often shortsighted, as there could easily be more examples of the same error in other locations, or that error could have been caused by an earlier error, or perhaps a more fundamental logic problem.

    These days I usually don't have too long to wait for my Perl projects to run (either they are pretty short, or I construct tiny sample datasets for testing), so I take this advice to mean "don't stop at the easy or 'obvious' answer, as it is often neither".

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

      (not really a perl thing, but...)

      just fixing the one error that the compiler spat out was often shortsighted, as there could easily be more examples of the same error in other locations, or that error could have been caused by an earlier error, or perhaps a more fundamental logic problem.

      I have to disagree on that one, the first lesson I learned the hard way in my first CS class was not to get bogged down by compiler errors. The prof had given us some C code, and our assignment consisted of two parts:

      1. fix the code so it compiled and ran
      2. modifiy it so it did something slightly different.

      As provided, the code generated about 42 compiler errors/warnings ... people (like me) who tried to fix more then one error at a time, or fix the later errors first, spent forever on the assignment. Had we started at the first error, and then recompiled, about 3/4s of the errors went away. Fixing the next (now first) errors made the rest go away.

      Moral: start at the begining, and proceed in sequence. At each step make sure that what you've done has fixed the first bug, and reduced the total number of bugs.

        Superficially it seems that you advocate the whirlpool model instead of the waterfall one. But really you advocate tripping blindly in the dark. As I will show, there is nothing wrong with the method of your teacher but you are getting the wrong lessons out ouf it!

        1. fix the code so it compiled and ran

        Most compilers run completely out of sync at the first syntactical error and produce a cascad of errors. So incremental fixing is a way to get a program to compile. That was probably the lesson the teacher wanted you to learn. I don't see any other interesting lessons to get from that. Getting a program to compile is no big deal!

        2. modify it so it did something slightly different.

        That's the way we do everything. Proceed from the known to the new. We never start anything from scratch but learn from previous experience. The good teacher is the one that impose in an new exercice a "slightly difference" so that the pupil can both build his confidence and exercice his own initiative.

        But deducing from these exercices that programming is incremental fixing of bugs is dead wrong. Incremental improvment of programs, or Larry's whirlpool (as opposed to the waterfall model) is way more than that. Testing and fixing is just the inner loop or the whirlpoool. But what you propose is not even that, it is the blind fixing of visible bugs probably creating countless of bugs elsewhere. In the linux kernel mailing list,there are recurring threads about self-proclaimed the bastard Linus against getting a debugger in the kernel to fight this natural but wrong tendency: "just fix the next bug" and to encourage programmers to always get the larger view

        I guess I could derive my mantra from Arthur Koestler notion of holon.

        Every complex system is an holarchy where higher holons depends on lower ones. A program is such an holarchy and the first thing to know is at which stage of the holarchy you need to work. Fixing blindly bugs after bugs is working on lower holons and at best building scar tissues. In more pragmatic term, getting local optima (here fixing given bugs) are no guaranty of a global optimum. And we live in a society where every one is a specialist of some holon and is able and prone to get a local optimal there but is likely create a disaster at higher level. Example: "an optimal so-called liberalist american economy is likely to wreck the global ecosystem because it does not care about global warming". Pick up your favorite example.

        So the mantra is Which holon needs working? or in term of Larry's whirlpool Which loop of the whirlpool needs work?

        Certainly, these mantra, as any mantra, set the mind but, by themselves, do not define any course of action. The devil is in the details and we must go define in a given fields what an holarchy is and from which holon it is made. Different schools of programming have various ideas about that.

        I like the concept of holon and holarchy but beware not to get in new-age drug induced illiterrate holistic dreams!!

        -- stefp -- check out TeXmacs wiki

        The point I was trying to make is that the compiler error usually tells you one vague thing: you did something wrong. Unfortunately it does not tell you to any useful extent what you did wrong. It could be anything from a simple typo in one line that lead to 42 messages, or you could have a whole host of fundamental flaws, and there are many options in between.

        In fact, I think I'm safe in asserting tha the most serious flaws in programming are too subtle to be reported by any automated means, so when you do get a warning or an error, the wisdom my boss meant me to take was this: view this warning as a moment of reflection to consider all that leads to this point and all that follows, and take a moment before you simply change one character in a knee-jerk reflex and re-compile.

        For another example, I am reminded of a silly little activity my geek friends and I enjoyed in high-school, when we had gained access to the the first BASIC interpreter we'd seen. The speed of response was positively intoxicating! When we got some code from elsewhere, and received the "syntax error on line nnnn" message, we'd just delete that line and re-run, repeating this process over and over. We were at least sure to never get that particular error again (now that's "de-bugging" ;-), and while the result was often a program reduced to just a handful of lines that did little or nothing, sometimes we'd get some really interesting behaviour which would amuse our adolescent minds for minutes at a time. I don't believe we ever got a correct program out of this process however ;-)

        While I was writing this, I noticed a great line from virtualsue in the CB:

        Programming is a craft not a religion. It's not all that different from construction work ;-)
        I think this is absolutely true, and following that metaphor, consider whether a contractor should simply patch cracks in a wall, or have a look to see if there is a larger problem elsewhere in the building.

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

Re: Programming Mantras
by djantzen (Priest) on Jan 21, 2002 at 06:45 UTC

    "Hmmmm, Mountain Dew.... Hmmmmm,..."

    Actually, I find myself reflecting a lot on what future maintainers of my code will think of what I'm writing. Every programmer has inherited code that's a nightmare to look at, and sometimes we get lucky and find an example of forward thinking design, where the author obviously thought hard about making the software flexible and clean in the knowledge that somebody else down the line would most likely have to augment or modify it.

    I want to be the guy that future developers see as having made their jobs easier by coding thoughtfully. Conversely I don't want to be the guy that they think about and shake their heads, like the original (and long gone) programmer at my last job whom we roundly mocked for doing things like declaring every single damn member function virtual in some deeply misguided attempt to write flexible code.

    I don't know that this translates into mantra per se, but it is a recurring thought that guides much of my work.

      I relate a lot to fever's recurring thought. I have inherited tons of hacked-up, dangerously insecure, bloated Perl scripts, and I do not ever want to do that to anyone else.

      Like fever, I want to make future developers' jobs easier. But I want to make their jobs so much easier, they won't even realize it was easy. By designing systems, programs and scripts that anticipate future changes, future coders will be able to extend and modify without putting too much thought into the existing code and focus solely on what they're trying to do.

      Current mantra: What would I think of this code if I needed to make a change and I wasn't a Perl expert?

      Once my current mantra is absorbed into my subconscious sufficiently, I'd like my next mantra to be: Can I think abstractly enough about this task that I could write a CPAN-worthy module for it?


      I find myself thinking in similar patterns. I try to always be aware of the bigger picture the code is fitting into. I can not count the umber of times in twenty years I ran across code that prevented some function from happening in its current incarnation, or how often I found the same logic in multiple places using different code.

      I also try to remember who my future audience is by what platform they develop on (primarily). I tend to see things written differently by big iron, *nix developers and M$ developers.</p?

      I liken my thinking to: Is this all I am? Is there nothing more?

      Of course, this mantra does have a limit before it becomes a project killer. ;-)

(shockme) Re: Programming Mantras
by shockme (Chaplain) on Jan 21, 2002 at 08:16 UTC
    "Am I going to remember why I did this?"

    Moreoften than not, it's several weeks - if not months - before I revisit my code. A little one line comment goes a long way toward reducing my debug time... Self-documenting code is great, but it doesn't always explain why I used ++$counter rather than $counter++.

    If things get any worse, I'll have to ask you to stop helping me.

      "Am I going to remember why I did this?"

      Wow! That hit's the nail right on the head for me! Or a related corollary:

      "Will anyone be able to figure out why I did this?"


Re: Programming Mantras
by FoxtrotUniform (Prior) on Jan 21, 2002 at 07:46 UTC

    "How can I re-use this?" is something that I'm trying to make a mantra, especially after reading through The Pragmatic Programmer a couple of times. Modular, orthogonal code is a Good Thing.

    Not really a mantra, but one concept that's stuck with me pretty much forever is the idea of conservation of difficulty, which was introduced to me by one of my profs in an intro programming course. The idea is that every problem has a set difficulty, and making some part of the solution easy (writing hacked-up, off-the-cuff code, for instance) will make another part difficult (debugging). Sometimes, the tradeoffs between easy and difficult are political at best (doing the hard bit when nobody's looking, and saving the easy finishing touches for when your boss shows up), but (here's the tie-in with reusable, orthogonal code) often you can do the difficult bits of many problems once -- by writing a module to do something clever that relates to a bunch of your problems, or spending an hour or two putting together a really elegant interface to a function you'll call a lot, for instance.

    "How am I going to debug this?", and it's friend "How am I going to test this?", are ones that I should keep in mind, though.

Re: Programming Mantras
by Aristotle (Chancellor) on Jan 21, 2002 at 08:33 UTC
    If I have a mantra, it would have to be "Is there anything redundant here?". Along the same lines, it is "How do I split this into reusable parts?" (which avoids redundacy from the get go). And what I'm always concerned about, "How obvious is the intention of this code?" - I try to pick identifiers such that the code almost reads like English, both for my own sake if I return to my code 2 years later, as well as for that of anyone else who might look at it. I try to melt code down as far as keeping it self-documenting will allow. (Statement modifiers help a lot here.) Maybe I should say my mantra is "How do I make this beautiful?" :-)

    Makeshifts last the longest.

Re: Programming Mantras
by Veachian64 (Scribe) on Jan 21, 2002 at 06:32 UTC
    I usually end up telling myself "Nothing unnecessary, nothing extra". Whenever I find I can cut out an unnecessary variable, function, or whatever, I do it. Of course, my definition of unnecessary doesn't necessarily mean extra code that improves clarity (which is always a Good Thing).
Re: Programming Mantras
by jonjacobmoon (Pilgrim) on Jan 21, 2002 at 07:00 UTC
    My response has less to do with mantras and more to do with the idea of wasting space.

    I have a perl pet peeve that I know everyone will jump on me about, but I do it because of the need to save time during debugging.

    I hate the one line conditional. You know the little villian:

    $foo = "bar" if (blah eq "blue");
    Funny how it takes no longer to compile or run in a multi-line statement, yet everyone wants to do it in one line to look cool. Let's say I need to add a second statement to that conditional or need to put a print statement in there to debug it. Cut and paste, cut and paste, and then cut and paste to put it back.

    Okay, so maybe that is my mantra: "avoid cut and paste, avoid cut and paste..." :)

    I admit it, I am Paco.
      $foo = "bar", print "DEBUG: $foo\n" if ($blah eq "blue");

      with tongue, firmly in cheek. ;-P

Re: Programming Mantras
by chromatic (Archbishop) on Jan 21, 2002 at 11:49 UTC


    (My Perl Monks mantra is "pimp articles." :)

Re: Programming Mantras
by Dominus (Parson) on Jan 21, 2002 at 22:24 UTC
    Says dws:
    my $html = $template->expand(\%bindings); return $html;
    ... he was always on the lookout for places where he would later need to place breakpoints to examine intermediate results while debugging...
    It seems to me that if you're writing wasteful code because it affords a better opportunity for debugging, the conclusion shouldn't be that the wasteful code is better, but that you need to get a better debugger.

    One of my hobby-horses is that the state of the art in debugging tools is really crappy. If you look at the debugger programs of the 1960's, you'll see that they are not substantially different from what we have today. Debugging tools have hardly gotten better in thirty-five years. I think that's really shocking.

    I think there's something to be learned from your example, but it isn't that you should write more verbose code to save intermediate results into named variables; it's that the debugger should be improved so that it provides better access to the intermediate results.

    You should be able to write something like this:

    return $template->expand(\%bindings);
    and then tell the debugger that you want to place a breakpoint after the call to expand but before the return, and examine the value that will be returned. It wouldn't even be hard for the debugger to get at that value; it's right there on the top of the stack.

    Why can't you do this now? It's not a technical barrier; it's a social one. We've gotten so comfortable with using crappy debuggers that we don't stop to notice when the debugger is making our lives difficult, or to think about how it might be improved.

    I'd like to see folks do more work on debuggers. Perl makes it especially easy to do that, because the debugger is written in pure Perl; you can just make a copy of and start hacking on it. is very simple; it's just a big loop with a giant if-else tree that looks to see what command you entered. To add a new command, you add a new branch to the tree. The information about breakable lines and breakpoints and soforth is all stored in straightforward Perl arrays and hashes, and it's all documented in perldebguts.

    The change I suggested above might be a little harder, because at present there's no support in the internals for stopping anywhere except at the beginning of a statement. But with a little XS support, you could still extend the debugger to do it; it would only require a little extra expertise.

    I'd really like to see more people experimenting with the debugger and finding ways to make it more effective. The current state of the art in debuggers is an embarrassment to the programming community.

    Mark Dominus
    Perl Paraphernalia

(jptxs)Re: Programming Mantras
by jptxs (Curate) on Jan 21, 2002 at 10:02 UTC
    I'm always saying "write the comments first." For me, I find it easiest to speak things out. So what happens is I speak out the logic, and then try and go stright to code. But since I don't type words much less code as fast I speak things out in my head, I get things messed up. So I always write the comments out first. I get them to make sense, then code to the comments...

    We speak the way we breathe. --Fugazi

(tye)Re: Programming Mantras
by tye (Sage) on Jan 21, 2002 at 10:56 UTC

    The only good answers to "how many X does your software support" are "0", "1", or "as many as resources allow".

            - tye (yep, I'll just leave it at that)
Re: Programming Mantras
by Biker (Priest) on Jan 21, 2002 at 14:24 UTC

    1. "This little application will become huge with time... Make sure it will scale. Error check everything!"
    2. "That small data file will become huge with time... Don't slurp it into an array!"

    "Livet är hårt" sa bonden.
    "Grymt" sa grisen...

Re: Programming Mantras
by simon.proctor (Vicar) on Jan 21, 2002 at 14:08 UTC
    • Am I going to be able to understand this in 6 months
    • Am I going to be able to read this in 6 months
    • Can I reuse anything I have just done

    Short and sweet.
      Surely you are missing the ever important
      • Will the poor sod who takes over when I quit be able to understand it?
      Or am I stepping on the toes of job security here :-)

      --- If it doesn't fit use a bigger hammer
        haha, close but how about:

        Will I be able to turn this into 1,000,000 lines of undocumented spaghetti code in my notice period?

        One for the - you're only a programmer so no pay rise, pay reviews :).
Re: Programming Mantras
by Juerd (Abbot) on Jan 21, 2002 at 13:03 UTC
    No mantra for me, that would ruin my music :)

    I always try to keep these in mind:
    • use strict; (A year ago, I wouldn't have said so, but -w and strict have become very close friends :)
    • Use modules when appropriate (but not always - I still prefer using simple regexes)
    • Think about modularity. Even for very simple tasks, I tend to make an OO module these days, and it really helps to clarify my code and to refactor where possible
    • Order is important. I use guards (return unless ...;) instead of nested ifs (if (...) { ... } else { return }) if possible
    • Indent, Indent, Indent, Indent :)

    2;0 juerd@ouranos:~$ perl -e'undef christmas' Segmentation fault 2;139 juerd@ouranos:~$

Re: Programming Mantras
by George_Sherston (Vicar) on Jan 21, 2002 at 17:00 UTC
    I have a few, on rotation:

    "Does this *really* feel right, or am I shirking?" - you know, the rare occasions I write good code it's because I've made my judgements on aesthetic grounds, rather than by thinking it all through. I mean, the ability to think it through underpins the aesthetic; but in the end it's the unswerving adherence to an aesthetic that forces me to do the thinking through. And so often I think "(it's still a bit ugly but) that's good enough" when it really isn't.

    I might boil this one down to "would I want CrazyTachTillyn to look at this?"

    "What's the data structure?" Maybe it's because of the stuff I'm working on, but I find it cuts my work in half if I work out in advance whether I need to base my set of functions around a hash of arrays or an array of arrays of hashes or whatever.

    "The system works" When something goes wrong it's very tempting to attribute this to some grand abstraction to do with Perl, my ISP or whatever. But that's a mistake. The error is always my fault; and believing this is a good thing because it puts the solution within my power. There IS an explanation: so I can find it out.

    George Sherston
Re: Programming Mantras
by BrentDax (Hermit) on Jan 21, 2002 at 12:08 UTC
    My general one is, "What's the stupidest thing I just did?" It might be iterating over a list the wrong way, or writing some very baroque statement, or even something as small as passing an unnecessary parameter to a function ($string, $index instead of just $char, say), but it doesn't matter--I'll fix it. I also have a specific one for when I'm working on Parrot's regexes: "Will this code make people think that Ilya's code is wonderfully clear?" ;^)

    --Brent Dax
    There is no sig.

Re: Programming Mantras
by Necos (Friar) on Jan 21, 2002 at 14:29 UTC
    The thoughts that seem to plague me even as I sleep are:

    1.) How can I improve my programming skills to make this block/sub/module more flexible?
    2.) How can I write more elegant (yet, still understandable) code?
    3.) How can I write less code without jeapordizing stability (in other words, killing duplications)?
    4.) Am I re-inventing the wheel, or is this code ground breaking?

    Whenever I'm writing code (as I am now), these things race through my head in a (at best) random order. Also, these thoughts have come from my interaction with others here at PM. Since most of the people here are experienced Perl hackers, it would be stupid of me not to take any of their advise.

    In short, "Make Perl yours, but always carry around a Bag-O'-Tricks(tm). Someone else might need the gift of constructive criticism (or at least, a swift kick in the rear)."

    Theodore Charles III
    Network Administrator
    Los Angeles Senior High
    4650 W. Olympic Blvd.
    Los Angeles, CA 90019
    323-937-3210 ext. 224
Re: Programming Mantras
by ajt (Prior) on Jan 21, 2002 at 18:41 UTC
    I often think:
    • Can I make it smaller/simpler?
    • What will the "idiot" user do?
    • What will the cracker do?

    I like to make my code smaller, more elegant and more modular, I shudder when I look at how bloated and spagetti like my early code is, and even today, I'd hardly call my code compact...

    Much of my stuff is small CGI scripts, so I'm very worried about black-hats and people doing stupid things.

    I can see a lot of validity in what other people have said here ++ all around, but I suppse I worry about: Reuse; Misuse; and Abuse.

Re: Programming Mantras
by lachoy (Parson) on Jan 21, 2002 at 18:32 UTC

    I wind up writing a lot of infrastructure stuff, so over time I've internalized these questions:

    • Is this as simple as I can make it?
    • What are error conditions that I need to check?
    • How can I break this? What happens if it breaks?
    • How can I test this? If I can't test it, I need to rewrite it so it can be tested.
    • How would another programmer want to use this? Whare are logical parameters and their order? What are logical return values?
    • Is this coupled to anything else? If it relies on a constant, however assumable, can I put the constant in a configuration somewhere or make it available for modification?
    • If nothign else works: what would clemburg do? (Plug in your own smart peer.)

    M-x auto-bs-mode

Re: Programming Mantras
by Steve_p (Priest) on Jan 21, 2002 at 19:19 UTC
    Being a consultant, I've had one mantra rule my decisions when programming:

    "Will they understand this when I'm gone"

Re (tilly) 1: Programming Mantras
by tilly (Archbishop) on Jan 21, 2002 at 23:42 UTC
    How should this work?

    I ask this on many levels. From how should the API I am calling work, to how should the function I am working on work, to what the API I am working on should work, to how the overall product should work.

    My reasoning is that I view a program as a textual representation of the mental model of a solution. Therefore the most important thing I do as a programmer is build, specify, and refine my own mental model of what should happen, and then make what is in the code match that model.

Re: Programming Mantras
by metadoktor (Hermit) on Jan 21, 2002 at 12:13 UTC
    It's "I Can Do It."


    "The doktor is in."

Re: Programming Mantras
by Steve_p (Priest) on Jan 22, 2002 at 07:43 UTC
    I hate posting twice to the same subject, but I ran across this quote that could easily become my new mantra.

    "Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods

    Found here
Re: Programming Mantras
by dreadpiratepeter (Priest) on Jan 21, 2002 at 21:33 UTC
    Well it used to be, "how can I generalize this?". But now that I generalize everything automatically it's become "what are the exceptions?". When won't this method work? What input can break this? What are the assumptions going in to this? It's a lot cheaper to think of these things when writing than when debugging.

    Entropy is not what is used to be. perl -e "$XxKe=$XxTa=$XxE_=$XxUc=$XxBu=$XxAj=$XxCs=$XxFa=$XxGn=$XxVk=$XxJh=$XxLr=$XxM_=$XxNp=$XxOe=$XxPr=$XxR_=$XxSh=$XxQl=$XxWe=$XxDt=$XxXr=$XxHo=$XxIt=$#=qq-X-;$$=qqXxX;print((map{(m/.{3}(.)/)[0]}map{s,_, ,,$_}sort grep{m`[$#-$#][$$-$$]`}keys%::),qq,\n,)"
Re: Programming Mantras
by clemburg (Curate) on Jan 22, 2002 at 00:07 UTC

    Do I *really* have to solve this problem? Who has already solved it for me? What is the problem that I *need* to solve? What do I *really* want to do *here*?

    Christian Lemburg
    Brainbench MVP for Perl

Re: Programming Mantras
by dthacker (Deacon) on Jan 22, 2002 at 06:43 UTC
    When I used to work for an outbound telemarketer our SysAdmin would end our pre-campaign meetings with "Let's make it a beautiful thing!" I've taken it for my own and added my own meaning. I want the next person to view my code to see it as a thing of beauty. Not always achievable, but always a goal.


Re: Programming Mantras
by perlmoth (Hermit) on Jan 22, 2002 at 02:47 UTC
    When I am coding, I find myself repeating over and over:

    "Aw, What gives!?"

    Although I don't think that strictly counts as a mantra.
Re: Programming Mantras
by Anonymous Monk on Jan 22, 2002 at 04:33 UTC
    Write everything as if the person who will be maintaining it is a short-tempered gun nut who knows where you live.

Log In?

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

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (2)
As of 2023-06-10 18:49 GMT
Find Nodes?
    Voting Booth?
    How often do you go to conferences?

    Results (39 votes). Check out past polls.