Acknowledge (and Learn from) Failures - Revision history

Sberczuk at 12:50, 13 July 2009

2009-07-13T12:50:50Z

←Older revision		Revision as of 12:50, 13 July 2009
Line 1:		Line 1:
-	As a programmer you won't get everything right all of the 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.	+	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.		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.

Kevlin at 09:08, 11 July 2009

2009-07-11T09:08:48Z

←Older revision		Revision as of 09:08, 11 July 2009
Line 1:		Line 1:
-	As a programmer you won't get everything right all of the 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.	+	As a programmer you won't get everything right all of the 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 at the heart of agile methods ~~and it~~'s useful to apply in your own professional practice regardless of your team's development approach.	+	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~~, and it~~ also takes from them the opportunity to react to the information.	+	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.		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.
Line 11:		Line 11:
	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.		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 ~~standup~~ 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.	+	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.		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.

Kevlin at 10:11, 4 February 2009

2009-02-04T10:11:27Z

←Older revision		Revision as of 10:11, 4 February 2009
Line 1:		Line 1:
-	As a programmer you ~~will do things wrong~~. 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.	+	As a programmer you won't get everything right all of the 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 be help the customers get the software that they really wanted. This idea of frequent feedback and adjustment at the heart of agile methods and it's useful to apply in your own professional ~~life~~ regardless of your team's development approach.	+	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 at the heart of agile methods and it's useful to apply in your own professional practice regardless of your team's development approach.

-	Acknowledging that something isn't working takes courage. Many ~~organization~~ encourage people to spin things in the most positive light rather than being honest. This is ~~counter-productive; telling~~ people what they want to hear just defers the inevitable realization that they won't get what they expected, and it also takes from them the opportunity to react to the information. Maybe a feature was only worth implementing if it cost what the original estimate said, and changing the scope is to the customers benefit, for example, so acknowledging that something won't be done on time gives the stakeholder to power to make the decision. Not acknowledging a failure puts this power in the development team, which is the wrong place.	+	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, and it also takes from them the opportunity to react to the information.

-	Most people would rather have something meet their expectations rather than get everything they asked for. Given bad news stakeholders may feel a sense of betrayal. You can temper this by providing alternatives, ~~but~~ only if ~~you believe~~ that ~~they are realistic~~.	+	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.

-	~~Not being honest about your failures denies you~~ a ~~chance to learn and reflect on how~~ you ~~could have done better, and improve your estimation, or technical skills~~.	+	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.

-	You can apply this idea not just to major things like daily standup 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.	+	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 standup 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.		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 ~~you~~ time.	+	Failures are inevitable. Acknowledging and learning from them provides value. Denying failure means that you wasted your time.

	By [[Steve Berczuk]]		By [[Steve Berczuk]]

Sberczuk at 19:36, 3 January 2009

2009-01-03T19:36:33Z

←Older revision		Revision as of 19:36, 3 January 2009
Line 1:		Line 1:
-	As a programmer you will do things wrong. 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.	+	As a programmer you will do things wrong. 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 be help the customers get the software that they really wanted.	+	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 be help the customers get the software that they really wanted. This idea of frequent feedback and adjustment at the heart of agile methods and it's useful to apply in your own professional life regardless of your team's development approach.

-	Acknowledging that something isn't working takes courage. Many organization encourage people to spin things in the most positive light rather than being honest. ~~Telling~~ people what they want to hear just defers the inevitable realization that they won't get what they expected, and it also takes from them the opportunity to react to the information. Maybe a feature was only worth implementing if it cost what the original estimate said, and changing the scope is to the customers benefit, for example, so acknowledging that something won't be done on time gives the stakeholder to power to make the decision. Not acknowledging a failure puts ~~the~~ power in the development team, which is the wrong place.	+	Acknowledging that something isn't working takes courage. Many organization encourage people to spin things in the most positive light rather than being honest. This is counter-productive; telling people what they want to hear just defers the inevitable realization that they won't get what they expected, and it also takes from them the opportunity to react to the information. Maybe a feature was only worth implementing if it cost what the original estimate said, and changing the scope is to the customers benefit, for example, so acknowledging that something won't be done on time gives the stakeholder to power to make the decision. Not acknowledging a failure puts this power in the development team, which is the wrong place.

	Most people would rather have something meet their expectations rather than get everything they asked for. Given bad news stakeholders may feel a sense of betrayal. You can temper this by providing alternatives, but only if you believe that they are realistic.		Most people would rather have something meet their expectations rather than get everything they asked for. Given bad news stakeholders may feel a sense of betrayal. You can temper this by providing alternatives, but only if you believe that they are realistic.

-	Not being honest about your failures ~~also~~ denies you a chance to learn and reflect on how you could have done better, and improve your estimation, or technical skills.	+	Not being honest about your failures denies you a chance to learn and reflect on how you could have done better, and improve your estimation, or technical skills.

-	~~Agile methods are based on~~ this ~~sort of frequent, honest, feedback, but you need~~ not just ~~apply this idea~~ to daily standup meetings and iteration reviews~~. It~~ also ~~applies~~ 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 yo a question.	+	You can apply this idea not just to major things like daily standup 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.	+	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 you time.

	By [[Steve Berczuk]]		By [[Steve Berczuk]]

Sberczuk at 23:09, 28 December 2008

2008-12-28T23:09:30Z

←Older revision		Revision as of 23:09, 28 December 2008
Line 1:		Line 1:
-	As a programmer you will do things wrong. Maybe you underestimated. Maybe you misunderstood requirements. 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 can ~~correct~~ and be ~~sure that~~ the customers get the software that they really wanted.	+	As a programmer you will do things wrong. 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.
		+
		+	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 be help the customers get the software that they really wanted.

	Acknowledging that something isn't working takes courage. Many organization encourage people to spin things in the most positive light rather than being honest. Telling people what they want to hear just defers the inevitable realization that they won't get what they expected, and it also takes from them the opportunity to react to the information. Maybe a feature was only worth implementing if it cost what the original estimate said, and changing the scope is to the customers benefit, for example, so acknowledging that something won't be done on time gives the stakeholder to power to make the decision. Not acknowledging a failure puts the power in the development team, which is the wrong place.		Acknowledging that something isn't working takes courage. Many organization encourage people to spin things in the most positive light rather than being honest. Telling people what they want to hear just defers the inevitable realization that they won't get what they expected, and it also takes from them the opportunity to react to the information. Maybe a feature was only worth implementing if it cost what the original estimate said, and changing the scope is to the customers benefit, for example, so acknowledging that something won't be done on time gives the stakeholder to power to make the decision. Not acknowledging a failure puts the power in the development team, which is the wrong place.

Sberczuk at 22:37, 27 December 2008

2008-12-27T22:37:59Z

←Older revision		Revision as of 22:37, 27 December 2008
Line 1:		Line 1:
	As a programmer you will do things wrong. Maybe you underestimated. Maybe you misunderstood requirements. 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 can correct and be sure that the customers get the software that they really wanted.		As a programmer you will do things wrong. Maybe you underestimated. Maybe you misunderstood requirements. 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 can correct and be sure that the customers get the software that they really wanted.

-	Acknowledging that something isn't working takes courage. Many organization encourage people to spin things in the most positive light rather than being honest.	+	Acknowledging that something isn't working takes courage. Many organization encourage people to spin things in the most positive light rather than being honest. Telling people what they want to hear just defers the inevitable realization that they won't get what they expected, and it also takes from them the opportunity to react to the information. Maybe a feature was only worth implementing if it cost what the original estimate said, and changing the scope is to the customers benefit, for example, so acknowledging that something won't be done on time gives the stakeholder to power to make the decision. Not acknowledging a failure puts the power in the development team, which is the wrong place.
-		+
-	Telling people what they want to hear just defers the inevitable realization that they won't get what they expected, and it also takes from them the opportunity to react to the information. Maybe a feature was only worth implementing if it cost what the original estimate said, and changing the scope is to the customers benefit, for example.	+

	Most people would rather have something meet their expectations rather than get everything they asked for. Given bad news stakeholders may feel a sense of betrayal. You can temper this by providing alternatives, but only if you believe that they are realistic.		Most people would rather have something meet their expectations rather than get everything they asked for. Given bad news stakeholders may feel a sense of betrayal. You can temper this by providing alternatives, but only if you believe that they are realistic.
Line 9:		Line 7:
	Not being honest about your failures also denies you a chance to learn and reflect on how you could have done better, and improve your estimation, or technical skills.		Not being honest about your failures also denies you a chance to learn and reflect on how you could have done better, and improve your estimation, or technical skills.

-	Agile methods are based on this sort of frequent, honest, feedback, but you need not just apply this idea to daily standup meetings and iteration reviews. It also applies 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 yo a question.	+	Agile methods are based on this sort of frequent, honest, feedback, but you need not just apply this idea to daily standup meetings and iteration reviews. It also applies 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 yo 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.

	By [[Steve Berczuk]]		By [[Steve Berczuk]]

Sberczuk at 22:21, 28 November 2008

2008-11-28T22:21:01Z

←Older revision		Revision as of 22:21, 28 November 2008
Line 12:		Line 12:

	By [[Steve Berczuk]]		By [[Steve Berczuk]]
		+
		+
		+	This work is licensed under a
		+	[http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]
		+
		+
		+
		+	Back to [[97 Things Every Programmer Should Know]] home page

Sberczuk at 22:19, 28 November 2008

2008-11-28T22:19:25Z

←Older revision		Revision as of 22:19, 28 November 2008
Line 1:		Line 1:
-	As a programmer you will do things wrong. Maybe you underestimated. Maybe you misunderstood requirements. It's important to be honest with yourself and stakeholders, and take failure as an opportunity to improve.	+	As a programmer you will do things wrong. Maybe you underestimated. Maybe you misunderstood requirements. 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 can correct and be sure that the customers get the software that they really wanted.

-	~~Telling~~ people ~~what they expect~~ to ~~hear just defers~~ the ~~inevitable~~.	+	Acknowledging that something isn't working takes courage. Many organization encourage people to spin things in the most positive light rather than being honest.

-	~~This applies~~ to ~~large things like~~ iteration reviews ~~as well as~~ small things like looking over some code you wrote yesterday and realizing that it was not as good as you thought.	+	Telling people what they want to hear just defers the inevitable realization that they won't get what they expected, and it also takes from them the opportunity to react to the information. Maybe a feature was only worth implementing if it cost what the original estimate said, and changing the scope is to the customers benefit, for example.
		+
		+	Most people would rather have something meet their expectations rather than get everything they asked for. Given bad news stakeholders may feel a sense of betrayal. You can temper this by providing alternatives, but only if you believe that they are realistic.
		+
		+	Not being honest about your failures also denies you a chance to learn and reflect on how you could have done better, and improve your estimation, or technical skills.
		+
		+	Agile methods are based on this sort of frequent, honest, feedback, but you need not just apply this idea to daily standup meetings and iteration reviews. It also applies 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 yo a question.
		+
		+	By [[Steve Berczuk]]

Sberczuk: Admit Failure moved to Acknowledge (and Learn from) Failures

2008-11-28T22:04:28Z

Admit Failure moved to Acknowledge (and Learn from) Failures

←Older revision

Revision as of 22:04, 28 November 2008

Sberczuk: New page: As a programmer you will do things wrong. Maybe you underestimated. Maybe you misunderstood requirements. It's important to be honest with yourself and stakeholders, and take failure as an...

2008-10-11T14:24:25Z

New page: As a programmer you will do things wrong. Maybe you underestimated. Maybe you misunderstood requirements. It's important to be honest with yourself and stakeholders, and take failure as an...

New page

As a programmer you will do things wrong. Maybe you underestimated. Maybe you misunderstood requirements. It's important to be honest with yourself and stakeholders, and take failure as an opportunity to improve.

Telling people what they expect to hear just defers the inevitable.

This applies to large things like iteration reviews as well as small things like looking over some code you wrote yesterday and realizing that it was not as good as you thought.