Continuing lessons from my mistakes

“Hey Marcus, remember that time you deleted 42,000 lines of code before checking in? Oh, and it happened to be on the first real project your boss had assigned you after hiring you? Oh, oh! And, you hadn’t backed up!”

“Yup.”

“Yeah, that sucked. Ha ha.”


True story, but I won’t bore you with the details about how I came to type that fateful command, rm -rf * .bak

Those details aren’t important for this story. What I want to share with you is how and what I keep learning from this situation.

The past is never dead. It’s not even past. — Faulkner

First, realize that every experience you can remember still provides opportunities for learning and growth. Your brain is full of untapped learnings. This isn’t wishy-washy, release-your-full-potential humanism. It’s a real, practical perspective on what learning is.

Often times may ask someone, What did you learn from that situation/mistake? as though the learning was a single occurrence. While it’s good to learn from a mistake, it seems limiting to imagine that the pattern is Mistake -> Learn -> Improve

Instead, I’m suggesting that the pattern is a cycle of:

Mistake -> Reflection -> Learn -> Remember -> Reflection -> Learn -> etc

(Mistakes aren’t the only thing that teach us, but they have played a big part in my own learnings.) I think the idea that an mistake has a single thing to teach us may be our pride at work, wanting to protect our fragile ego by allowing us to exclaim, “I have learned from my mistake, and moved on. Done and done.”

Maybe instead of “What did you learn?” a better question is “What are you learning?”

Two items of note:

  1. This is a simplified version of Piaget's Learning Cycle
  2. This applies to any experience, not just mistakes

As an example I’ll list some of my learnings through the years about a mistake I made twenty-one years ago. Notice how the learnings change as time passes.

Learning through the years

Background: I had just spent four months on my first project at my first real programming job. I had told my boss and the team I was done and ready for QA. I was preparing to package it and check it in.

I didn’t want to include the .bak files in the package or check-in, so I was trying to delete them all. I issued the command rm -rf * .bak to remove the bak files. (See the problem? It’s the space between the “*” and the “.bak”? Small difference, big effect.)

Lessons learned through time

One second later

  1. When rm takes longer than expected, it’s cause for concern

One minute later

  1. rm assumes you know what you are doing
  2. I just lost four months of work
  3. Unix doesn’t have a Recycle Bin
  4. rm does have a flag you can pass to be prompted with “Are you sure?”, but it’s off by default
  5. I’m afraid of telling my boss
  6. I don’t have the SysAdmin’s phone number

One hour later

  1. SysAdmin’s don’t backup everything on the system
  2. The fact that RCS (Revision Control System) takes minutes for a single check-in, and is a huge pain in the butt, is no excuse for not checking-in code.
  3. My boss is a very kind person.
  4. Deleting four months of work doesn’t automatically get you fired
  5. My boss has a sense of humor, responding to the news with “Did you enjoy writing it the first time? Good, now get to work! <grin>”
  6. It may be ironic to have deleted everything you wrote the day you declared to everyone you were “Done”, but it’s not funny. At least, not to me. Not yet.
  7. Desperation and fear make my stomach hurt
  8. I hope I don’t have to tell my wife I got fired

One day later

  1. It’s amazing how much you remember about a design after it’s gone
  2. The database schema alone reveals a great deal about the code
  3. My boss has my back with our VP and customer
  4. My team is awesome and supportive
  5. Reconstruction can move quickly
  6. RCS is not that slow
  7. My boss likes sports metaphors, telling me “It’s not the number of home runs, it’s the number of times at bat.”

One week later

  1. Old backups of a partial project are very helpful. Something is better than nothing
  2. I may have lost files, but I didn’t lose ideas or designs
  3. Re-writing involves re-thinking, which involves improving
  4. Improving the code feels natural, and doesn’t take much more time (if any)
  5. My boss is really, really great
  6. Deleting an entire project is not a CLM (career limiting move)
  7. Being teased by people who care about you isn’t hurtful, but can bring people closer together
  8. There are other version control systems, like CVS
  9. I make mistakes, and want a safety net.

One Month later

  1. My boss appreciates resilience
  2. I waffle between feeling stupid about what I did, and feeling good about what I’m doing
  3. I am not as careful a developer as I thought
  4. Even users understand that mistakes happen
  5. People tell stories about their own mistakes when they learn about yours. Everyone appears to have a story, many worse than mine.
  6. The world didn’t end

One year

  1. It only takes ~20% of the time to rebuild a codebase
  2. It will be better the second time
  3. Users forget late projects, but remember good people
  4. Stories about mistakes live a long time
  5. I can learn to be more careful with my files
  6. I can make my own backups
  7. I can still get a raise after making a big mistake

Five years

  1. This is a good story to tell people who just made a mistake
  2. Telling people there is a problem ASAP builds trust
  3. It’s hard to be an awesome boss when someone makes a big mistake, and having a role model really helps
  4. Being an awesome boss is a worthy goal
  5. A mistake may seem HUGE to me, but not to others.
  6. Git is worth investigating
  7. Dictating check-in frequency to developers is irritating, no matter how important it seems

One decade

  1. Losing code teaches programmers the importance of checking-in
  2. I am not perfect, have never been, and will never be
  3. My programmers are not perfect, either
  4. Creating a safe environment is vital to productivity, innovation and happiness
  5. Sometimes losing all the code is the best thing that can happen to a project.

Two decades

  1. Be gentle with people, as others beat themselves over for their mistakes more than you ever will
  2. Humor is important, especially in difficult situations
  3. Being a great boss is rewarding
  4. Check-in often

Looking back for more lessons

As I look back at this situation, more than twenty-years later, recalling it is a visceral experience. What I draw from it may have changed over time, but this one experience holds a wealth of lessons for me.

Imagine if I spent time reflecting, examining and learning from the big experiences in my life? Imagine how much more I have to learn from what I have already experienced?

I don’t know what future experiences I will have, but I know that my past is a gold-mine of lessons waiting to be learned.

How about you? Do you have a past experience that continues to provide lessons?