Be a Better Programmer, Part 2
Thu May 22 12:38:32 EDT 2014
- Be a Better Programmer, Part 1
- Be a Better Programmer, Part 2
- Be a Better Programmer, Part 3
- Be a Better Programmer, Part 4
- Be a Better Programmer, Part 5
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.
Brad Balassaitis - Sat May 24 21:31:48 EDT 2014
Very interesting concept. I naturally tend to think of myself as about the polar opposite of an artist. However, I believe that what we do requires a large amount of "logical creativity." There is absolutely an art to designing and implementing software, the level of which varies significantly based on the restrictions involved (requirements, time, experience, tools available, etc).
David Navarre - Thu Aug 14 11:30:51 EDT 2014
Paul Graham's piece is great. Thanks for linking to it. I found myself nodding and thinking, "Oh I should quote that art"
I remember you saying at
LotusphereConnectConnectED early this year how you hated reading someone else's code. Sometimes, the someone else whose code structure I find appalling is me three years ago. So, I have that 'striving to perfect' code tendency as well.Jesse Gallagher - Thu Aug 14 11:34:04 EDT 2014
Oh, absolutely. In many cases, looking at my code from years (or months, or sometimes days) ago is the most painful at all, since I can remember thinking I was being so clever, but in retrospect see just how many fundamental concepts I was missing. And then I go and write code that I will presumably detest next year. If that STOPS happening, then it's time to worry.