Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid

Greatest programming mistakes and what to learn from

by Mr. Lee (Scribe)
on Dec 22, 2004 at 18:52 UTC ( #416865=perlmeditation: print w/replies, xml ) Need Help??

Many "monks" seem to be around the programming scene for a very long time, and I want to ask one question: what was the greatest errors that you have made in your programming career, and more important, ask a second question: what did you learn from it? Did you change something fundamental for the rest of the time since then? Or did you not and why not?
  • Comment on Greatest programming mistakes and what to learn from

Replies are listed 'Best First'.
Re: Greatest programming mistakes and what to learn from
by mr_mischief (Monsignor) on Dec 22, 2004 at 22:26 UTC
    First, for anyone in the computer field who hasn't been around very long a quick lesson... If you meet someone in a bar or at a party who asks for your phone number immediately after finding out you're in the computer field, don't give it out or you can look forward to Windows tech support calls at 3 AM from someone you barely know. :-) My roommate at the time gave out our number and told a couple of people what we did for a living, and they told their friends. Pretty soon we had to change our number.

    As for something having to do with the practice of programming, one thing I learned the very hard way is that if your job consists of both programming and other duties, make sure that the time estimates you give people for getting units done or adding new features to a project make clear that they depend on the percentage of time you spend at the task of programming. If you estimate something will take three days, be sure your boss knows that's three days of design, coding, and testing exclusive of maintaining hardware/server configs/client consulting relationships.

    When you get pulled away from programming, make it clear that your target delivery date is slipping because of the shifted task schedule. Be sure to mention that the time needed may be related not just to how long you have been doing other things but also how much of your programming time has been in uninterrupted segments. If you're the type of programmer who works best in a certain mental state and it takes time for you to get into that state, then every switch away from that state causes additional lead-in time for the next session.

    I've seen many projects delivered late or even fall by the wayside not because of bad time estimates, but because there was a lack of communication between the developer giving the estimates and the manager reassigning task priorities with little thought about how the software project is estimated. If you know you'll have four hours a day on a project, and that it'll take six four hour sessions to design, test, code, and deliver properly, then that's six working days. If two of those days you're on a junket, and on the day after the junket you're too tired to code, then that's nine working days or maybe ten because of the break. If you originally told your boss two or three days because it's 24 hours of coding and fail to point out that junket in between, you're substantially late on your project.

    If a software project is a back-burner project, then estimate the number of hours for each function or small group of functions. Make sure deadlines and the time for the functions absolutely needed make some kind of sense together. Make sure you actually get some time to work on it, even though it's a back-burner project.

    Whatever the case, it helps to remind people that estimates for delivery are based on certian assumptions and that when those assumptions change, the delivery estimate should too.

    Update: added a word I omitted originally.

    Christopher E. Stith
Re: Greatest programming mistakes and what to learn from
by dthacker (Deacon) on Dec 22, 2004 at 20:59 UTC
    • Human error creeps into the simplest tasks. Always test everything. Learned when a division sales manager handed my boss a stack of reports with math errors on a business trip. I'd been in a hurry to finish them, it was 3am when I finished them, and I thought they were too simple for me to make a mistake on. I was wrong.
    • Backup before you work. You will eventually trash something important. If it's backed up, you won't feel the pain. Learned one night when I dropped a table before I unloaded it.
    • Never try to outguess the customer. Ask questions. Show them work in progress. Make sure your delivering what they want. Learned when my deliverable did not deliver.
    • Document while you work. I know that people have differing opinions on the value of comments and documentation. I have had to re-visit documented 5 year old code and undocumented 5 year old code. The documented code was easier to work with. Do it now. You probably won't have time to document it later.
    • Keep an open mind. In 2000, I bought a copy of Learning Perl. A colleague of mine saw it on my desk and asked me, "Why do want to learn that? It's a dead language!" I don't think he's in the industry anymore.

    • Dave
      Code On!
Re: Greatest programming mistakes and what to learn from
by jplindstrom (Monsignor) on Dec 22, 2004 at 23:09 UTC
    Not the greatest mistake, but a timeless classic I'm-a-moron moment is when you realize that you're editing one thing, looking at another thing and wonder why nothing happens.

    The only improvement over the years is the frequency with which it happens, and the time it takes to realize that you are, in fact, behaving like a moron again.


      Another, similar classic is accidentally opening the same file twice in different sessions, editing one, saving and closing it, and then habitually saving and closing the other on top of the first.

      What I've learned is to only have one editor open at a time, ever.

      What I should have learned is to use an editor which notices a file that got changed out from under it.

      ...or when you are trying to solve a problem, and you run to Perl Monks for help, and you accidentally post the wrong set of code to your node... Doh!

      Linux, sci-fi, and Nat Torkington, all at Penguicon 3.0
      perl -e 'print(map(chr,(0x4a,0x41,0x50,0x48,0xa)))'


      I can so completely relate to this type of situation...



Re: Greatest programming mistakes and what to learn from
by mirod (Canon) on Dec 22, 2004 at 19:05 UTC

    My biggest mistakes have not been in programing per se: a faulty Apple II floppy disk made me loose about 2 weeks of work at crunch time in a project. The lesson I leraned: backup early, backup often!

    Later on I learned the hard way that features never go away. If a user asks you to remove a feature, don't throw away the code: chances are that some day they will come back to you, asking you to add it (they will have forgotten that you ever wrote it), with a really tight deadline. The lesson I learned: version control tools are good for you.

      little joke to prove your point...
Re: Greatest programming mistakes and what to learn from
by tilly (Archbishop) on Dec 23, 2004 at 03:17 UTC
    My greatest error was having my first programming job be an Access developer on Windows, and what I learned from it was to be a Perl and Linux zealot. :-)

    Seriously, the single worst mistake that I made was to edit a production script so that it passed an accidental undef (rather than an argument) to a program (which I didn't write) that interpreted the lack of an argument as "send everything" rather than "bad data". The result was that I proceeded to attempt to send to Bloomberg's ftp site every file that they had been sent in several years - and I said attempt because the ftp server did not prove to have enough disk space to load all of these files.

    As for what I learned, well, I learned a lot about the value of prompt apologies, having programs validate your assumptions, (later) to appreciate the typo checking from, not to permanently leave stale garbage in a production directory, and several other lessons.

    Unfortunately the developer who wrote the code that I was maintaining learned none of those lessons from the incident since he'd left the company and was not around to benefit from the experience. :-(

      Hey Tilly,

      So what year about did you make this mistake? I ask because I used to work at ol' Bloomberg and wrote some code that supported things like that, as well as much of the code for their first three websites. That was where I learned Perl.

        It would have been somewhere in the winter of 1998-1999. My employer was Trepp.
Re: Greatest programming mistakes and what to learn from
by Wonko the sane (Deacon) on Dec 23, 2004 at 01:36 UTC
    Debugging lesson learned:

    When faced with a logical paradox, check your assumptions,
    You will always find that at least one is in error.



      Whenever I'm debugging a problem, and I have no idea what's going wrong, my first instinct is to say: Print out *all* the variables.
      My coworkers used to give me strange looks, and I'd get conversations that went like this:

      Me: "Hey, print the value of X"

      Them: "I know what it is. It's 3."

      Me: "Print it out anyway."

      Them: "Fine." Output: 3

      Me: "Good. Now print the value of Y..."

      Repeat for many, many variables (incidentally, this often became code that logged gobs of data to a file). Eventually, we'd get to a variable where my coworker thought it was one value, and the variable was another value. "Oh, crap! I see the problem..."

      This is especially necessary for languages like C where a runaway pointer or stack overflow can trash a variable from a completely different context.

      Fortunately, they're starting to understand my debugging methods now :)

      $"=$,,$_=q>|\p4<6 8p<M/_|<('=> .q>.<4-KI<l|2$<6%s!<qn#F<>;$, .=pack'N*',"@{[unpack'C*',$_] }"for split/</;$_=$,,y[A-Z a-z] {}cd;print lc
Re: Greatest programming mistakes and what to learn from
by exussum0 (Vicar) on Dec 22, 2004 at 20:58 UTC
    Mine was, read the god damned error. I banged my head when a long winded error was half heartedly taken. After I read it, read it again, and then made sure I understood it, i fixed it in minutes. *grumblecakes*

    Give me strength for today.. I will not talk it away..
    Just for a moment.. It will burn through the clouds.. and shine down on me.

Re: Greatest programming mistakes and what to learn from
by neniro (Priest) on Dec 23, 2004 at 08:04 UTC
    • Don't work more than 10 hours, cause you'll make too much failures after this time.
    • Ensure you're working with the right terminal window (things tend to get really ugly if you kill processes on the wrong box).
    • Leave job-related trouble at work. Your life starts to get terrible if your mind is always in the office.
Re: Greatest programming mistakes and what to learn from
by fraktalisman (Hermit) on Dec 22, 2004 at 22:48 UTC
    The most annoying error is that I keep forgetting useful information (like using split with -1 when needed).
    What to do?
    • Often when I don't recall the precise solution to a problem, I do recall there was something tricky about it, and where or how I found the appropriate documentation (perldoc can be confusing) / pm article.
    • I keep notes (on paper!) about my projects.
    • I keep code examples that I used successfully, sort of a personal tips and tricks library.
    • I also trained my brain to remember things better, e.g. using keywords or even jokes about problems and their solutions. You might find me filing through backup cd's muttering "I know we solved it in 2002 for customer xyz". It works.
    There must be other serious mistakes I did, but that was the first that came into my mind ...

Re: Greatest programming mistakes and what to learn from
by wolfger (Deacon) on Dec 23, 2004 at 13:57 UTC
    I can't believe nobody mentioned this yet... I guess it sort of goes hand in hand with "back up early and often"... but my biggest mistake (which I have made more than once) is to not do versioning. It's a real pain to have working code, and decide to add some new functionality... maybe rewrite a bit of the original code to streamline things... genercize some old code and turn it into a subroutine that can be utilized by the new code... and in the end you wind up with something that doesn't work! And here I am, with my code rewritten into non-functionality, and I've saved it right over the previous working version.

    Version control. It's not just for a multi-person development environment.

    Linux, sci-fi, and Nat Torkington, all at Penguicon 3.0
    perl -e 'print(map(chr,(0x4a,0x41,0x50,0x48,0xa)))'
Re: Greatest programming mistakes and what to learn from
by Limbic~Region (Chancellor) on Dec 23, 2004 at 15:11 UTC
    Mr. Lee,
    <dislaimer>I am not a programmer by trade</disclaimer>

    The biggest mistake(s) I have made are ones that seem to be made by all new coders.

    • Not caring if it is the right way, only caring if it works
    • Not caring if it is maintainable as I will never need it again
    • Not listening to the advice being given by more experienced coders and getting frustrated that they are not answering my question(s)
    • Getting stuck pursuing a solution that is wrong for the problem because it originally looked right and I had already invested a great deal of time in it
    • Not bothering to RTFM and just changing things randomly hoping they would work
    • Being so stubborn about just solving the problem that I miss all the tangental information I come across researching it that would have helped me 5 minutes down the road with the next problem
    • etc, etc, etc
    I am still learning and I am still making some of these mistakes. It seems that it is only after a new coder is willing to stop making these mistakes that they are no longer considered "new".

    Cheers - L~R

Re: Greatest programming mistakes and what to learn from
by Anonymous Monk on Dec 22, 2004 at 20:28 UTC
    The biggest mistake I made was: "Don't anger your little brother, or he'll run a big magnet over all your disks". ;-)

    I learned not to trust my little brother when he's angry; and to hide my backups where he couldn't find them. :-) --

      This is probably a good lesson to transfer to the workplace: Don't anger your coworkers, you never know how they might sabotage you.

      Taking proper care of your backups is probably a good life lesson also!

Test your code under the same conditions as it will run in production
by hossman (Prior) on Dec 23, 2004 at 07:52 UTC

    My first big project at my first big job was an apache module that took in some search terms and some categories as input, opened some files on disk that cached some meta-data for the category, and then did a search on a search index using the user input and the meta-data.

    The module worked fine, it ran fast, i had no problems in development or in qa, and we ever ran it through PMA to make sure you could respond quickly.

    when we deployed it live, it worked fine for a little while and then the whole machine would seeze up and not do anything. It turns out i wasn't closing the meta-data files, And the apache "threads" (sub-processes) where long lived, and haning on to the open file handles untill they exited.

    The problem didn't show up in QA because they didn't hit it with a lot of concurrent load. It didn't show up in dev (even though i specificly tried hammering it with lots of requests) because the dev server had a much shorter time to live for the thread/process pool. It didn't show up in PMA (even though we were hitting it hard, and it was configured just like production) because the client we were using to trigger load was testing lots of permutations of input was doing a lot of randomness on the search terms, but not the category ... so the processes were usually getting lucky and typically allready had the filehandle that they needed opened.

    it actually turned out that we were occasionally hitting the problem in PMA, it was just blocking untill another process died and released some filehandles ... once i put in the appropriate "close" call, the average response time was cut in half because of the eliminated blocking.

Re: Greatest programming mistakes and what to learn from
by zentara (Archbishop) on Dec 23, 2004 at 12:19 UTC
    I still smile to myself, when I remember this.

    I was working at a Community College, back in the 70's, running programs thru punch cards on a shared mainframe (which serviced all the colleges in the state), and developing some Fortran software for an automatic-random-question-test system for a professor. Anyways, I wasn't sure how a certain loop would output, so I needed to run through about 1000 simulations. Well, being a dummy, I made each loop to be a separate process, instead of all under one process and I overloaded the process_queue on the mainframe, and shut the whole works down. The professor and sys-admin were quite annoyed because they were blamed. :-)

    What did I learn? I learned..."don't do that again" :-)

    I'm not really a human, but I play one on earth. flash japh
Re: Greatest programming mistakes and what to learn from
by petdance (Parson) on Dec 23, 2004 at 22:15 UTC
    This is a question I ask all my programming candidates: "Tell me about the worst bug you ever wrote."

    Then, after he/she tells me the story, I ask "What did you change in how you work as a results?"

    The questions, and their answers, dig at the person's depth of experience, and maturity as a programmer, respectively.


Re: Greatest programming mistakes and what to learn from
by knexus (Hermit) on Dec 25, 2004 at 00:09 UTC
    Rather than reply with a specific example, I think it may be more interesting to get at the root of many of my errors all at once.

    So, my greatest struggle in programming (and things in general) was dealing with the "Master of Oversimplification" which exits in me. No matter the task, difficult of simple, I would always work it out in my mind and somehow grossly underestimate the work at hand. I evetually came to the conclusion that this was due to excess hubris created by quick and early sucesses in the beginning of my software development career. Unfortuntely it took a few tough years (read: nightmare projects from hell) before I was enlightened.

    In short, living through projects with seemingly endless develop/test cycles and playing fireman all day really takes the wind out of your sails. This then leads to either professional death (burnout) or some serious introspection. What was hard to accept was that I often helped create the environment that led to careless mistakes and overlooked erroneous assumptions; largely by unintentionally creating unrealistic expectations in others... and then trying to live up to them.

    Once I learned to not overestimate my own abilities and speed, I became a much better developer. The seeming irony is that as I learned some humility I actually became more competent... which then leads to greater confifence... argg watch out for that vicious cycle.

    I hope this makes sense... I feel like I started rambling :-)

Re: Greatest programming mistakes and what to learn from
by hsmyers (Canon) on Dec 25, 2004 at 17:24 UTC
    Never, I repeat Never test pre-alpha defragmentation software on the development box.


    "Never try to teach a pig to wastes your time and it annoys the pig."
Re: Greatest programming mistakes and what to learn from
by dimar (Curate) on Dec 24, 2004 at 21:21 UTC

    Mistake: equating programming ability and competence with "doing a good job" ...

    Ability does not always equal recognition, and vice versa.

    Never overlook the importance of 'peopleware'.

    Never assume people will be satisfied with an answer even if it happens to be well-reasoned and technically correct.

    A truly great and innovative plan must always overcome the natural resistance to changing the status quo.

Re: Greatest programming mistakes and what to learn from
by EdwardG (Vicar) on Jan 05, 2005 at 16:04 UTC

    In 1987 I accidentally IPL'd the production mainframe, taking down Natwest's entire network of terminals throughout New Zealand.

    After the fuss died down, my manager took me to one side.

    "Not thinking, Mr Guiness?"


    "Won't do it again, will you?"


    Not strictly a programming mistake, but one I remember vividly and with increasing nostalgia as time goes by.


      In the 80's I worked on a VAX with a funds transfer application. I had bad information on which machine was live and I deleted the active database. This was at 4pm and the funds transfer network closed at 4:30...come to find out this bank had VERY low traffic and they had not yet entered the transactions for the day...I reallocated the files and they entered their stuff and no one was the wiser (except me).
Re: Greatest programming mistakes and what to learn from
by martinvi (Monk) on Dec 24, 2004 at 12:35 UTC

    1. To assume. Never ever ass-U-me.
    Make a guess and then go and check. Go back and double-check. Get someone else and let her/him check.

    2. To check without a confirmed, public, well-defined, appropriate metric.

    3. To do something without a confirmed, public, well-defined, appropriate documentation.

Re: Greatest programming mistakes and what to learn from
by Mr. Lee (Scribe) on Jan 04, 2005 at 18:41 UTC
    Thanks all for the replies.
    I will try to consider. But it is too much to consider all for all the time. One thing that seems most important from your answers is: to think and to be careful

Log In?

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

How do I use this? | Other CB clients
Other Users?
Others surveying the Monastery: (2)
As of 2023-06-03 00:47 GMT
Find Nodes?
    Voting Booth?
    How often do you go to conferences?

    Results (6 votes). Check out past polls.