In Practices of an Agile Developer, Andy Hunt and Venkat Subramaniam outline a huge list of ways to improve yourself as a software developer. While I found almost every tip in the book to be useful, I found one tip to stand out from the rest, considering it pointed out one of my particularly bad habits: “Write clear code, not clever code”.
One of my passions as a programmer is figuring out new and better ways to do the same thing. I love refactoring code and finding out what was being done in 10 lines, I could do in 3. Or as a better measure, doing something with one if else block instead of a triply nested if else statement. Usually this works out great. The code is simpler to maintain, and less complex for all involved.
However, in my endless pursuit of smaller, clearer code, I would often end up with smaller, more confusing code. In 2009, as a member of a 7 person agile team, it was very easy to measure how I was doing in this category: How often did another team member ask me what a piece of code did? Once I began looking at these problematic blocks of code, I noticed a pattern, and began to work on resolving the problem. It doesn’t matter what my particular problem was… what mattered was that I began looking for it!
Pay attention to your team members. Look into why they’re asking you about your code. Maybe there is something you do that makes perfect sense to you, but could be written clearer. Consider the next person who’s going to be looking at your code. Chances are, they’ll be happier looking at clearer code, not clever code. You’ll be happier too.
Top comments (0)