1) Pick an area that most newbies don't get (ie, requirements)
2) Blather on for a while about all the ways they are done wrong
3) Miss the point of the topic. In requirements, you list what you do, then do it. Instead confuse key terms, like "user" and "customer", or "grill" with "be immersed in"
4) Try to be funny
5) Make sweeping conclusions that are obviously incomplete in the real world "Code only for yourself" -- so everybody with a need now has to have a programmer with the same exact need? Wow.
6) Throw in some generally accepted wisdom ("find something good and take stuff out") as a way of tossing the crowd a bone
7) Profit!
As a general rule of thumb, if somebody comes to you with a common phrase from software engineering and makes a sweeping statement (a friend just blogged "reviews are worthless!") then they are either pulling your leg a little bit or don't know what the heck they are talking about. The usual method of attack is to describe how something is commonly done and then disparage the concept by way of association.
If you don't eat their sandwiches, then you'd better have a LOT of friends who eat them every day, or you're breaking the cardinal rule
The point of that long winded article is don't build something unless you are going to use the product or personaly know a lot of people who will. Never ask people you don't know what they want it's stupid. Take the segway it's cool but it's clearly something people want in the abstract even if it's not useful 99% of the time which is the type of thing you build when you ask people what they want without having any idea what you want to build.
An example of the opposite as a datapoint: We've all eaten institutional food cooked by people who are following a recipe they may not particularly care a whole lot about and probably won't eat their own cooking.
We are developers so I think the question is the rate of adoption of new recipe's at McDonalds? They are spending money on new recipe's and advertising them etc but how many of there new ideas catch and are still in use in 5-10 years? And how many of the successes are based on what someone wants to eat vs. what they think other people might buy.
Formula for blog entry:
1) Pick an area that most newbies don't get (ie, requirements) 2) Blather on for a while about all the ways they are done wrong 3) Miss the point of the topic. In requirements, you list what you do, then do it. Instead confuse key terms, like "user" and "customer", or "grill" with "be immersed in" 4) Try to be funny 5) Make sweeping conclusions that are obviously incomplete in the real world "Code only for yourself" -- so everybody with a need now has to have a programmer with the same exact need? Wow. 6) Throw in some generally accepted wisdom ("find something good and take stuff out") as a way of tossing the crowd a bone 7) Profit!
As a general rule of thumb, if somebody comes to you with a common phrase from software engineering and makes a sweeping statement (a friend just blogged "reviews are worthless!") then they are either pulling your leg a little bit or don't know what the heck they are talking about. The usual method of attack is to describe how something is commonly done and then disparage the concept by way of association.