Egotistical architects and city planners with big schemes scare me, they forget that the cities that work best work on a personal, local level.
http://www.theguardian.com/cities/2014/apr/17/india-smart-city-dholera-flood-farmers-investors
This was posted 6 hours ago. It has 0 notes.
The paradox of poverty is that tomorrow is unpredictable but the future never changes.
https://medium.com/p/fa4c36eb306b
This was posted 3 days ago. It has 0 notes.

"It may well turn out that one of the most important effects of open source’s success will be to teach us that play is the most economically efficient mode of creative work."

This was posted 4 days ago. It has 0 notes.
There is a more general lesson in this story about how SMTP delivery came to fetchmail. It is not only debugging that is parallelizable; development and (to a perhaps surprising extent) exploration of design space is, too. When your development mode is rapidly iterative, development and enhancement may become special cases of debugging-fixing `bugs of omission’ in the original capabilities or concept of the software.
This was posted 1 week ago. It has 0 notes.
I grew my beta list by adding to it everyone who contacted me about fetchmail. I sent chatty announcements to the beta list whenever I released, encouraging people to participate. And I listened to my beta-testers, polling them about design decisions and stroking them whenever they sent in patches and feedback. The payoff from these simple measures was immediate. From the beginning of the project, I got bug reports of a quality most developers would kill for, often with good fixes attached. I got thoughtful criticism, I got fan mail, I got intelligent feature suggestions.
This was posted 1 week ago. It has 0 notes.
Sociologists years ago discovered that the averaged opinion of a mass of equally expert (or equally ignorant) observers is quite a bit more reliable a predictor than the opinion of a single randomly-chosen one of the observers. They called this the Delphi effect. It appears that what Linus has shown is that this applies even to debugging an operating system-that the Delphi effect can tame development complexity even at the complexity level of an OS kernel.
This was posted 1 week ago. It has 0 notes.
8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone. Or, less formally, “Given enough eyeballs, all bugs are shallow.” I dub this: “Linus’s Law”. My original formulation was that every problem “will be transparent to somebody”. Linus demurred that the person who understands and fixes the problem is not necessarily or even usually the person who first characterizes it. “Somebody finds the problem,” he says, “and somebody else understands it. And I’ll go on record as saying that finding it is the bigger challenge.” That correction is important; we’ll see how in the next section, when we examine the practice of debugging in more detail. But the key point is that both parts of the process (finding and fixing) tend to happen rapidly.
This was posted 1 week ago. It has 0 notes.
Linus was keeping his hacker/users constantly stimulated and rewarded-stimulated by the prospect of having an ego-satisfying piece of the action, rewarded by the sight of constant (even daily) improvement in their work.
This was posted 1 week ago. It has 0 notes.
Or, to put it another way, you often don’t really understand the problem until after the first time you implement a solution. The second time, maybe you know enough to do it right. So if you want to get it right, be ready to start over at least once.
This was posted 1 week ago. It has 0 notes.
While I don’t claim to be a great programmer, I try to imitate one. An important trait of the great ones is constructive laziness. They know that you get an A not for effort but for results, and that it’s almost always easier to start from a good partial solution than from nothing at all.
This was posted 1 week ago. It has 0 notes.