Ask HN: What are things a programmer should do at least once?

Write a compiler. It gives you great insights into parsing/tokenizing, building syntax trees, implementing syntax and Symantec checks and code generation. Obviously, you would have to pick a toy language (typically a subset of a known programming language) and your generated code will be inefficient. Still, you would learn a lot.

Here's a list (I've thought about this often):

1. Use your application. (Not the same as testing.)

2. Adopt an apprentice programmer, teach them your seat, pass on the seat. Leave the seat.

3. Program something for fun that is your own idea.

4. Program something for someone else that is their idea.

5. Sort the books/library.

6. No books/library? Build books/library.

7. Re-write the code from scratch, for the hell of it.

8. Take over someone elses' project, finish it to the end users satisfaction.

9. Give your project to someone else, in a state that they can do #8 easily.

10. Build a list of positive observations over a period of X, where X is how long you think it might be fun to do so.

The accomplishment of a number of these actions have, in my opinion, resulted in some really great programmers and some really great software.

The old chestnut, but valid: Learn, and get comfortable in, a functional language. The typical case being Lisp (often in conjunction with a readthrough of SICP), but if you have the stomach for it, Haskell (or languages of its lineage- ML, perhaps OCaml or Scala) offers the same functional "enlightenment", and the mysteries of strong type systems besides.

Parse natural language (e.g. English) toward understanding it and responding. You will learn a great deal about ambiguity, the tradeoff between elegance/verbosity and the basics of information (sufficiency, necessity, ambiguity and excess). You'll also better appreciate the language itself, its basic patterns and the value and limits of grammar.

This will reveal the inevitability of verbal interfaces in computing devices (esp. mobile) and the difficulties therein.

It's then worth extending the effort another step, to introduce yourself to the statistical and numerical techniques used by natural language processing pros to keep up with the explosion in language in modern media: personal, social, and mass.

Read "Database Design for Mere Mortals".

Its one of the few books I keep buying and giving away.

Write a program with another peogrammer. Do it as many times as possible with as many people. Software is built in the mind. Understand other minds and you will understand software better.

Manage a team.

Wasn't my cup of tea but at least I know what it is like on the dark side.

Only danger is after doing it for a year it was harder to ace the technical questions at interviews.

Go to college parties.

Rewrite the same program at least five times, trying each time to improve it. You can use different languages.

Supporting and extending other peoples code, however old the code is. Greenfield projects with new libraries and frameworks get all the limelight, yet you will learn a lot more by developing and supporting existing software in an organisation.

Ask why and understand the reasons for a feature so well that when you explain it back to the business user requesting it, they nod, say "exactly" and their eyes sparkle.

Then change how the feature works, or eliminate it, or address the business reasons using a completely different implementation and sell it to the same person in a way that has them enthusiastically agree and sign off on it.