What should every programmer write?

make a game; you will learn a lot. even a simple 2d game like a chess simulation is a great exercise in software engineering, for several reasons.<p>- Games are a LOT of work. Most hobbyist games are never finished. Sticking with one from start to finish is a great execise in discipline and perseverance.<p>- Games of any significant level of complexity require a lot of thinking about performance. Most programmer's first game looks something like this:<p><pre><code> while not game.time_to_quit(): for each entity in game.entities: entity.update() game.render_frame() which will always pin a single CPU to full utilization. Try again! </code></pre> - Games require a wide knowledge of data structures and programming techniques, like kd-trees, pools, and (if you're really serious about performance) stuff like cache-aligned allocation and flywheels.<p>- There are always tons of cool features you can add that will stretch your coding ability to the limit. Try adding a save-game feature and watch yourself pull your hair out designing a decent data model. Add 'instant replay' abilities without destroying memory performance, and build an AI to see why functional programming rocks your socks off. Add network play and learn how to write really performant network code. Add pixel shaders and learn the basics of GPU processing and how awesome it is.<p>- Games are the type of project that is 'never done' in the sense that there is almost always some improvement left to be made.<p>- Most decently built games separate the engine from the game itself. Learning to do this properly is a great way to learn good techniques for designing good abstraction layers.<p>- Games are fucking awesome. The first time you have code moving a lolcat around on the screen, you'll shit your pants with excitement (YMMV). Part of the fun of programming is building stuff, and being able to see what you're building is very rewarding, especially if people play what you're working on and (if you're really good) they like it.

For something a little less painful than the other suggestions here, write a web server.<p>You'll learn more about HTTP, statefulness, scalability and 'how websites work' than you'll ever learn building websites.

Implement swtch() for x86 and arm (or whatever cpu you have). This is if you want to be a systems programmer, work on operating systems, file systems, etc.<p>There is something magical about calling a function as one process and returning as another.<p>I did this while still at school for Udi Manber (agrep, google search vp) because he wanted a user level threads package.<p>You can see my hacky code for the VAX (I think) at<p><a href="http://www.mcvoy.com/lm/T/src/Tasm.S" rel="nofollow">http://www.mcvoy.com/lm/T/src/Tasm.S</a><p><a href="http://www.mcvoy.com/lm/T/src/Tswitch.c" rel="nofollow">http://www.mcvoy.com/lm/T/src/Tswitch.c</a><p>it's from 1987 when I was a grad student, probably doesn't compile.

A small Lisp-1 interpreter written in Lisp or Scheme it was a rite of passage in the the old days.<p>This [1] is a naive implementation of the eval function that I wrote last summer. Maybe someone can give me some feedback on it. I am planning to work a little bit more on it this holidays.<p>[1] <a href="https://gist.github.com/493736" rel="nofollow">https://gist.github.com/493736</a>

A Scheme parser &#38; interpreter helps a lot in understanding compiling &#38; functional programming.<p>Resource: Scheme 9 from empty space: <a href="http://tx97.net/s9fes/" rel="nofollow">http://tx97.net/s9fes/</a>