When I hear people start talking about “natural” programming, easier ways of programming or making programming available to non-programmers, I get very skeptical. It makes me think of Logo and Turtle Graphics, or programming languages made to be more similar to natural language. It’s like you could make a simpler English to make it easier for non-authors to write literature. So when I first read about The Natural Programming Project, I balked – although for no reason. The researchers working on NPP certainly does approach programming with the aim of making it easier for laypeople, which seems like a turn-off. However, the output of the project is surprisingly interesting to the professional:  Lab studies scientifically testing the utility of design[…]

Wil Shipley has an excellent blog post on how using simple heuristics – ie. less-than-perfect shortcuts to a goal – can improve life significantly, and how we tend to ignore that. He makes a point about user interfaces, but it is good as a general observation:  A good-enough solution that improves life for many people is better than a perfect solution that can’t possibly be made. Also, he points out that classic programming theory will teach you a lot of computer-sciency methods for problem solving, while in real-life are heuristic methods trying to understand user input as good as possible. That, however, I think is because he is a good programmer, not something all programmers come across: I bet the[…]

Jeff Atwood’s blog Coding Horror has a great post about failing projects! This qoute by Charles Bosk is great: In my interviewing, I began to develop what I thought was an indicator of whether someone was going to be a good surgeon or not. It was a couple of simple questions: Have you ever made a mistake? And, if so, what was your worst mistake? The people who said, ‘Gee, I haven’t really had one,’ or, ‘I’ve had a couple of bad outcomes but they were due to things outside my control’ — invariably those were the worst candidates. And the residents who said, ‘I make mistakes all the time. There was this horrible thing that happened just yesterday and[…]

A quick find: I’ve been wanting to read the programming management classic “The Mythical Man Month” for years, but have never gotten around to it.  Turns out there is a  chapter-by-chapter summary that has been online for only 19 years (!). Enjoy getting through a classic in two hours. However, the whole book can be summarized with the following koan from the Tao of Programming: A manager went to the master programmer and showed him the requirements document for a new application. The manager asked the master: “How long will it take to design this system if I assign five programmers to it?” “It will take one year,” said the master promptly. “But we need this system immediately or even[…]

Occasionally, programming forums take a step back from the nitty gritty implementation details and look at the bigger issues. I wish they did more often, as “occasionally” means pretty much close to never. Most discussions in technical forums rarely go past what you can find in the manual, while the big things that can make or break a project (or a programmer) goes unmentioned. So Elisheva‘s discussion “Swallowing and Elephant in 10 easy steps” on how you go about to understand large, new systems was a very interesting diversion at Perl Monks.  There’s only a few quality thoughts past the original posters musing, sadly, but it is nice to see someone touching this subject in a serious way. Another thought on[…]