Kotlin: It’s the little things

Kotlin has a bunch of amazing features, and certain ones tend to grab the headlines — things like extension functions, higher order functions, and null safety among them. And rightfully so — those are all incredibly powerful, fundamental features of the language upon which everything else builds on.

And while I love those features, there are a handful of small things you don’t hear much about that I really appreciate on a day-to-day basis.

These are simple, small niceties — the little things you do hundreds of times a day but nothing you’d consider “advanced”. They’re common sense language features that, when compared to Java, end up saving you a bunch of cognitive overhead, keystrokes, and time.

Take this simple, albeit highly contrived, example:

// Java
1 | View view = getLayoutInflater().inflate(layoutResource, group);
2 | view.setVisibility(View.GONE)
3 | System.out.println(“View " + view + " has visibility " + view.getVisibility() + ".");

// Kotlin
1 | val view = layoutInflater.inflate(layoutResource, group)
2 | view.visibility = View.GONE
3 | println(“View $view has visibility ${view.visibility}.")

At first glance the Kotlin version may look similar, as the differences are subtle. But there’s some great stuff to unpack that’ll make your life much better in the long run.

Given that example, let’s take a look at five things from Java that you’ll never need to do in Kotlin.

(Note: For clarity in the code snippets, Java is always shown first and Kotlin second. Contextual code is truncated and the diffs are bolded.)

1. Declare variable types

View view
val view

Instead of explicitly declaring a variable type (in this case a View) Kotlin simply infers it from whatever is assigned to it. You just write val or var, assign it, and get on with your day. One less thing to think about.

2. Concatenate Strings into an unreadable mess

“View " + view + " has visibility " + view.getVisibility() + "."
“View $view has visibility ${view.visibility}."

Kotlin provides String interpolation. It’s such a stupid simple feature to have that makes working with Strings much easier and more readable. It’s particularly useful for logging.

3. Call getters/setters

view.visibility = View.GONE

Kotlin provides accessors for existing Java getters and setters so that they can be used just like properties. The resulting conciseness (fewer parenthesis and get / set prefixes) improves readability considerably.

(Occasionally the Kotlin compiler can’t reconcile the getters/setters for a class and this won’t work, but that’s relatively rare.)

4. Call painfully long boilerplate methods


Kotlin provides you with concise convenience methods that wrap many painfully long Java calls. println is the most basic (though admittedly not the most practical) example, but Kotlin’s standard library has a boatload of useful tools that cut down on Java’s inherent verbosity.

5. Write semicolons


Need I say more?

🏅Honorable mention: Not shown, but you never have to write the new keyword ever again either!

Look, I know these aren’t mind-blowing features. But these little things, in aggregate over many months and tens of thousands of lines of code, can make a big difference in your work. It really is one of those things you have to experience to appreciate.

Put all these little things together with Kotlin’s headline features and you’re in for a real treat. 🍩

If this article was helpful to you, please do hit the 💚 button below. Thanks!

We’re hard at work making the Basecamp 3 Android app better every day (in Kotlin, of course). Please check it out!

Everything is possible but nothing is free

Every developer has been asked whether building a certain feature is “possible”. The short answer is virtually always YES. It’s possible. Software is the clay of dreams; everything is possible.

What those asking really want to know, though, is one of two things:

  1. Can you just build this thing I want, in addition to all the other things already on your plate, without moving any of your estimates? In other words, can you invent additional time or work hero hours to make this happen? The short answer to that question is always no. No, developers cannot bend time, invent time, or be long-term productive by sacrificing their downtime for your special-request time.
  2. Is this “easy” to do? And by “easy”, let’s take the vaguest, most fuzzy definition of the word that the two of you will never agree upon. This is like two kids arguing which car is faster: the red one or the yellow one? Without further information, you’re not going to make much progress on either question.

Here’s a simpler approach: I would like to have this and I’m willing to pay up to that.

That’s a basis for a conversation worth having. It’s rarely enough for a developer to give you a definitive answer on the spot, but after a couple of follow-up questions, you’re at least likely to know whether you’re in the ballpark.

The catch with framing the request like that is it requires the person asking to make the hard analysis. How much is my request really worth? What other things would I give up to have this thing instead? It forces them to bargain with reality, which is much less appealing than charming the developer fairy into just giving them want they want, no sacrifices needed.

And many developers are surprisingly willing to play their part in this fantasy, because who doesn’t want to be thought of as superhero with magical powers? It’s an addictive role, but also a broken one. You only get so many magic spells before your book is done.

Successfully and sustainably making progress on software together is based on an open dialogue about costs and trade-offs. The more we obfuscate those critical decisions, the less likely we are to get what we all really want: The best software for the time and money we have.

Basecamp was built by hunting for bargains under a set-the-budget type negotiation tactic as described above. Well, mostly. We still succumb to wishful thinking every now and then too, but when we catch it in the act, we try to whack it. Let me know how you think we did.