The second session of the first day was by Michael Feathers giving a demo of using functional approaches to different problems.

I took two main lessons out of it:
1. “Clever code” is relative.
2. Functional programming can help establish a common base of understanding that doesn’t vary from one problem domain to another.

“Clever code” is something that’s often looked down uponbecause it can make it more difficult for multiple developers to maintain an application and read its code. But what is “clever”, exactly? Michael Feathers made the point that anything that’s unfamiliar to us will at first look as strange and weird. But if we take the time to learn new functions and patterns, they will quickly become familiar and comfortable instead of too clever and complicated.

Another way to mitigate the gap between unfamiliar and comfortable is to use common functions. Functional programming is a good example of that: it is more about manipulating data without worrying about setting up abstractions to model it first. Functions built into a functional language aren’t trying to represent the domain of the problem. Instead, they simply perform common operations that do the same thing regardless of what kind of problem they’re applied to.

For example, the zip function is the same in Ruby, Python, Scala, Haskell, and other languages. This means that you can learn how it works once and if you find yourself working in another language or another domain, you can easily apply it there.

The same holds true for design patterns and, to an extent, frameworks.

Establishing a common base of understanding is important for ensuring that we write the best code possible. Sometimes this requires compromises to favour readability over efficiency or style, but other times we’re better off using some clever code on the assumption that we and our fellow developers will learn how it works and become better for it.