Seth Godin on listening to your customers. A great summary of the balance of customer satisfaction and gleaning the gold from the loud people.

I’ve been gravitating toward web development in the past few years. If anyone is curious, here is my basic approach to web site (and web application) development:

1. Concept: do interviews, write stories about the site/application, create & collect storyboards, sketches, swatches, metaphors, and ideas
2. Pitch: redraft storyboards and organize other materials into a final set including basic requirements if software is needed
3. Plan: milestones, resources, inter-dependencies (only if the $ or scale requires it)
4. Design: site + URI maps, basic visual design, information design, software design
5. Analysis: review design, prototype tough bits, capacity analysis, reflect, and improve as needed
6. Bootstrap: server setup, source repository setup, shell out software and content
7. Development: short, minimalist development (simple styles, skip color + bling, simple implementations, simple code)
8. Finishing: a small amount of review, refactoring, reflection, and improvement (only enough to get off the ground)
9. Release: start internal, limited beta, public beta, version 1, etc.
10. Spit and polish: make things shine
11. Repeat: goto 8 until version 1, then continue incrementing as $/time allow

Notes

• Web development only differers from other software in how easy it is to release quickly
• Some of these items can be skipped, depending on the size of the project
• Many of these items can parallelized with the right people, or when stalled on preceding items
• Too much parallelization becomes chaos (must balance it)
• You must release before polishing, even if internally
• Internal (and beta) releases must be real … if you fake them, the results are useless
• Milestones are critical to finishing, in that you need to finish the project in stages for psychological reasons (or you may never finish)
• Analysis cannot be skipped, even if short (capacity, data, information, etc.)
• If you’re developing framework, then you’re project will fail: focus on your goal
• Use the simplest tools possible: paper, pen, wikis, existing libraries, etc.
• Metaphors, swatches, and examples are cool, and are cheaper than visual-design from scratch

Are you a Dummy? David at 37Signals argues that the “Dummies” mentality is a weak form of thinking, where the reader of the book psychologically cheats themselves into the dummy mentality, helping to fulfill their destiny as such.

I think it’s simpler than that. The “Dummy” books (and their low-end counterparts) are crappy information. They’re like fast food and couch-ups for the mind. You put garbage information in, you get garbage thinking out.

I first noticed the GIGO textbook effect with a few books I bought on C++ in the early-mid 1990s. I knew C fairly well (thanks to K&R and Plauger), so I figured learning C++ would be a breeze. I picked up a few cheap texts at a local bookstore and went on my merry way. Months later I was still struggling with the language. I didn’t understand why until I went back to my old C texts: they were simpler and clearer than my new C++ books. The C++ texts were part of a newer generation of material infected with screen-shots, compiler-settings, and half-truths. They were horrible.

At the time, I couldn’t discern between good information and bad, and I had filled my head with a bunch of weak metaphors and buggy examples. The problem was that I didn’t realize that there was a difference in quality of information, and how important that quality was to learning. And it wasn’t just the correctness of the information either, it was the whole approach to critical thinking that an author impresses on you: things like how a language should be used, what was intended, and how it actually works.

Later I relearned C++ through the eyes of Stroustrup, Plauger, comp.lang.c++, and such. It was a different language. There was no mystery. I knew what should be possible, and where to look when it wasn’t.

I never think about the audience. If someone gives me a marketing report, I throw it away. - Wall-E creator Andrew Stanton

Why programmers should play Go. A good argument for stretching your thinker in weird and wonderful ways. I’ve played my share of Go over the years, and while I can’t claim to be good at it, I can say that it has changed how I think. The important thing to remember, though, is that the stretching isn’t just a result of learning the game, it’s also the result of thinking about the game, and reflecting on the patterns of play and tactics.