TopCoding

"An expert is a person who has made all the mistakes that can be made in a very narrow field." -- Niels Bohr

An error-prone physicist

I've been thinking about mastery lately, after reading books like Outliers and discussing Talent is Overrated with my brother.  The basic premise of the latter is that mastery is achieved by many hours of mindful practice of things that are within your grasp.  At any point in time, there are

1. things you can already do,
2. things you could do with some practice, and
3. things you might eventually be able to do but are not within your grasp yet.

Since time is a precious resource, you should avoid either striving for things far outside your ken or sticking with what you already know.  You should try to attain what is within your reach and will cause you to improve.

How do you improve as a programmer?  For the last few months, I've been practicing on TopCoder.  TopCoder is a free programming competition site with a number of areas for competition, though it centers around algorithms.  I had tried it when my grad student advisor first told me about it around ten years ago, but my initial and incorrect impression was that it was only for can't-see-the-forest-for-the-trees hackers who loved writing cryptic and nested for loops and who never had any other plans for the evening.  To be sure, doing the competitions and practice problems is a bit like practicing musical scales, but if you're serious about your craft, then you should be serious about practicing.  By and large, the kinds of problems you can find at TopCoder will challenge you in ways that you might not get at work, and they let you do it in a focused manner.

TopCoder's algorithm problems should help you practice the mapping of a real problem to algorithms and data structures, which is really the heart of what it means to be a programmer.  I suggest starting with Division II problems.  I didn't realize there was a difference at first and was highly discouraged by a Division I problem that eluded me for hours.  Each division has easy, medium, and hard problems which you can do at your leisure.  I've been practicing using Java, since I've been spending more time lately with the language and want to learn it well, though it seems like the top ranked programmers use C or C++.  Make sure you look at other people's code after you've tried a problem.  I've been following a guy named DoublePointer, who also programs in Java, and seems to have done every single problem.

I'll admit that some of the worse problems--or perhaps the problems I like the least--are the ones that admit of no answer besides many nested loops where you have to keep track of multiple indexes.  Solving any problem will involve some measure of implementation and some of algorithm design, but these tend too much towards the former.  In general, however, I think the problems on TopCoder are excellent.  Not only do they let you practice at a level within your grasp, but you get to learn about all kinds of subjects, like lotteries, tire rotation, and Incan numbering systems.  I recommend trying a practice set each week.  That should only take an hour or two.

In the end, mastery is all about doing things you can't quite do, which means making a lot of mistakes.  Practice makes perfect because it's in practice where you get to screw up when no one is looking.  I give many thanks to TopCoder for the chance to mess up and learn from what I've done  wrong.  My TopCoder profile consists entirely of the Bohr quote above and is my inspiration to keep at it when I get frustrated by a tough problem.

Lessons From the Amish

Having grown up near Pennsylvania Dutch country, I know surprisingly little about the Amish. The extent of my knowledge includes only the great variety of delicious deserts they make. So, I have to take the word of Kevin Kelly, who has spent much time with the Amish, in order to understand their approach to technology.

According to Kelly's research, there are very few examples of any cultures prohibiting the use of technology. Of course, many people decide not to drive, watch TV, or pay for data plans, but it's not often that we as a nation, culture, or society say 'No' to technology. The Amish, however, do this all the time.

Amish love their scooters

I had always thought that the Amish were anti-technology and lived in an unchanging world. In fact, they are obsessed with technology. Early adopters try out new technologies and the community sees what happens. Right now, for example, they're experimenting with solar power and cell phones. Standard land-line phones are typically housed in shacks far away from homes. Cell phones will likely be limited to areas outside the home, such as vans, if they are adopted.

That's right--the Amish use electricity, automobiles, refrigeration, genetically modified crops, and many other modern conveniences. But they use them in their own, deliberate ways. Kelly notes that:

• They are selective.
• They evaluate new things by experience instead of by theory.
• They have criteria by which to make choices.
• The choices are not individual but communal.

What is the problem that the Amish have found with many new technologies? They disrupt the strong familial and communal life that they cherish. These values are so important that the Amish make sure everyone who is a part of the community wants to be there--young adults are free to live like non-Amish for a few years during a period they call Rumspringa before they freely choose to be Amish.

Amish solar paneling--look carefully

For us non-Amish, it is very difficult to make choices about technology for society at large, since it is not clear what criteria we all share. Even individually, it is hard to resist the push of smartphones, automobiles, or running shoes.

Even if we agree on what we want from technology (a pretty big 'if' in today's political climate), it's very hard to know what a technology really is until is has gained widespread adoption. Edison only considered the phonograph as a vehicle for music as an afterthought. Ford couldn't have imagined the drive-through's, cruisin' music, or urban sprawl made possible by automobiles. These 'second-order' effects happen because technologies are constantly being adapted for new uses and being combined with other technologies. For this reason, it's impossible to decide that a technology is bad a priori.

Based on the principles of Amish experimentation, Kelly suggests that we adopt the following goals:

• Anticipation
• Continual assessment
• Prioritization of risks, including natural ones
• Rapid correction of harm
• Redirection, not prohibition

These are still a tall order, but they're more reasonable than trying to achieve Amish-like levels of consensus. The principles are the same: open discussion, experimentation, observation, and risk-assessment.  Let's try it out and then talk about it.