Articles Feed

A Software Craftsman's New Year's Resolutions

by: colin | December 30th, 2009 | 1 comments »

There is so much to learn in this field, and the many new languages, frameworks, and APIs that are developed every day only add to our task. Sorry for the title-bait, but no self-respecting iterative-developing programmer would make resolutions for an entire year of learning. I expect to re-evaluate every few months, but making a long list of goals is a fun way to brainstorm paths to improvement.

Let me first take a moment to reflect on the past year. I've learned so much in 2009, beginning with my discovery of the Software Craftsmanship movement and its focus on apprenticeship. I leapt at the opportunity to come to 8th Light as an apprentice under Micah Martin, and was excited to come onboard long-term at the conclusion of my formal apprenticeship. It's important to remember that only a year ago, I wasn't doing TDD or Agile and hadn't really used any other technologies professionally beyond the Rails ecosystem. This year, I've done quite a bit of Java and JRuby, and I've studied Scheme through SICP, as well as some Clojure (mostly exercise-type practice) and Scala (just enough to write a Tic-Tac-Toe program). My progress speaks both to the time and effort I invested in learning (see Uncle Bob's tweet about professionalism) and to the tremendously positive peer pressure that surrounds me here in the Chicago area, the Software Craftsmanship community, and 8th Light specifically.

However, a software developer can't be caught looking backwards for very long. With that in mind, I present my goals for 2010.

---

1. Check email and Twitter less frequently.

Like many other developers (and musicians), I have a bit of an obsessive personality, so I end up interrupting my work and personal life to get my news fix much more often than necessary. Besides, it's going to be illegal to text, email, or tweet while driving in Illinois beginning January 1, so it's absolutely necessary (not that it was safe while driving before).

2. Take more breaks when coding alone.

When programming without a pair, I tend to stay very close to the code and neglect the big picture. With some open-source work over a recent vacation, I found myself coming to an impass nearly every evening, and invariably I'd have a simple solution the following morning. It's less necessary with a pair (like Doug Bradbury) who's able to step back and evaluate bigger-picture ideas, but our minds don't have infinite endurance, even with the labor split up.

3. Timebox spike code.

I'm improving my test-driven development habits, but there are so many unfamiliar areas to me as a programmer that I have a hard time telling whether I'm going in the correct direction until I'm there. I don't write tests for most spikes, so this means that I sometimes end up with a couple hundred lines of working code that I need to retrofit tests onto. Obviously, this ends up being more work than it should, and while I can refactor to make the code more easily testable (especially with automated refactoring tools), I'd prefer to have tests in the first place. And in the worst cases, I might miss some tests that need to be written and allow bugs that should have been caught. So my intention is to put a cap on the amount of time I spend on a spike before I backtrack and start writing tests. Something like 30 minutes seems reasonable. Besides, most of the spike code I write is alone, so I should be taking more breaks anyway.

4. Focus language study.

There's something to be said for the tremendous breadth in the languages I studied this year (Java, Ruby, Scheme, Clojure, Scala, and C), but I don't want to be a jack of all trades, master of none. It's time to get serious and get some real depth. Since my current project is mostly in Java and JRuby, it seems logical to get really in-depth with those two languages. My study at home would be reinforced by what I do daily at work, and vice versa. On the other hand, it also seems smart to go after an up-and-coming language and get ahead of the curve there. So I won't rule out more Clojure or Scala study, but it's my intention to pick one at most.

5. Focus open-source efforts.

I tend to leap around open-source projects a bit, looking into a few projects just enough to catch some low-hanging fruit from the bug or feature lists. I'd like to get more depth on a project or two, ideally in the same languages I'm planning to study more of: Java and Ruby. Limelight is the no-brainer choice, and I've already started a bit of work there. The best news is that I already know Micah, the creator/maintainer, and he's very willing to help me learn and contribute to the project. I highly recommend the project, as well as Nokogiri (the Java branch would be exciting to get working) and JRuby, for anyone with Java and Ruby skills looking for a project.

6. Really learn testing frameworks well.

It's not very often that I run into a testing problem that's limited by my lack of knowledge of the testing framework, but it sure is embarrassing when that does happen. The acceptance tests for my project are in Fitnesse, and the unit tests are in RSpec and JUnit. Following my current rationale, I should get really good at those. I have the longest to go in Fitnesse, where I still feel like a beginner, so I plan to start there.

7. Schedule study / practice.

My evenings often end up being extended mashups of coding, reading, and television. It's nice to have a relaxed feel about practice, but too often, it means less quality time with my wife and dogs. I'd like to schedule my study, both to increase the quality of my work during that time and to increase the amount of quality family time.

---

I'm sure the ways to achieve these will vary, but I think they're specific enough to drive my growth as a developer. I'm excited about continuing the improvements of the past year in 2010, and I hope that by focusing on these "resolutions", I'll even accelerate things a bit. I'd love to hear other ideas people have for improving their skills in the coming year!

#