The Cat Ate My Source Code

The greatest of all weaknesses is the fear of appearing weak.

J. B. Bossuet, Politics from Holy Writ, 1709

One of the cornerstones of the pragmatic philosophy is the idea of taking responsibility for yourself and your actions in terms of your career advancement, your project, and your day-to-day work. A Pragmatic Programmer takes charge of his or her own career, and isn't afraid to admit ignorance or error. It's not the most pleasant aspect of programming, to be sure, but it will happeneven on the best of projects. Despite thorough testing, good documentation, and solid automation, things go wrong. Deliveries are late. Unforeseen technical problems come up.

These things happen, and we try to deal with them as professionally as we can. This means being honest and direct. We can be proud of our abilities , but we must be honest about our shortcomingsour ignorance as well as our mistakes.

Take Responsibility

Responsibility is something you actively agree to. You make a commitment to ensure that something is done right, but you don't necessarily have direct control over every aspect of it. In addition to doing your own personal best, you must analyze the situation for risks that are beyond your control. You have the right not to take on a responsibility for an impossible situation, or one in which the risks are too great. You'll have to make the call based on your own ethics and judgment.

When you do accept the responsibility for an outcome, you should expect to be held accountable for it. When you make a mistake (as we all do) or an error in judgment, admit it honestly and try to offer options.

Don't blame someone or something else, or make up an excuse . Don't blame all the problems on a vendor, a programming language, management, or your coworkers. Any and all of these may play a role, but it is up to you to provide solutions, not excuses.

If there was a risk that the vendor wouldn't come through for you, then you should have had a contingency plan. If the disk crashestaking all of your source code with itand you don't have a backup, it's your fault. Telling your boss "the cat ate my source code" just won't cut it.

Tip 3

Provide Options, Don't Make Lame Excuses

Before you approach anyone to tell them why something can't be done, is late, or is broken, stop and listen to yourself. Talk to the rubber duck on your monitor, or the cat. Does your excuse sound reasonable, or stupid? How's it going to sound to your boss?

Run through the conversation in your mind. What is the other person likely to say? Will they ask, "Have you tried this" or "Didn't you consider that?" How will you respond? Before you go and tell them the bad news, is there anything else you can try? Sometimes, you just know what they are going to say, so save them the trouble.

Instead of excuses, provide options. Don't say it can't be done; explain what can be done to salvage the situation. Does code have to be thrown out? Educate them on the value of refactoring (see Refactoring). Do you need to spend time prototyping to determine the best way to proceed (see Prototypes and Post-it Notes)? Do you need to introduce better testing (see Code That's Easy to Test and Ruthless Testing ) or automation (see Ubiquitous Automation) to prevent it from happening again? Perhaps you need additional resources. Don't be afraid to ask, or to admit that you need help.

Try to flush out the lame excuses before voicing them aloud . If you must, tell your cat first. After all, if little Tiddles is going to take the blame.

Related sections include:

Prototypes and Post-it Notes
Refactoring
Code That's Easy to Test
Ubiquitous Automation
Ruthless Testing

Challenges

How do you react when someonesuch as a bank teller, an auto mechanic , or a clerkcomes to you with a lame excuse? What do you think of them and their company as a result?