You Don't Need That - Revision history

Checker at 11:22, 23 April 2007

2007-04-23T11:22:05Z

← Older revision		Revision as of 11:22, 23 April 2007
Line 1:		Line 1:
	There's this phenomenon that sometimes surfaces when you get smart people who are extremely loyal to a particular piece of software or process, and then the software or process is criticized for lacking a feature or failing to address a concern. I call it ''You Don't Need That''.		There's this phenomenon that sometimes surfaces when you get smart people who are extremely loyal to a particular piece of software or process, and then the software or process is criticized for lacking a feature or failing to address a concern. I call it ''You Don't Need That''.

	This mentality is sometimes displayed surrounding feature requests in my favorite editor, [[Emacs\|GNU Emacs]]. I love Emacs, but it's pretty pathetic that it doesn't have soft returns (sometimes called "word wrap") and it's on version 21.x as of this writing<ref>Apparently version 22 will finally be adding them, yay!</ref>. Heck, Windows notepad.exe has word wrap. This lack of functionality, by itself, is bad enough, but worse is when a newbie asks about the the feature, and partisans try to convince the newbie that they don't want the feature in the first place.		This mentality is sometimes displayed surrounding feature requests in my favorite editor, [[Emacs\|GNU Emacs]]. I love Emacs, but it's pretty pathetic that it doesn't have soft returns (sometimes called "word wrap") and it's on version 21.x as of this writing<ref>Apparently version 22 will finally be adding them, yay!</ref>. Heck, Windows' notepad.exe has word wrap. This lack of functionality, by itself, is bad enough, but worse is when a newbie asks about the the feature, and partisans try to convince the newbie that they don't want the feature in the first place.

	I wish I could find an example of this happening to link or reproduce here, either with Emacs, or with any other software. I remember reading threads like this when I last searched for information about word wrap in Emacs about 4 years ago but I can't find a good link now. Let me know if you have a link to a good example and I'll post it here.		I wish I could find an example of this happening to link or reproduce here, either with Emacs, or with any other software. I remember reading threads like this when I last searched for information about word wrap in Emacs about 4 years ago but I can't find a good link now. Let me know if you have a link to a good example and I'll post it here.

Checker at 19:58, 31 March 2007

2007-03-31T19:58:16Z

← Older revision		Revision as of 19:58, 31 March 2007
Line 11:		Line 11:
	There are, of course, legitimate times when somebody asks for something and they really actually do want something else but they don't know it. The difference is, in these cases, the "something else" should provide some advantage over the thing they asked for, either for the provider or receiver. Part of the job of a programmer is to figure out what the right way to expose a feature is via an [[API Design\|API]], and part of this skill is knowing how to get to the heart of the requests coming in and provide the features that satisfy the most requests with the least work while simultaneously not designing yourself into a corner...to hit the knee of the cost/benefit curve.		There are, of course, legitimate times when somebody asks for something and they really actually do want something else but they don't know it. The difference is, in these cases, the "something else" should provide some advantage over the thing they asked for, either for the provider or receiver. Part of the job of a programmer is to figure out what the right way to expose a feature is via an [[API Design\|API]], and part of this skill is knowing how to get to the heart of the requests coming in and provide the features that satisfy the most requests with the least work while simultaneously not designing yourself into a corner...to hit the knee of the cost/benefit curve.

	I'm guilty of saying ''You Don't Need That'' on occasion myself—it's just so easy to rationalize away criticism of things in which you've invested heavily, and a feature request can easily be seen as criticism if you're in the wrong mindset. But, I really strive to take feedback with an open mind, and actively listen and make things better. I'm not sure how successful I'm being; my friend and colleague Tony Gialdini, awesome animator and user of some of my decidedly wacky code, posted this ~~printout~~ on the wall above my desk... :)		I'm guilty of saying ''You Don't Need That'' on occasion myself—it's just so easy to rationalize away criticism of things in which you've invested heavily, and a feature request can easily be seen as criticism if you're in the wrong mindset. But, I really strive to take feedback with an open mind, and actively listen and make things better. I'm not sure how successful I'm being; my friend and colleague Tony Gialdini, awesome animator and user of some of my decidedly wacky code, posted this on the wall above my desk... :)

	<center>[[Image:tell-me-what-you-need.jpg]]</center>		<center>[[Image:tell-me-what-you-need.jpg]]</center>

Checker at 07:45, 31 March 2007

2007-03-31T07:45:08Z

← Older revision		Revision as of 07:45, 31 March 2007
Line 7:		Line 7:
	The hallmark of ''You Don't Need That'' is a reasonable request rebuffed with lots of rationalization about why the software needs to be the way it is, often with a nice helping of condescension towards the requester thrown in for good measure.		The hallmark of ''You Don't Need That'' is a reasonable request rebuffed with lots of rationalization about why the software needs to be the way it is, often with a nice helping of condescension towards the requester thrown in for good measure.

	The right thing is, of course, to listen to the feature request with an open mind, and if it's actually a reasonable request, and there's no actually equivalent functionality and no real workaround that satisfies the user's constraints, then just say so. "Yeah, we didn't have time to do that," "Some early decisions we made to support X make Y hard, sorry," or "Huh, never thought of that, it sounds useful," are all way better to hear than, "You don't really need Y, because if you have Y, then you'll get lazy and then we won't run on teletype over an acoustic coupled modem and we'll ~~sacrific~~ the orthogonality of our architecture."		The right thing is, of course, to listen to the feature request with an open mind, and if it's actually a reasonable request, and there's no actually equivalent functionality and no real workaround that satisfies the user's constraints, then just say so. "Yeah, we didn't have time to do that," "Some early decisions we made to support X make Y hard, sorry," or "Huh, never thought of that, it sounds useful," are all way better to hear than, "You don't really need Y, because if you have Y, then you'll get lazy and then we won't run on teletype over an acoustic coupled modem and we'll sacrifice the orthogonality of our architecture."

	There are, of course, legitimate times when somebody asks for something and they really actually do want something else but they don't know it. The difference is, in these cases, the "something else" should provide some advantage over the thing they asked for, either for the provider or receiver. Part of the job of a programmer is to figure out what the right way to expose a feature is via an [[API Design\|API]], and part of this skill is knowing how to get to the heart of the requests coming in and provide the features that satisfy the most requests with the least work while simultaneously not designing yourself into a corner...to hit the knee of the cost/benefit curve.		There are, of course, legitimate times when somebody asks for something and they really actually do want something else but they don't know it. The difference is, in these cases, the "something else" should provide some advantage over the thing they asked for, either for the provider or receiver. Part of the job of a programmer is to figure out what the right way to expose a feature is via an [[API Design\|API]], and part of this skill is knowing how to get to the heart of the requests coming in and provide the features that satisfy the most requests with the least work while simultaneously not designing yourself into a corner...to hit the knee of the cost/benefit curve.

	I'm guilty of saying ''You Don't Need That'' on occasion myself—it's just so easy to rationalize away criticism of things in which you've invested heavily, and a feature request can easily be seen as criticism if you're in the wrong mindset. But, I really strive to take feedback with an open mind, and actively listen and make things better.		I'm guilty of saying ''You Don't Need That'' on occasion myself—it's just so easy to rationalize away criticism of things in which you've invested heavily, and a feature request can easily be seen as criticism if you're in the wrong mindset. But, I really strive to take feedback with an open mind, and actively listen and make things better. I'm not sure how successful I'm being; my friend and colleague Tony Gialdini, awesome animator and user of some of my decidedly wacky code, posted this printout on the wall above my desk... :)

			<center>[[Image:tell-me-what-you-need.jpg]]</center>

	[[Category:Programming]]		[[Category:Programming]]

Checker at 08:00, 29 March 2007

2007-03-29T08:00:21Z

← Older revision		Revision as of 08:00, 29 March 2007
Line 7:		Line 7:
	The hallmark of ''You Don't Need That'' is a reasonable request rebuffed with lots of rationalization about why the software needs to be the way it is, often with a nice helping of condescension towards the requester thrown in for good measure.		The hallmark of ''You Don't Need That'' is a reasonable request rebuffed with lots of rationalization about why the software needs to be the way it is, often with a nice helping of condescension towards the requester thrown in for good measure.

	The right thing is of course to listen to the feature request with an open mind, and if it's actually a reasonable request, and there's no actually equivalent functionality and no real workaround that satisfies the user's constraints, then just say so. "Yeah, we didn't have time to do that," "Some early decisions we made to support X make Y hard, sorry," or "Huh, never thought of that, it sounds useful," are all way better to hear than, "You don't really need Y, because if you have Y, then you'll get lazy and then we won't run on teletype over an acoustic coupled modem and we'll sacrific the orthogonality of our architecture."		The right thing is, of course, to listen to the feature request with an open mind, and if it's actually a reasonable request, and there's no actually equivalent functionality and no real workaround that satisfies the user's constraints, then just say so. "Yeah, we didn't have time to do that," "Some early decisions we made to support X make Y hard, sorry," or "Huh, never thought of that, it sounds useful," are all way better to hear than, "You don't really need Y, because if you have Y, then you'll get lazy and then we won't run on teletype over an acoustic coupled modem and we'll sacrific the orthogonality of our architecture."

	There are, of course, legitimate times when somebody asks for something and they really actually do want something else but they don't know it. The difference is, in these cases, the "something else" should provide some advantage over the thing they asked for, either for the provider or receiver. Part of the job of a programmer is to figure out what the right way to expose a feature is via an [[API Design\|API]], and part of this skill is knowing how to get to the heart of the requests coming in and provide the features that satisfy the most requests with the least work while simultaneously not designing yourself into a corner...to hit the knee of the cost/benefit curve.		There are, of course, legitimate times when somebody asks for something and they really actually do want something else but they don't know it. The difference is, in these cases, the "something else" should provide some advantage over the thing they asked for, either for the provider or receiver. Part of the job of a programmer is to figure out what the right way to expose a feature is via an [[API Design\|API]], and part of this skill is knowing how to get to the heart of the requests coming in and provide the features that satisfy the most requests with the least work while simultaneously not designing yourself into a corner...to hit the knee of the cost/benefit curve.

	I'm guilty of saying ''You Don't Need That'' on occasion myself—it's just so easy to rationalize away criticism of things you've invested heavily in, and a feature request can easily be seen as criticism if you're in the wrong mindset. But, I really strive to take feedback with an open mind, and actively listen and make things better.		I'm guilty of saying ''You Don't Need That'' on occasion myself—it's just so easy to rationalize away criticism of things in which you've invested heavily, and a feature request can easily be seen as criticism if you're in the wrong mindset. But, I really strive to take feedback with an open mind, and actively listen and make things better.

	[[Category:Programming]]		[[Category:Programming]]

Checker at 09:36, 28 March 2007

2007-03-28T09:36:28Z

← Older revision		Revision as of 09:36, 28 March 2007
Line 7:		Line 7:
	The hallmark of ''You Don't Need That'' is a reasonable request rebuffed with lots of rationalization about why the software needs to be the way it is, often with a nice helping of condescension towards the requester thrown in for good measure.		The hallmark of ''You Don't Need That'' is a reasonable request rebuffed with lots of rationalization about why the software needs to be the way it is, often with a nice helping of condescension towards the requester thrown in for good measure.

	The right thing is of course to listen to the feature request with an open mind, and if it's actually a reasonable request, and there's no actually equivalent functionality and no real workaround that satisfies the user's constraints, then just say so. "Yeah, we didn't have time to do that," ~~or,~~ "Some early decisions we made to support X make Y hard, sorry," are ~~both~~ way better to hear than, "You don't really need Y, because if you have Y, then you'll get lazy and then we won't run on teletype over an acoustic coupled modem and we'll sacrific the orthogonality of our architecture."		The right thing is of course to listen to the feature request with an open mind, and if it's actually a reasonable request, and there's no actually equivalent functionality and no real workaround that satisfies the user's constraints, then just say so. "Yeah, we didn't have time to do that," "Some early decisions we made to support X make Y hard, sorry," or "Huh, never thought of that, it sounds useful," are all way better to hear than, "You don't really need Y, because if you have Y, then you'll get lazy and then we won't run on teletype over an acoustic coupled modem and we'll sacrific the orthogonality of our architecture."

	There are, of course, legitimate times when somebody asks for something and they really actually do want something else but they don't know it. The difference is, in these cases, the "something else" should provide some advantage over the thing they asked for, either for the provider or receiver. Part of the job of a programmer is to figure out what the right way to expose a feature is via an [[API Design\|API]], and part of this skill is knowing how to get to the heart of the requests coming in and provide the features that satisfy the most requests with the least work while simultaneously not designing yourself into a corner...to hit the knee of the cost/benefit curve.		There are, of course, legitimate times when somebody asks for something and they really actually do want something else but they don't know it. The difference is, in these cases, the "something else" should provide some advantage over the thing they asked for, either for the provider or receiver. Part of the job of a programmer is to figure out what the right way to expose a feature is via an [[API Design\|API]], and part of this skill is knowing how to get to the heart of the requests coming in and provide the features that satisfy the most requests with the least work while simultaneously not designing yourself into a corner...to hit the knee of the cost/benefit curve.

Checker at 09:24, 28 March 2007

2007-03-28T09:24:27Z

← Older revision		Revision as of 09:24, 28 March 2007
Line 1:		Line 1:
	~~{{todo}}~~		There's this phenomenon that sometimes surfaces when you get smart people who are extremely loyal to a particular piece of software or process, and then the software or process is criticized for lacking a feature or failing to address a concern. I call it ''You Don't Need That''.

			This mentality is sometimes displayed surrounding feature requests in my favorite editor, [[Emacs\|GNU Emacs]]. I love Emacs, but it's pretty pathetic that it doesn't have soft returns (sometimes called "word wrap") and it's on version 21.x as of this writing<ref>Apparently version 22 will finally be adding them, yay!</ref>. Heck, Windows notepad.exe has word wrap. This lack of functionality, by itself, is bad enough, but worse is when a newbie asks about the the feature, and partisans try to convince the newbie that they don't want the feature in the first place.

			I wish I could find an example of this happening to link or reproduce here, either with Emacs, or with any other software. I remember reading threads like this when I last searched for information about word wrap in Emacs about 4 years ago but I can't find a good link now. Let me know if you have a link to a good example and I'll post it here.

			The hallmark of ''You Don't Need That'' is a reasonable request rebuffed with lots of rationalization about why the software needs to be the way it is, often with a nice helping of condescension towards the requester thrown in for good measure.

			The right thing is of course to listen to the feature request with an open mind, and if it's actually a reasonable request, and there's no actually equivalent functionality and no real workaround that satisfies the user's constraints, then just say so. "Yeah, we didn't have time to do that," or, "Some early decisions we made to support X make Y hard, sorry," are both way better to hear than, "You don't really need Y, because if you have Y, then you'll get lazy and then we won't run on teletype over an acoustic coupled modem and we'll sacrific the orthogonality of our architecture."

			There are, of course, legitimate times when somebody asks for something and they really actually do want something else but they don't know it. The difference is, in these cases, the "something else" should provide some advantage over the thing they asked for, either for the provider or receiver. Part of the job of a programmer is to figure out what the right way to expose a feature is via an [[API Design\|API]], and part of this skill is knowing how to get to the heart of the requests coming in and provide the features that satisfy the most requests with the least work while simultaneously not designing yourself into a corner...to hit the knee of the cost/benefit curve.

			I'm guilty of saying ''You Don't Need That'' on occasion myself—it's just so easy to rationalize away criticism of things you've invested heavily in, and a feature request can easily be seen as criticism if you're in the wrong mindset. But, I really strive to take feedback with an open mind, and actively listen and make things better.

			[[Category:Programming]]
			[[Category:Opinions]]

			<references/>

Checker: New page: {{todo}}

2007-02-21T11:13:36Z

New page: {{todo}}

New page