Learning from Other Peoples Solutions

Why reading code is a skill

Most people who practice with puzzles spend almost all their time writing. Yet reading solutions by other people is one of the fastest ways to see approaches you would not have thought of. A single clever answer can show you a technique that you then use for years.

Reading is also harder than it looks. Someone else’s program reflects their assumptions, their habits and sometimes their desire to be as short or as strange as possible. Learning to extract the idea from the code is a skill that improves with practice.

When to look

Timing matters. If you look too early, you rob yourself of the struggle that makes the answer stick. If you wait too long, you may waste hours on a dead end.

A reasonable routine:

1. Make a real attempt first. Spend enough time that you understand the problem and have a few failed ideas of your own.
2. Solve it, if you can, even badly. A working but clumsy solution gives you something to compare against.
3. Then read. Seeing a different approach after you have wrestled with the problem makes the differences stand out.
4. If you are truly stuck, take a hint, not the whole answer. Look for a description of the idea before you look at code.

How long to struggle depends on the person and the puzzle. There is no single right amount.

How to read a solution

Do not just skim for the part that works. Try these steps:

• State the idea in one sentence. Before examining the details, ask what the program is fundamentally doing. “It keeps a running total on the stack” or “it walks along the wall until it reaches a gap” are the kind of summaries you want.
• Trace a tiny input by hand. Choose the smallest input that exercises the logic and follow the program step by step, writing down the state at each point. For grid programs, this is the exercise described in tracing by hand: keep track of the pointer position, direction and stack contents.
• Find where each part of the problem is handled. Locate the loop, the decision, the output. Naming the parts makes unfamiliar code navigable.
• Note anything surprising. If you would not have written it that way, ask why they did. There is usually a reason: a size limit, a quirk of the language, or a trick.

If the code is compact or deliberately tricky, the techniques for reading dense programs are similar to those for obfuscated code: take it apart one region at a time and label what each does.

Questions worth asking

For every solution you study, a few questions tend to be productive:

• What data representation did the author choose, and why does it suit the problem?
• Where is the key insight? Could the solution be written without it?
• What assumptions does it make about the input? What would break it?
• How does it handle edge cases such as empty or minimal input?
• Is it written for clarity, for brevity, or for speed? How would it change if the goal were different?
• Which language features is it relying on? Would the same idea work in another language?

Comparing two solutions to the same puzzle is especially instructive. Ask what each does better and what each costs.

Take something away

The point of reading is not to collect answers but to add techniques to your toolbox. After studying a solution, try to:

• Rewrite it from memory. Close the file and recreate the idea. Where you get stuck shows what you did not really understand.
• Rewrite it differently. Change the representation, or solve it with a different structure. Doing so tests whether you grasped the principle or only the surface.
• Apply the idea to a new problem. Look for another puzzle where the same trick helps.
• Write a note. One or two sentences describing the technique, in your own words, are worth more than the pasted code.

Be honest about the difference between understanding and recognition. It is easy to follow code and feel that you could have written it, but writing it from a blank page is a different test.

Common pitfalls

• Copying without understanding. A pasted solution teaches little, and in a contest it may be against the rules. Always follow the norms of the place where you found the puzzle.
• Assuming shorter means better. Compact answers can be admirable, but they may sacrifice clarity. In practice, readability matters, which is why code layout is worth thinking about even in a hobby language.
• Trusting without testing. Solutions posted online may contain bugs or work only for some inputs. Run them against your own test cases.
• Comparing yourself unfairly. Seeing an expert’s elegant answer can be discouraging. Remember that it may be the result of years of practice, or of many drafts you cannot see.

Reading across languages

You can learn from solutions written in languages you do not use. The structure of the idea often survives translation. A solution to a counting puzzle in a tape language and one in a grid language may both use a countdown program shape, with a counter reduced step by step until it reaches zero. Seeing the same idea in several forms strengthens your sense of what is essential and what is incidental.

Reading in odd languages can feel intimidating at first, because the notation is unfamiliar. Start with short programs and read them slowly. Over time the symbols become as natural to you as keywords in more common languages, and the ideas behind them become easier to borrow.