For this week's installment, I'd like to cover a more abstract topic than last time:

Develop a Philosophy of Programming

By this grandiose title I don't mean that your outlook on programming has to be an answer to life, the universe, and everything (though tell me if it is), but more that it's useful to know why you do what you do. Why are you a programmer? I'm assuming it's not because of a particular love for "delivering" "enterprise" "workflow" "solutions".

In my case, it's because I find the act of programming to immensely joyful (even when it's a pain). The best times are when I'm working on something and my brain is just saying "This is awesome" - whether the actual end product remains awesome is largely immaterial; it's more the act of creating it. Good thing, too, since another part of the joy is figuring out why the stuff I did before is awful in light of a new idea I've had.

The most influential thing I've read on the notion of programmer identity is Paul Graham's Hackers and Painters. His numerous other essays are also generally worth a read, but that one has stuck with me. The crucial aspect is that he aligns programmers' personalities with those of artists (over-reduced to "painters") rather than the scientists and mathematicians that Computer Science grew up with. Over the years, I've spent a lot of time thinking about where programming fits in the pantheon of professions, and I think the essay is mostly right. Certainly, programmers share a lot of traits with mathematicians (pedantry, for one), but otherwise the math/science basis of programming is something of an implementation detail. The real beating heart of programming is the joy of creating - or even just the joy of tinkering and trying, of discovering the contours of the medium.

Deciding on your philosophy of programming, whether it matches mine or takes a different path, isn't something that directly assists your day-to-day work, but I think it informs the whole. Having this sense of identity gives me a solid feeling of why I'm doing what I'm doing and an intrinsic motivation to do it properly. It helps push me to elevate my code past "the first thing that works" and into an intentionally-crafted product. Far from being a flighty academic exercise, thinking this sort of thing through has bolstered my consistent drive to improve.