Archive
Habitforge
 Well, it’s almost February so the New Year’s Resolution rush has probably gone by. If you’re anything like me, there are a lot of things you would like to do, habits to get into, but that you can’t really find the time or energy to keep them up. I stumbled upon a website that promises to help you meet and sustain your goals – habitforge.com. The premise of the site is simple: it takes 21 days to make a habit stick (despite that often-quoted number, the science might not be there to back it up). Regardless, you enter in your goal and the site e-mails you each day to determine whether or not you met your goal during the past day. It keeps a counter of the number of consecutive ‘yes’ days, as well as statistics on your overall success, failure, and non-response rates. If you miss a day, the counter goes back to zero. I like the site for two main reasons. The first is that it has a pull rather than a push mechanism for receiving your responses. I don’t have to remember to log into the site and enter my information (push); as long as I check my e-mail daily, it actively solicits a yes or no response taking no more than one click.    Â
Â
  The second reason I like the site is that it actually seems to be working – it’s fun to see the dots of progress for consecutive completed days fill up, and it’s very painful to see them reset back to zero if you miss a day. I certainly have been writing a lot more than I would have otherwise had it not been for the reminders of the site.  The site’s not perfect; right now there is no way to indicate that a goal only applies to specific days of the week (e.g. goals that are related to work habits probably don’t mean much on weekends), but the site promises that feature is coming. My second complaint is that if you forget to respond to the e-mail, it counts that as a no-response and resets the timers back to zero. Fortunately, there is a way to go back and edit past responses to fill in the missed e-mail solicitation; this puts the counters back to their rightful place. Until I found that option, I was a bit pissed at that idea; to me a lack of a data point should not be equivalent with a no or yes answer; it should keep the counter at what it is and just update the yes, no, no-response rate statistics. Â
The idea of doing a task on consecutive days to improve at it and make it a habit is not a new thing; Jerry Seinfeld credits a similar system with helping him be so prolific and productive, though the method is a bit lower tech. I personally really enjoy this service, and hope it can be of some use to you too.
  Â
This is perhaps the most superfluous hand-rail I’ve ever seen.
Review: The Passionate Programmer
The Passionate Programmer: Creating a Remarkable Career in Software Development
by Chad Fowler
Publisher: The Pragmatic Bookshelf
I received a gift card to Border’s for Christmas and was perusing their voluminous computer section when I saw Chad Fowler’s The Passionate Programmer: Creating a Remarkable Career in Software Development. The cover of the book features a stylized rendition of a saxophone and immediately drew my attention. The fact that it was part of the Pragmatic series helped as well; I already have purchased The Pragmatic Programmer: From Journey To Master and Textmate: Power Editing for the Mac and thoroughly enjoyed both of them.
The saxophone on the cover is a reference to the fact that the author was a professional jazz saxophonist before becoming a software developer; this drastic switch in careers leads to some new insights I had never fully considered before. Before getting to an example of that, I’d like to talk a little about the structure.
This book is actually the second edition of what was originally called “My Job Went to India: 52 Ways to Save Your Job”, and it keeps the same format as the original: each chapter is numbered and presents a single focused idea for differentiating yourself as a software developer and to have a successful career. The book is divided into five large sections:
- Choosing Your Market (deciding what technologies you should specialize in)
- Investing in Your Product (how to gain real expertise with your technology of choice)
- Executing (combatting apathy, productivity ideas)
- Marketing… Not Just for Suits (hits on the fact that you can be the best coder in the world but if no one but you knows it, you’re not doing yourself any favors)
- Maintaining Your Edge (don’t get complacent; technology is incredibly fast-paced and you must keep up to date if you wish to remain relevant)
While a lot of the advice is similar to what you can find online for free, they are stated in ways I have never read before and truly made me think. For instance, the chapter “Practice, Practice, Practice” draws on his experience as a jazz musician. Here is a choice excerpt:
When you practice music, it shouldn’t sound good. If you always sound good during practice sessions, it means you’re not stretching your limits. That’s what practice is for…
Our industry tends to practice on the job. Can you imagine a professional musician getting onstage and replicating the gibberish from my university’s practice rooms? It wouldn’t be tolerated. Musicians are paid to perform in public—not to practice… If we’re going to try to compete based on quality, we have to stop treating our jobs as a practice session. We have to invest the time in our craft.
With that interesting lead in, he suggests some ways to meaningfully practice software development, while maintaining the metaphor of musicianship:
- Learn the core APIs and function libraries of your language of choice (roughly equivalent to gaining muscle memory with scales etc.)
- Code for an open source project, as well as reading the same (~ sight reading practice)
- Practice programming with self-imposed constraints, e.g. finding some problem like 99 Bottles of Beer on the Wall and implementing it in as few lines of code and as quickly as possible in your given language (~ improvisation)
This book was a very entertaining, useful, knowledge-rich book, and has my highest recommendation.
You know you’ve been coding too much when your first thought is “Java”