I don't do New Year's resolutions. I don't believe in them 1 . Consider that people generally come up with these resolutions well before the New Year, but delay implementing them until that time. Why is that? Surely, if the resolution is a beneficial change in their lives, they would benefit most from implementing it as soon as they decided to do it. Then there's all the baggage that comes with calling it a New Year's resolution. That's just asking to fail, because nobody keeps their resolutions. In those apparent contradictions are the answer. People make New Year's resolutions for things they think they should do but don't actually want to do. Waiting till the New Year delays doing something they don't want and allows them to join a crowd of people all failing at once, reducing their guilt. It's win-win; they get the satisfaction of trying to do something positive without actually having to do it or feel bad about not doing it.

All of that is a long-winded, roundabout way of saying I have resolved to do a new thing, but this resolution is not of the New Year's kind. The main thing I took away from Paul Graham's latest essay was the idea that one should constantly be producing something. I've spent a lot of time thinking about various ideas, but little time in either following through on them or laying the groundwork for doing so at another time. I find it very easy to let a day go by without having accomplished anything productive (code-wise), and it's similarly easy to let a single wasted day become a wasted week. I won't have that luxury if I'm on my own; days and weeks like that could be fatal to an attempt to go independent. As a result, I've resolved that I must write some useful code every day. Always Be Creating 2 . It could be for my day job. It could be for some noodling around on my own. What doesn't matter so much as long as it happens.

There are several clear advantages to doing this:

1. Self discipline and good work habits.
2. Being a doer, not a dreamer. I've spent a lot of time thinking about things I could do and very little time actually following through.
3. Experience and knowledge beyond what I might get through my job. This is especially important because the languages and technologies that will be most useful for me aren't ones I use at work. For example, if I want to create a client-side application, C# looks to be the best language to use. For building many kinds of web applications, the Java that I know is useful, but I suspect a more dynamic language such as Python will be better suited for the scale of what I'm more likely to attempt.
4. Building a library of useful parts from which I could build other things. When the time comes to go off to try whatever fool idea I seize upon, I cannot allow myself to start from scratch. I need to have all my building blocks and tools ready. Otherwise, I just won't have enough time or energy. 90% of most software projects is plumbing, and most of that is the same with similar projects.

¶ 1205 Posted at 12.27 PM ⇒ No Comments ( me | longshot | software )