Putting Down the Golden Hammer: Part I, Whose Hammer Is This?
This blog is one of a series that is part-transcription, part-extension, and part-continuation of the talk that I first gave at KotlinConf 2019 called "Putting Down the Golden Hammer."
Photo by Jozsef Hocza on Unsplash. No, this particular hammer is not gold.
The Golden Hammer?
The Golden Hammer, a.k.a
Law of the Instrument, a.k.a.
Maslow's Hammer is "a cognitive bias that involves an over-reliance on a familiar tool." (Wikipedia)
You might be familiar with it phrased by Abraham Maslow in this way (hence the name "Maslow's Hammer"):
I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.
In Search of Idiomatic
After three years of developing with Kotlin, I know a couple of things for sure. That I still love Kotlin and that I am still figuring out what idiomatic and "good" Kotlin is.
Looking for an answer to "what is idiomatic Kotlin?" I first tried to learn as much as I could about as many Kotlin features as I could. I wrote a talk called "Dissecting the stdlib," where I (super quickly) went through many of the Kotlin features and stdlib tools that I loved. Moreover, these were features that felt pretty Kotlin-y to me.
Learning syntax and getting exposure to features is always a great place to start. In my effort to be Kotlin-y and idiomatic by using as much Kotlin as I could, I sometimes wrote code that made me mentally jump through hoops. I sometimes wrote code that I didn't understand six months later, either in a literal "what am I doing here?" way but also in an "I don't know/remember why I did things this way." way. I often fell in love with Kotlin's features and became biased towards using them to the point of overusing them because I had a hammer, and I was going to use it on all my Kotlin nails.
It happens to developers a lot, right? We learn a new thing. We develop with that new thing. We make mistakes or not-great decisions with that new thing. We learn how to use that new thing in a better way.
In following up "Dissecting the stdlib" and wanting to write better code, I tried to step back and answer "what is idiomatic Kotlin?" in a different way.
From a More Pragmatic Perspective
"What is idiomatic Kotlin?" Well, if anyone knows the answer to that, it's probably the Kotlin team.
I often think about Andrey Breslav's KotlinConf 2018 keynote. He talked a bit about the goals of the Kotlin team to create a "pragmatic language" for getting things done and allowing devs to turn their "thoughts into working software without any hoops to jump through."
The bit of Andrey's keynote that blew my mind was a small section where he expanded on the idea of pragmatism in Kotlin. In particular, Andrey talked about lauded qualities of Kotlin that are not that vital from a pragmatic perspective. For each, Andrey offered an actual value of the team instead.
- Readability > Concision
- Reuse > Expressiveness
- Interoperability > Originality
- Safety/Tooling > Soundness
I wholeheartedly recommend that you watch Andrey's keynote if you haven't already. But for now, I'll offer a poor paraphrase of each.
Readability > Concision
Concise code is not necessarily better code. Boilerplate is annoying and can hide problems, but concision is not a virtue in and of itself. Readability is what matters.
Reuse > Expressiveness
Rather than having a language that allows a developer to do anything, they value having abstractions that enable a developer to turn common patterns into libraries.
Interoperability > Originality
Flat out, originality is not important to the team at all. "We don't want to stand out. We actually want to blend in." Interoperability has helped with Kotlin adoption, but it also allows developers to leverage experience and tools (even those from other platforms) in Kotlin.
Safety/Tooling > Soundness
Okay, to be honest, this one is a bit too academic for me. I think we could roughly say that soundness has to do with the mathematical correctness of the compiler. And while that is nice from the academic perspective, most mainstream languages are not sound but "sound-y." Furthermore, the Kotlin Team's actual goal is safety and tooling. The compiler should catch bugs as much as it can. The type system allows for both safety and tooling to aid the developer.
So What Now?
Okay, so these are the values driving the Kotlin team. Can we re-frame how we read and write Kotlin with these values in mind to reduce our biases, reduce the number of hoops we jump through, write better Kotlin, and avoid using features like Golden Hammers?
Well, spoiler alert, the answer is "yes!"
This post is the first in a series in which I will ask:
What are some shiny/sexy/fun features of Kotlin?
(ﾉ◕ヮ◕)ﾉ*:･ﾟ✧
…that are easy to overuse?
(ﾉ・・)ﾉ▬▬▬▬█
Along the way, I will use this guide list of values and goals to evaluate some favorite Kotlin features and determine how to use them more pragmatically.
- Readability
- Reusability
- Maintainability
- Intentionality
The first two are obviously from Andrey's keynote. The last two are extrapolations, really, but I have come to highly value them as part of a medium-sized team with a sizable codebase that has some sophisticated business logic.
In the next article, I'm going to start with two basic Kotlin features that are two syntactic sugars that I first learned of and loved in Kotlin: type inference and implicit parameter names.