First week's goals (results a month later) - Poor

Well, change isn't always easy, even if you believe in it. I'd say I did fairly poorly on my first week (now a month ago) and those since, though I was on the vacation a decent portion of the time after. Still - that's no excuse not to blog results. I currently have a more pressing side project at work, so I won't get to focus on code much in the next week or two, but I will come up with a new list of goals for next week regardless.

I was pretty faithful to the puzzler a day (as it's a fun break from the normal day), and probably did 1 puzzler a day. I can't emphasize enough how useful (and satisfying!) it is to learn the quirks of a language that you use day-to-day (in this case, Java). It's good knowledge, and 'Java Puzzlers' presents it in an entertaining fashion.

On the unit test front, I probably updated or added a unit test one day of the week, in a section of code I already had pretty good coverage with. I did not get around to writing my first Abbot test. My issue has always been writing the first test - it's easy (and enjoyable) to follow in the footsteps, once they are there, but it seems like a pretty solid trend that untested code stays as untested code - there is an initial barrier of resistance still (maybe the code is hard to test, maybe the coder is lazy, or maybe test-driven just isn't strongly enough part of the mindset to jump-start things)

On the findbugs section I'd say I failed - there's no lack of warnings to fix, but they are often in a foreign area of the codebase. I did examine our warnings reports in Hudson, but didn't fix any.
I find that sometimes I'm hesitant to perform an obvious fix in a section of the codebase most requently updated/maintained by another developer. Prior history (just google Debian SSH) dictates that sometimes applying fixes that a code metric suggests in code you aren't familiar with is a bad idea. The code I'm looking at isn't as delicate, but it still deters me somewhat. We'll see how I cope with this as I really want to better embrace Findbugs.

On the Hudson front, I frequently spend an hour or two getting everything building (especially tricky in Eclipse at times, as the heavy generics often confuse Eclipse's compiler, since it does not use javac). Afterwards, I don't know what I should work on and it is late at night. Time dicates I should probably find a bug to fix, but it's often hard to find a good starter. I think I will keep this goal of contribution, with a renewed focus or speaking with the devs that hangout in #hudson on IRC. I'll just ask if there's an area I could help with in a small way. Hudson remains the single most useful bit of Java software I've ever used - the benefit the project has given our team is tremendous.

I'll have to come up with a list of follow-up goals and any strategies for better accomplishing them