Instead of excuses, provide options. Don't say it can't be done; explain what can be done.
Regardless of how well you prepare something, there's always a chance things don't turn out the way you thought. In software development, even the best projects can fail in unexpected ways. Even those with the highest code quality and loads of test coverage.
The ultimate question is: how do you deal with such unforeseen scenarios? You have two options: either you blame everything else, or you take responsibility. It's obvious that the tip in this post's title is in favor of the latter option. Even when something outside of your control fails, you can take responsibility. There are always options you can offer as an alternative. And in the worst case you apologize, bite the dust, and get on with your life.
"Telling your boss 'the cat ate the source code' just won't cut it."
An effective way to think of alternative options is to look at yourself in the mirror. Go to your bathroom, look at yourself, and ask: "What is the other person likely to say?" or "How will the other person react?" Conversations are much easier when you already thought about the answers to trivial questions.
And, when you lack an answer yourself, ask for help. There is no person that knows everything. Not even you, who is reading this (sorry, mate). I like to think about asking for help as something that shows strength. Asking for help requires the courage to admit that there's something you don't know. It can be scary, especially when you think about what other people will think of you. Others may think you're stupid. You will be amazed at how often the opposite is true. Most people like to help you out because most people are social, compassionate, and like to share their knowledge. When you seek discomfort, you will be rewarded. And when you meet someone who doesn't, that's their defect. When you meet such a person, talk with them about it. Tell them why being open to help others is something they should invest in. Something that will also help them and their personality in the long term. And if that has no effect and all is in vain? Well, then screw them. 😉
This post is part of a series about the Pragmatic Programmer.
Top comments (0)