Technique: Personal Projects

One of the best things you can do to deepen and broaden your technical knowledge is to work on side projects, outside your day job.

A personal project is a SideProject where:

• You will frequently use the software yourself.
• You work on it alone.
• You are solely responsible for the code.
• You will maintain and improve the code over a long period of time—ideally years.
• No one else is going to see or care about how the code looks.

Personal projects give you a venue for DeliberatePractice. A personal project is an environment where it's safe to make mistakes, and you can explore and experiment freely.

The practice on its own will, of course, make you a better programmer. But I think the most important benefit of personal projects is that they free you, temporarily, from social pressure to do things the "normal" way, or to follow the "best practices" imposed by your manager or teammates at work. Only by pushing the boundaries can you discover the limits of the "best practices" you've received from others. This process of discovery will allow you to internalize the ToolsNotRules view of programming, and learn to rely upon your Judgment when making technical decisions.

For example, you might try:

• Doing TestDrivenDevelopment for an entire project
• Forgoing AutomatedTests entirely
• Writing in a FunctionalProgramming language like Clojure, F#, Haskell, or Elm.
• Writing in an ObjectOrientedProgramming language like Ruby.
• Using or eschewing StaticTyping.

Putting Yourself Under the Microscope

A personal project is like a science lab: it is a world unto itself, isolated (mostly) from external confounding factors. It is an ideal environment to study your own preferences and habits as a programmer, and to learn what you really like and dislike.

At our day jobs, it's easy to blame others for the shortcomings of the code, or for "holding us back" with silly rules and superstitions. A personal project puts that view of the world to the test.

Maintaining code that you wrote over a long period of time, where you have no one else to blame and no one to impress, really brings you face to face with your own true preferences.

By working on my own projects, I have learned:

• A lot of the time pressure I feel at work is self-imposed. It comes from my own impatience, not from my manager or coworkers.
• The code I prefer to read often looks very different from the code I think I "should" write.
• When I begin a project aiming for "the perfect design", the result feels awkward and contorted, and I start to dread working on it.

This process of self-discovery can be nerve-wracking and humbling at first. But it leads ultimately to peace. Eventually, you realize that when you are in touch with your feelings about the code, you can relax. Instead of tenaciously pursuing idealistic images of how things "should" be, you can simply fix the problems that really exist, and are really important to you, one at a time. You'll be open to many more ways of doing things, and you won't feel the need to put down anyone else's programming style, because you'll see that every technique is a good idea in its proper context.

"Personal" Projects at work

What if you don't have time outside of work to write code? You might be able to get the benefits of the Personal Projects technique at work by using a MakingApp as a testing ground for new approaches.