The language doesn’t matter

I’ve always been pessimistic about introducing more programming languages on the JVM. I’ve seen a few cautionary examples that stopped a company from growing or led to a rewrite in the language it already used as its lingua franca. I sympathize with curious developers who want to play around, especially when a language is riding a wave of enthusiasm. I can also understand, a little less readily, wanting to polish a résumé. The usual arguments go something like this.

• I need this bit of syntactic sugar or I’ll wear my fingers raw. Or, in language X this would be shorter.
• We have microservices, and they’re meant to let us try different languages. What if one of them solves problem Y better?
• Language Z lets me rewrite these three lines as one.

All these arguments have some merit, but there’s a catch. The issue is that the code is lousy. Writing more efficiently or squeezing three lines into one won’t solve that. Whether you use Ruby, Go, Lua, Scala or Clojure is irrelevant. What matters is producing well-designed object-oriented code that’s easy to test, costs nothing to maintain and can be extended. Programming is a plain old discipline. It may look less exciting on a résumé than a new technology, but it matters much more. Anyone can appreciate it as soon as they see your first commit.

Like swimming, it’s a discipline you can learn by repetition and by learning from your own mistakes or others’. Plenty of exercises and tools help. A few are pair programming, coding katas, refactoring, TDD, and sitting down with examples of good and bad design. One important thing programmers should learn is to rein in their egos. I am not my code, and my code is not me.

Dominik Moštěk spoke about accidental vs. essential complexity in a CZJUG talk and showed the explosion of methods in one of our repository interfaces. The cobbler’s children go barefoot. We run events like Coderetreat, but at Zonky we don’t have a plan for learning clean code together. Long ago at GoodData we ran a code kata, but in the usual GoodData fashion we argued right away over whether to use Perl, Erlang, JavaScript or Java. Fifteen keen people became ten, seven, five, three, then just the organizer…

Dominik has several very good ideas for making clean code and TDD part of how we work. Here are a few.

• Extract parts of the code into open-source libraries. That forces us to think harder about their design.
• Pair programming.
• Gamification, like the bug fixing days we run. There’s a prize for the winner, of course. Give points for refactoring that improves the code.

What about you? How do you tackle clean code?