Acknowledge (and Learn from) Failures
|(5 intermediate revisions not shown.)|
|Line 1:||Line 1:|
As a programmer you
As a programmer you . Maybe you underestimated. Maybe you misunderstood requirements. 'to , . , you canbe .
'to thingsthe .
Telling people what they want to hear just defers the inevitable realization that they won't get what they expected
Telling people what they want to hear just defers the inevitable realization that they won't get what they expectedalso takes from them the opportunity to react to the information.
, only if that .
a you .
apply this idea to daily meetings and iteration reviewsalso to small things like looking over some code you wrote yesterday and realizing that it was not as good as you thought, or admitting that you don't know the answer when someone asks a question
By [[Steve Berczuk]]
By [[Steve Berczuk]]
As a programmer you won't get everything right all of the time, and you won't always deliver what you said you would on time. Maybe you underestimated. Maybe you misunderstood requirements. Maybe that framework was not the right choice. Maybe you made a guess when you should have collected data. If you try something new, the odds are you'll fail from time to time. Without trying, you can't learn. And without learning, you can't be effective.
It's important to be honest with yourself and stakeholders, and take failure as an opportunity to improve. The sooner everyone knows the true state of things, the sooner you and your colleagues can take corrective action and help the customers get the software that they really wanted. This idea of frequent feedback and adjustment is at the heart of agile methods. It's also useful to apply in your own professional practice, regardless of your team's development approach.
Acknowledging that something isn't working takes courage. Many organizations encourage people to spin things in the most positive light rather than being honest. This is counterproductive. Telling people what they want to hear just defers the inevitable realization that they won't get what they expected. It also takes from them the opportunity to react to the information.
For example, maybe a feature is only worth implementing if it costs what the original estimate said, therefore changing scope would be to the customer's benefit. Acknowledging that it won't be done on time would give the stakeholder the power to make that decision. Failing to acknowledge the failure is itself a failure, and would put this power with the development team — which is the wrong place.
Most people would rather have something meet their expectations than get everything they asked for. Stakeholders may feel a sense of betrayal when given bad news. You can temper this by providing alternatives, but only if you believe that they are realistic.
Not being honest about your failures denies you a chance to learn and reflect on how you could have done better. There is an opportunity to improve your estimation or technical skills.
You can apply this idea not just to major things like daily stand-up meetings and iteration reviews, but also to small things like looking over some code you wrote yesterday and realizing that it was not as good as you thought, or admitting that you don't know the answer when someone asks you a question.
Allowing people to acknowledge failure takes an organization that doesn't punish failure and individuals who are willing to admit and learn from mistakes. While you can't always control your organization, you can change the way that you think about your work, and how you work with your colleagues.
Failures are inevitable. Acknowledging and learning from them provides value. Denying failure means that you wasted your time.
This work is licensed under a Creative Commons Attribution 3
Back to 97 Things Every Programmer Should Know home page