I read Pragmatic Programmer whenever I get a chance. It’s such a great book. I was skipping through the pages today and landed on the first chapter. After (re)reading it, I can say that it is arguably the best chapter in the book. All software developers must read it once and live by its philosophy:
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 happen—even on the best of projects. Despite thorough testing, good documentation, and solid automation, things go wrong. Deliveries are late. Unforeseen technical problems come up.
In your career, you will make mistakes. They are inevitable. I can’t count the number of times I have made mistakes. So when you do make a mistake for something you accepted responsibility for:
- Don’t deflect responsibility.
- Don’t blame another team member.
- Don’t blame a vendor.
- Don’t blame a library or a tool that you use.
- Don’t blame management.
- Don’t become defensive.
Sure any of the above factors could have played a role in the failure. But deflecting responsibility by making excuses or blaming someone or something is the worst possible way to handle such situations. What you should do instead is own up and offer solutions. That’s what your coworkers and management are interested in.
I’m reminded of this email from Linus in which he gets furious at a kernel programmer for making up “lame excuses”. (For the record, I strongly disagree with the language in the email.)
Responsibility is a two-way street. It has to be both given and accepted. I have seen managers foolishly thinking that they can walk up to an employee say out loud “You are responsible for this” or “You own this” and walk away. If the employee doesn’t accept or accepts half-heartedly, the responsibility gets diluted. The employee must be willing to accept the responsibility. Quoting from Pragmatic Programmer:
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.
This doesn’t mean that you should never accept responsibility for anything. That’s not how you grow in an organization and it will not help your career. Be fair, professional and ethical - analyze the risks, determine additional needs such as staff, time or budget and negotiate with your boss or manager. You have every right to think about the situation, but be fair in your assessment.