If you know anything about functional programming, that statement should be no surprise to you; you’ve probably had much the same experience yourself. Even if you don’t know much about functional programming, if you stop and think about how you’ve learned the things you do know, it shouldn’t be surprising. Are you big on automated testing? Why? Isn’t it because there was a time when it reshaped your world, and even though your view has become more nuanced since then, you’ve never lost a part of that initial amazement? Or maybe object-oriented is your shtick; it was mine for a while, and still can be, if you put me in the right language on the right project. Isn’t it true that you can program with object-oriented because object-oriented reprogrammed you?
I posit: the good stuff in software always changes the way you think. That’s why we enjoy it, isn’t it? Besides, you have to shape your mind before you can start shaping software. Michael Feathers has an article, nicely summarized and consummated by his final statement, that has made a deep impression on me:
Quality is a function of thought and reflection – precise thought and reflection. That’s the magic. Techniques which reinforce that discipline invariably increase quality.
Sometimes even the best of us shy away from the pain of intense thinking. It makes our brains hurt, even the smartest among us. But isn’t it also the thing that we love about software? Thinking. And I don’t mean merely academics, but rather applying ourselves diligently to whatever problem it is that we are trying to solve.
That’s what sets the good kind of lazy programmer apart from the bad kind of lazy programmer. All programmers are lazy, but the truly lazy programmers—in the pejorative sense—are the ones trying their best not to think and thereby offloading all the complexity they should be grappling with themselves onto business analysts, testers and users. Good-lazy programmers are the ones who try to automate the things that are not worth spending mental energy on so that they can free up mental bandwidth for the things that are worthwhile.
Software is not an ivory-tower discipline, but it is as mind-on of a craft as woodworking is hands-on. It thrives on anything that promotes thinking; the act of continuously thinking about your problem is far more important than whether any particular idea you have about it is particularly good or useful. Thinking is an inherently productive activity; if you aren’t thinking new thoughts, or at least renewed thoughts, you aren’t thinking much. So in software, we should strive to think new thoughts.
Functional programming has helped me to think radically new thoughts. There are many good arguments out there trying to convince you to use Haskell, F#, Elixir, Clojure or whichever language. But it should only take one argument to at least get you to try some functional programming: you will be forced to think radically new thoughts.