http://www.recombinantrecords.net/docs/2009-05-Amusing-Ourselves-to-Death.html

I find this section the most interesting:

One of the things that makes recognizing Sudoku puzzles an easier task than most image processing/recognition problem is that it is a highly constrained problem – a standard Sudoku puzzle is going to be a square grid and it will only contain the printed numbers 1-9.

These two points are very important. The first point – it’s a square grid tells us what shape a puzzle is and what we should be looking for in an image. The second point – it will only contain the printed numbers 1-9 tells us that we aren’t going to need a sophisticated OCR system. When we look at the problem there’s nothing that jumps out and says “nobody has solved this before – it’s probably really hard”.

We can also add some additional assumptions -

1. In a photograph of a sudoku puzzle, the puzzle is going to be the main/most important object on the page
   A user is going to be photographing the puzzle – they aren’t going to take a picture of a whole newspaper page, they won’t be taking a photograph of a coffee shop and expecting us to find a sudoku puzzle that someone is playing four tables away. Also, the user is going to try and capture the whole puzzle, they won’t miss a corner or chop off the top.
2. The puzzle will be orientated reasonably correctly.
   No-one (hopefully) is going to be taking a picture of an upside down puzzle, and typically they will be trying to align it nicely in the camera viewfinder so it is reasonably straight without too much distortion.

A great example of how some simple assumptions made about your problem make it far easier to solve. Of course, the key is making sure the assumptions are valid, or being prepared to handle edge cases where these assumptions prove false.

One of the (many) unfortunate side effects of choosing a career in software development is that, over time, you learn to hate software. I mean really hate it. With a passion. Take the angriest user you’ve ever met, multiply that by a thousand, and you still haven’t come close to how we programmers feel about software. Nobody hates software more than software developers.

This is so true it hurts. An additional side effect of being a Program Manager is that you become extremely critical of everything. Parking meters. Elevator buttons. Anything that isn’t as usable as it should be. Not that I could do any better at designing these things, necessarily, but they still anger me, and much more than they used to now that design is a part of my daily work life.

Another great quote from the article:

Hardware companies don’t generally do software well. Digital camera companies excel at building digital camera hardware. Software, if it exists at all, is an afterthought, a side effect, a checkbox on some marketing weasel’s clipboard.

This is true not only for consumer electronics like digital cameras, but also for other hardware that you might not think of as running “software.” Think of your microwave. The ice dispenser on your fridge. Your washing machine. Your car’s on-board computer. All of these are running software in some fashion most likely, and they all kind of suck.

You know that when you type “two cups of flour and two eggs” (which now works) you are looking for a Nutrition Facts label. It is only Stephen Wolfram’s giant electronic brain which has to run ten million lines of code to figure this out. Inside your own brain, it is written on glowing letters across your forehead.

Wolfram Alpha and hubristic user interfaces

http://www.zephoria.org/thoughts/archives/2009/05/27/when_teachers_a.html.

http://jiggmin.com/play_game.php?title=Effing+Hail

http://topherchris.com/post/106795199/recommendation-letter

Who Watches the Watchman? (via Daring Fireball)

I started calling these Wikipedia Walks. The concept is simple – start at an article you find interesting, then just continue on to any articles linked from the original. Finish when you get bored. To make it more interesting, you should record both the starting article and the ending article, so you can see just how far off the beaten path you’ve gotten.

To start, I’d suggest the article on Game Theory.