Be the worst

You know you aren’t the best programmer out there. You haven’t created an open source project in your free time. You probably haven’t even contributed a patch. You don’t go to all of the hip conferences to learn about the latest “latest and greatest” technologies. You don’t give talks at the local user group, and you don’t have a widely read blog.

But you aren’t the worst programmer either. You try to do your work well and you read a few technical books a year. You attend a user group or two when it fits in your schedule. There are a few technologies that you understand fairly well, and others on your team look to you for help in your areas of relative expertise.

The problem is, you are in a rut. You aren’t gaining skills as quickly as you were last year. You aren’t exactly thrilled about your current job, but not so dissatisfied that you want to take the chance of trading your known problems for unknown problems. What to do?

Book review: Effective Java by Joshua Bloch

If you write Java as part of you job, you need to read this book. If you are learning Java, and hope to write Java as part of a future job, you need to read this book. So for many developers, the question of whether you should read this book is answered very quickly. The most important questions that remain are when to read Effective Java, and why to read Effective Java.

This is not a book to read to learn Java, Bloch assumes throughout that you have a familiarity with the language. It is also not a book to help you take the next steps after learning core Java, such as learning popular APIs such as JDBC, Java EE, or Swing. Effective Java is unlikely to equip you to accomplish any programmatic goal in Java that you were unable to code before reading it.

If you are overly pragmatic, it may seem that this book meets no real need. But if you have learned several languages, the purpose of this book, and the importance of books like this, is obvious.

Book Review: Clean Code by Robert Martin

I read Clean Code by Robert Martin (Uncle Bob), and it was well worth it. In about 400 pages, Uncle Bob gives real motivation for writing clean code, explains, in careful detail what clean code means for all of the regular parts of a typical system, and then applies the principals discussed on several substantial chunks of real-life code.

Martin begins with motivation to strive to write clean code. That may seem unnecessary, but it serves several good purposes, even for those that were willing to buy a book entitled “Clean Code.” First of all, in Martin’s engaging style , you become excited about the possibility of writing better code. More importantly, in my view, is that rather than appealing to prideful notions of craftsmanship or art, he makes it clear that clean code is about useful, maintainable, flexible software. That it is about reducing the cost of software, and preventing, reducing, and fighting the software rot and decay that often surrounds us.