Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼

Matthew Wilson

Dr. Dobb's Bloggers

Programming: Sudoku With a Time Limit?

September 07, 2010

I've been searching for a metaphor for programming, to help explain to my sons the curiosity, the intellectual satisfaction, the maintenance of multiple simultaneous concepts in the brain, the tremendous importance of experience and of metaphor, and the occasional intense pressure of what it is I do for a living.

I've been lapsed in all my writing activities of late - due to a rather large and important deadline looming in a few weeks' time: through 2010 I've been involved as an expert witness on an IT fraud case, and we're getting down to the pointy end. (It's the most rewarding work of my career, but there's a lot of pressure - much of which is self-imposed, natch.)

The performance of my fatherly duties have also been somewhat truncated, at least as far as household duties and playing football (the one where you kick the ball with your foot ;-) and Nerf war with the boys, and for the same reason. (Except for last weekend, Father's day here in Australia, when I was the proud recipient of a Raider CS-35, a pump-action multi-fire Nerf rifle. We're still finding darts all over our home!)

At times like this, the boys have trouble understanding the ebbs and flows of my workload. For most of their lives, Dad's been at home, "doing stuff on the computer", and, when not out on his bike, often able to manage his time to break off to play, read, watch TV, shout (when the occasion arises), or whatever else the boys want to do. I've succeeded to some degree in explaining to them that working really hard at school/university helps to give you choices in life, and that I've been fortunate in that respect to a reasonable degree. What I've been much less successful at is explaining what it is I actually do.

As far as my friends and family - and most other non-programmers, for that matter - are concerned, computers are "machines that do things for you". When computers go wrong, the interpretation is that someone's done a bad job, or taken a shortcut. And, a lot of the time, that's true. But that's not the whole picture: sometimes it's an inescapable function of the scale and complexity of the systems. Trying to explain to non-programmers that programmers face an impossible task in reconciling the precision of software systems with their complexity - a phenomenon I call the unpredictable exactitude paradox - is very difficult. Let's be blunt, many computing professionals struggle to comprehend this issue, and all of those that do struggle to live with it!

Of late, I've found a better approach is to focus on the contradictory mix of intense fun and intense pressure that occurs in many commercial programming activities. The best analogy I've come up with so far is: programming for a living is like playing Sudoku with a time limit.

Many people - my sons and me included - like playing Sudoku. When we go away on short breaks I always buy a Sudoku book, and hack away at it while lounging around, alternating with a novel or two. (There's always a pile of programming books as well, which I never fail to bring, yet always fail to open. Go figure!)

Anyway, my modus operandi for Sudoku is to rush through the Easy and Medium ones - assuming I get to them before the youngest son does - one after the other, as fast as possible. Once I hit the Hard and Extreme sections, however, this systematic approach founders. I'll try the first Hard, and go as far as I can easily go, and then move on to the next. Except for the occasional Hard, whose particular patterns happens to tally with some way of my thinking, I'll skip from one to the next, adding in whatever's easiest as I go. Only when I've got a smattering of numbers in every Hard, will I then "bother" to start the hard work of finishing them off. Same goes for the Extreme section.

Part of the problem is that I refuse to annotate the empty boxes with possible candidates, or to test out possible solutions on a sheet of paper. It may be delusion, but my reasoning is that I keep my brain fit by eschewing such expediencies. (I realise I may be wrong: my mum has no scruples about annotating, and usually Sudokus far more efficiently than me. But then, she is the only member of either side of the family that finishes cryptic crosswords as a matter of course.)

Naturally enough, I muddle partially through most of the Hard, and several of the Extreme, items in my haphazard fashion. Occasionally, one'll annoy me so much I'll sit and think and won't give up no matter what, but to most of them I'll give a phlegmatic shrug, and just enjoy my holiday. That is, of course, because I'm supposed to be relaxing, and intend to do so, and absent anyone holding a knife to my throat I'd be a fool to do otherwise.

And this is where programming commercially differs from Sudoku. Sometimes you have to complete that puzzle, no matter how extreme. When I put it to my son that he might have to finish a given puzzle, no matter what, he fixed me with a look of quizzical disbelief, and declared that if he couldn't do it, then (of course) he wouldn't do it. Q.E.D. Self-evidently correct. Except that in programming, sometimes you have to, nonetheless.

Granted, this simile is imperfect. But it's the one I'm using at dinner parties and school camps this year. I'd be interested to hear from anyone who has a good alternative.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.