Practicing the Fundamentals: The New Turing Omnibus

While researching Classic Computer Science Puzzles, our CEO Scott Stanfield turned me on to A.K. Dewdney's The New Turing Omnibus: 66 Excursions in Computer Science.

This is a companion discussion topic for the original blog entry at:

I’m really liking the link that someone posted in the previous thread.

I can work out clever answers, or I can be lazy and bruteforce.

It’s also #6 on the “Movers and shakers” list at Amazon:

Sales are up 24,367%, LOL

Sales are up 24,367%, LOL

The power of Internet blog advertising. You should get a kick-back from the publisher/author.

As a (black-belted?) go player I must protest! We do not use belts, although kyu / dan ranking is used. :slight_smile:

What would be the fundamentals that a good programmer might forget?

KISS. RTFM. PEBKAC. DRY. If it ain’t broken, don’t fix it. Cheap, fast, accurate; pick two. If your program is idiot-proof, they’ll find a better idiot. Any piece of software reflects the organizational structure that produced it.

Ian said,

“The power of Internet blog advertising. You should get a kick-back from the publisher/author”

But if he were, we could no longer trust his recommendations.

A good book is always welcome but a good blog generates great discussions! :slight_smile:

If you make an idiot-proof program, you probably won’t be able to use it.


You got me thinking about what are the programming fundamentals. It’s not like Go where you are refining your skill at a single task over and over. Programming is funny since once you solve the problem there is no need to solve it again if you are a subscriber or DRY.

Furthermore, if you are a subscriber of DROPE (Don’t Repeat Other People Either - OK, I just made that up) you shouldn’t have to solve a problem that anyone else has either. So what’s the fundamental skill/task that you need to practice?

Continuous learning, IMO. You can’t be DROPE if you don’t know what other people are doing. It’s human nature to try and find a comfort zone and coast, but for programmers this is a downward spiral of lowering productivity. Once you start reinventing the wheel you are no longer productive and your reinventions are likely to be inferior to what has already been done.

Learning is hard work so one needs to keep that muscle in shape. So even if you don’t have anything you need to learn now, you should still be doing it just to be ready for the time when you do need to - that is, practicing learning.

If you make an idiot-proof program, you probably won’t be able to use it.

That’s an interesting postulate. If we rule out the typical cases of “lock yourself out of your home” by inattention, e. g. through forgetfulness, obfuscation or over-the-top security, that leaves this question: Would you be able to create a program that’s more intelligent than you are? And as idiots are always the others, and you usually take this as your gauge, how probable is it? :wink:

Once you start reinventing the wheel you are no longer productive and your reinventions are likely to be inferior to what has already been done.

Nicely said, but I’ll provide this as a counterpoint:

Amazon have the same book, used, published by W.H.Freeman but out of print for under $9 here:

I’m not the seller, I just found it and bought one!


I disagree with “Do It Yourself” - at least as it applies to the “real world”. There’s a distinct difference between “school work” and “paid work”. In the first copying is cheating and in the second copying is productivity. I agree that a person learns the best by doing, but they don’t often come up with the best result. You might fiddle around with something to learn the concepts, but you don’t build your enterprise app that way.

The take away from the crypto post was that you should not try and roll your own. All non-trivial, real world, problems fall into this category. There are experts and a body of work out there (especially with the rise of Open Source) that far exceed anything a single dude with a computer can come up with.

At the end of the day, we, as programmers are (or should be) judged by how productive we are. Did you write a high quality program in a reasonable amount of time? Not how clever you were. It’s been shown again and again that the best programmers are the humble ones that know their limitations and work within them.


Hey Now Jeff,
Omnibus - for all every. The page screen shot is classic still enjoying your blog.

One often forgotten lesson:

Code is twice as hard to read than it is to write, so you should only code at half smartness, or you won’t be able to understand it when you come back to it later.

@Matt, re DROPE:

I’ve just been calling that DROP (same meaning, without the “Either”). It’s part of the wheel reinvention problem that comes along quite a bit. When you’re working for such a small company as I am, it’s always important to remember that 10 minutes to search for and download something useful is a lot better than a week writing it yourself.

Just bought a copy from Amazon. I love your blog and if this book is as good as your site then I will be a happy man.

If not, then I still have your site to read every morning.

Kee Dewdney is great, I used to love his columns in Scientific American when I was a kid. If you can find his book “The Planiverse”, it is also an enjoyable fantasy elaborating upon the famous Victorian excursion into lower dimensions, “Flatland”.

Good puzzle here. Why is the door on the wrong side? Did Routemaster ever make a bus for a country where they drive on the wrong side? I doubt it.

I agree. This is a great little book. Every year I say I am going to work my way through the entire book. Then something else grabs my attention and I don’t finish it. Now, you’ve gotten me to the point where, once I again, I say, “This time, I’m going to work my way through the entire book.” We’ll see.

By the way, your sample chapter is Chapter 49, not Chapter 33.

If your program has a bug remember that a good programmer is usually off by one somewhere.