Courtesy of KotlinLang.org

In the previous article, I gave an overview of the declarative (remembering facts) and procedural (drilled) memory. In this article I’d like to apply some of that knowledge. This is with a view to learning Kotlin more effectively. If we can link the declarative (I recognise I need to) to the procedural (I can do this without thinking) then we’re in a good place. After all, it’s no good having all the tools in the box, if you don’t know when to use them.

Picture courtesy of www.vanderbilt.edu

TLDR; – set some goals up to go alongside your training materials. As you do each ‘drill‘, question where it belongs in relation to your overall goals. Review that periodically so that you can link the “I should do this” to the “this is how I did this” in your head.

We’ll start with the ‘search for meaning’.

Search for meaning

I’ve written about the excellent ‘Make it Stick‘ and in that book, there was a concept of ‘searching for meaning’. The idea here is that we find the overarching concepts as a kind of ‘primer’ for our learning. Otherwise we might risk focusing on trivia and minutiae and miss the big picture.

Even that isn’t enough though, if i want to Learn Kotlin more effectively. To do that, I have to fit what I learn into the available hours I have at work, and the particular project I’m on. There could well be foundational steps along the way, but I need to keep my eyes on the prize.

Working out your motivations

Where this gets tricky is determining what ‘meaning you’re after’. Reading a book for the book’s sake is much easier – if you get the big concepts out of the book you’ve succeeded. However work life tends to be a bit more complex than that. Rarely do you have time and budget to learn a book inside out. You need to hit the ground running.

As a senior developer getting to grips with a project, my motivation is to know enough Kotlin to be able to contribute to the quality of the codebase. It’s what I’m paid to do, it’s what any annual bonus is appraised on etc.

I’ll start with my long term goal and then my more immediate ones.

Look at the specific problem you’re having

My original motivation for learning Kotlin at work was due to being pretty overwhelmed. They say the first step is admitting you have a problem, right? For context, we use Kotlin as a wrapper/configuration layer for building AWS CloudFormation templates. We also use Kotlin in place of Java in some of our applications, phasing it in gradually as part of a long-term direction.

In terms of the ‘CDK problem’ I started from my pain points and quickly moved to foundation steps.

Breaking down ‘your vague problem’

  • I’m baffled by the CDK wrapper we have at work, I dread picking up stories of that nature.
  • I don’t know enough about the CDK constructs, nor do I understand Kotlin that well so I’m being attacked on two fronts.
  • Initially at least makes sense to tackle CDK and Kotlin separately so I can at least work out which part does which. I can interleave the concepts when I have some base level of expertise.
  • It makes sense to tackle Kotlin first. Our work project uses Kotlin for more than just allowing us to assemble CloudFormation via CDK.
  • So my long term goal is to be able to build/maintain CDK constructs using this Kotlin wrapper.
  • However my more immediate goal is to get some level of mastery on Kotlin. If that becomes automatic, then I can just focus on how that integrates with CDK.

So I think doing this step will give me a better way for learning Kotlin. It’s going to focus on this more immediate goal, and therefore have a narrower scope. However unlike my longer term goal (being able to build/maintain CDK constructs) my more immediate goal doesn’t have great success criteria. So we need to nail that next.

Set your success criteria for your immediate goal

So for my more immediate goal, what do I want to be able to do? That threw for me for a bit, until I thought about my own ‘conflicts’ on the new project. Countless times I would think “why don’t we just do it in Java, I know how to do that?”

To get rid of that conflict, I would need to know:

  • How to write Kotlin “on demand” – having the right constructs on autopilot.
  • Why a piece of code was written in Kotlin over Java? What benefits did that give over Java?
  • When writing a new piece of code when would I use Kotlin over Java? Not just “we’re using Kotlin on this project”. What’s the core philosophy/advantage of Kotlin that would make it as better choice for something new?

I may not have a choice on a project in which language we use. I may not be able to influence others even if I don’t agree with the choice. But at least if I know what the intention is, I have something I can ‘pin my learning to’. With that in mind I broke my immediate goal into criteria.

CriteriaMeasure of success
Be able to write Kotlin constructs on demand.Be able to apply constructs/idioms into project with diminishing need for re-checking online. (Same as I can do in Java, from my own memory).
Be able to understand the philosophy beyond Kotlin usage over Java.For each construct/idiom, be able to evaluate its application over Java.
Be able to apply Kotlin on work projects (me).For each new price of code I write, be able to recall the Java construct it is replacing. As a senior developer, I should be able to evaluate that from memory and decided whether Kotlin was appropriate.
Be able to apply Kotlin on work projects (others).For each piece of code I review, be able to recall the Java construct it is replacing. As a senior developer, I should be able to evaluate that from memory and advise whether Kotlin was appropriate.
Table of success criteria to measure that I’m learning Kotlin effectively

Next, we’ll look at the specific drills to build the procedural memory. In this case using some excellent ‘Kotlin drills’ that JetBrains provide for us.