"I think the reason that webmonkeys are so desperate to feel they're doing something grand is rather simple. Their work is simply....too....boring. All these frameworks and web doodahs are more often than not simply the product of a hopelessly bored mind desperate to inject some sense of meaning into their daily grind. All the business asked them to do was product an app that solved a specific need. Nobody told them to go invent a framework for it, or to maximise reusability, or to componentise the moving bits, or to use TDD, or to opensource anything.

"Yet, all these things happen. The poor developer's task is so menial and trivial that he is forced to go out of his way to justify his sad pathetic little existence. What better way than to open source it and seek approval from other equally sad pathetic individuals? What better way than to inject the project with what is perceived to be cutting edge, intelligent, and exciting?"

"I used to think that all eyes were on me, just waiting for me to be great!... I thought everyone really cared! I thought it all mattered!

"But... ...what if I wasn't great?"

Labels: passion

…in which everything is possible but nothing of interest is easy.

Alan J. Perlis

What is the Turing tar-pit? It’s the place where a program has become so powerful, so general, that the effort to configure it to solve a specific problem matches or exceeds the effort to start over and write a program that solves the specific problem.

I suffer from a tendancy to go swimming in tar. I start out trying to solve a specific problem. I become frustrated with the obvious deficiencies of the tools, and before I know it I’m sketching out ideas for platforms, frameworks, and architectures to solve a whole class of similar problems.

(This is especially dangerous for programming language designers. There’s an irresistable urge to reduce a language to the smallest, most elegant core of axioms.)

I think a programming language should be mostly defined in itself. A language spec should be divided into two parts, a small core of operators that play the role of axioms, and the rest of the language, which, like theorems, are defined in terms of the axioms.

Paul Graham

The danger of the tar-pit is that instead of developing a solution to a problem, you develop a tool for solving problems. And invariably, the wider the class of problems the tool can solve, the less useful it is for solving any one problem.

In my own case, I often find myself engaging in “bottom-up programming,” trying to invent the perfect programming language for expressing the program I’m trying to write. When I find myself working on language syntaxes, I realize I’m mired in tar and I need to reset.

The Turing tar-pit’s lure is that it is situated right in the centre of some of the most attractive real-estate in your imagination. Tools that solve whole classes of problems in generic ways offer the potential for vast improvements is productivity. Consider VisiCalc: this application actually turned its users into programmers!

In programming, everything we do is a special case of something more general—and often we know it too quickly.

Alan J. Perlis

The very exercise of trying to understand the relationship between the problem you’re trying to solve and the general class of problems can help you understand your problem in more detail. And you can get some wonderful Aha! moments.

So I believe that to do really great work, you must be prepared to skirt very close to the edge of the tar-pit. Hopefully you have an iron will and can avoid disaster with ease.

In my own case, I have little will and I’m further hampered by an enormous curiosity. Out of self defence, I’ve developed some heuristics for exploring the edges of the tar-pit and mining generalization for insights:

1. Keep Alan Kay’s words in mind: “We aim to make simple things simple and complex things possible.” When solving the general problem makes complex things possible, that’s good. But it shouldn’t be at the expense of making simple things simple.
2. Mentally retrace your steps to the safe safe ground of the problem domain on a frequent basis. In my own case, I work with fairly disposable user stories. The important thing I do is return to them every once in a while and ask “how will this marvellous widget make any of these things easy?”
3. Eat your own dog food/go round trip on an infrequent basis. Okay, you’re convinced you need to run your application inside a special purpose virtual machine. Fine. Pick one small operation and make it work. Program for your virtual machine, end to end. Don’t skip any of the steps. It’s better to go thin (few functions) and deep (use the entire stack) than to go wide and shallow. If your VM is a pain in the rump, you’ve discovered something. (This is a cornerstone of Ken Schwaber’s Scrum methodology).
4. Don’t beat yourself up if you get mired. If you never produce anything more than an esoteric programming language or tool, you’ll still have gone where strong minds fear to tread. Okay, your started out trying to solve problem A and you found yourself solving a general class of problems C that doesn’t even include A. Once again, Alan Kay: “A successful technology creates problems that only it can solve.” Don’t be so sure you haven’t created something really important. Finish it up, you won’t know what you have until you start using it.

Are you quite sure that all those bells and whistles, all those wonderful facilities of your so called powerful programming languages, belong to the solution set rather than the problem set?

Edsger Dijkstra

Amen.

Labels: popular