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.

• 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!

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.

/J

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)))'

J.

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

*Sigh*

Cheers,
MichaelD

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...

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 strict.pm, 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.

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

Wonko

Bravo!

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 :)

--Stevie-O

$"=$,,$_=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
[download]

• 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.

• 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.

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 learned not to trust my little brother when he's angry; and to hide my backups where he couldn't find them. :-) --
AC

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!

ggg

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.

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" :-)

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.

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 :-)

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?"

"...no"

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

"...no"

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).

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.

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.