09Dec

Great chess players don’t see the pieces, they see the board. Great programmers need to learn from that.

Posted by Elf Sternberg as programming

I had an insight the other day, while working with one of the younger colleagues at work, about why I come up with answers and write code so much faster than he does. It’s not that he’s not as smart or as talented as I am, it’s that we look at programming problems in a completely different way.

In a paper from 1974 entitled How Big is a Chunk, Herbert Simon attempted to codify what makes beginning chess players different from grand masters. The answer, Simon believed, is that beginners see pieces and masters see “chunks:” collections of pieces that form a strategic unit on the board, and that can be exploited against other strategic units. Simon built on George A Miller’s notion of “the magical number seven plus or minus two”– the biggest “chunk” that a human brain can handle. Miller argued that we remember a phrase of “seven words,” which could have as many as two dozen syllables, so the “word” was a piece of the chunk, not the syllable, and so on. Simon believed that a “chunk” of chess could have seven “pieces in position” in it, and that a grand master of chess could have anywhere between 25,000 and 100,000 chunks in his head, ready to deploy at a moment’s notice. This is why a grand master can play dozens of games of chess against beginners simultaneously; he doesn’t have to memorize the state of every board, he just has to look at the board and to identify its riskiest chunks and respond accordingly.

My colleague is a huge fan of test driven development (TDD), but what we were developing as a pair programming exercise was a view: there was minimal logic to be written, only some dynamic HTML (well, React) to take data that was already available and present it to the end user in a highly digestible format. Our goal was to remove the repetitive legends automatically generated for many graphs on a page, and replace it with a deliberately generated legend for all the graphs.

“Let’s do this TDD style. Put an empty object on the page,” I suggested. “Okay, make it show the wrong thing. Now, we know the legend was there before with the right labels. We had to supply those labels, let’s go find where they’re generated. How are they cross indexed with the colors? Write that down. Okay, let’s change the wrong thing to show the names. Now add a rectangle with the colors.” When we had that, I said, “Okay, I think you know how to use Flex to lay out the legend, add a title, all that, right?” He agreed that he did. “Oh, and people print this out. Remember that thing we did where we made sure that there were only two graphs per page, and used the CSS ‘no page break’ thing to make sure?” He nodded. “Each page will need a legend, but you’ll have to hide all but the last one in display, and show all of them in print. You know how to do that too, right?”

It all took us about two hours. When it was done, he shook his head and said, “I would never have gotten there that fast. This would have taking me days.”

I assured him he’ll get there. But I realized that the reason I got us there so quickly is that I had a chunk in my head about how HTML works, and another chunk about where the data came from, and a third chunk about how Javascript merges the two. He doesn’t have that experience yet, so he sees rows and <divs> and arrays and classNames and color codes. But that’s the underlying stuff, the pawns and rooks of the game. That’s not the chunks.

The only question left is how to teach these people how to chunk stuff, and what to chunk, and why.

Comment Form

Subscribe to Feed

Categories

Calendar

December 2019
M T W T F S S
« Nov   Jan »
 1
2345678
9101112131415
16171819202122
23242526272829
3031