This is, a Q & A series by Triplebyte where we ask software professionals to go deep on a technology or work practice they use and know well.

For this edition, we spoke with Nate Ebel, Android engineer and author of the book Mastering Kotlin, about how choosing the right programming language can make a difference in your work – and your overall happiness as an engineer.

(The chat below has been edited for clarity and brevity.)

How did you get started as a programmer, and how did programming language selection play a role?

I was never going to be a software developer. I actually majored in Geography with a concentration in Geographic Informations Systems. (And during school, I worked as a GIS technician for a local city government).

But at the beginning of my undergraduate degree, I did take a single programming class. It was an intro to computer science with C++ and I hated it. I had no interest in programming again until my senior year when I had to take a GIS programming course. This course was taught not by the CS department, but by the Geography department. It used Python instead of C++ and focused on solving real-world problems. I really took to this class. In fact, I took the learnings from that class and used them to save 12 person-months of work at my GIS job. After that, I was hooked.

I decided to get a CS minor. I loved it. It was then I decided I wanted to write software instead of going into GIS.

So it sounds like that switch to Python definitely played a part in your falling in love with programming?

I think so. With Python, as I discovered, I could automate a lot of complex data processing and save months of work. Like I said, before Python, most of my development experience had been with C++ or niche languages like Lisp or Unicon, that I only used at University. Python was the first language where I truly felt productive, like I had developer super powers.

These days, I still have a soft spot in my heart for C++ even though it has never been overly useful in my career. Something about using it always made me feel extra technical, although usually less productive.

And these days you are mostly focusing on Android, particularly Kotlin – a language you like so much you wrote a book about it. How did you choose Android and Kotlin and why?

Before grad school, I bought an iOS programming book from Big Nerd Ranch and I bought Android for Dummies. I started going through both to learn mobile development. I had a chance to explore Android for my GIS job, and my Android learning quickly outpaced my iOS experience. I decided to set a six month goal of shipping an app to the app store before my grad program started.

Ultimately, I shipped the app, spent my whole grad program building robots with Android devices, and eventually got a job building GIS apps for Android, coming full circle and combining both of my skill sets.

Since I knew it was going to be all Android for me from there out, I remember getting excited in 2015 when I started hearing about this new language “Kotlin” that could be made to work for Android development and provided some cool new features like non-null types and higher-order functions. After spending a couple of sessions working through the Kotlin Koans, I was hooked. I started building side projects with the language, and I actually completed Udacity’s Android Nanodegree using Kotlin before their review system even knew what to do with the language.

The primary language for Android at that time was Java. (And even though Google has named Kotlin as the official dev language for Android, plenty of programmers still use Java today for Android.) But what were the best things about Kotlin that sold you on switching over from Java.

I certainly feel that my switch to Kotlin, across multiple projects, has been a positive investment.  I’ve seen the enforcement of type nullability lead to more thorough handling of edge cases and improved data flow throughout an application. I’ve seen complex data transformations reduced to a few, easy to read, lines of functional code. I’ve seen reductions in the total amount of code in a project after migrating to Kotlin, and less code overall to write, review, and maintain.

For a specific example, I really enjoy examples of using Kotlin’s Standard Library to chain multiple functional operations together in a single expression. Before Kotlin on Android, this type of data transformation was generally done using RxJava, which is a heavy dependency with a large learning curve. Having first-class support for this more functional approach is a huge win for Kotlin developers on Android.

I know some don’t put much weight into this argument, but I honestly think I have more fun writing Kotlin, as well. Over the years, as I’ve learned the language on my own and with teams, it’s been a really fun experience. I’ve enjoyed learning to rethink patterns, discover new patterns and conventions, and generally see a new interest and curiosity brought to the development process.

For me, it’s more fun to write code if I’m learning as I go, and learning more and more about Kotlin over the years has been a big part of that experience.

Today, my time is split between Java and Kotlin. However, the previous code bases I worked with were nearly all Kotlin. Those projects were able to move to Kotlin quickly because they were a bit smaller, and had smaller, very pro-Kotlin teams. I think it’s pretty clear today that Kotlin is the way forward for Android and any native Android project calls for Kotlin. Larger projects, or projects with large portions of legacy code, are likely going to be slower to migrate simply because there’s a higher cost. I think new development should generally be done with Kotlin though.

Nate Ebel quote.png

Like Java, does Kotlin have potential in areas outside of mobile development? What do engineers interested in applying the delights of Kotlin to their fields of, say, back-end and web need to know?

Certainly Kotlin’s biggest audience right now is among Android developers. Kotlin, though, is applicable for a variety of other development work. As a JVM language, Kotlin is a great choice for back-end developers – anywhere you’re already using Java or Scala. Frameworks such as Spring Boot or Ktor provide great support for writing server-side applications with Kotlin.  

Kotlin also has a really interesting multi-platform story. JetBrains, the team that created Kotlin, recently released JetBrains Space built entirely using Kotlin Multiplatform. With Kotlin Multiplatform, developers can write shared models and business logic using Kotlin and then consume that code across a myriad of platforms, including Android, iOS, JVM, Javascript, Mac, Linux, etc. This differs from cross-platform solutions such as React Native and Flutter in that it doesn’t try to share UI. It doesn’t promise an entirely shared codebase. Instead, it aims to reuse core logic and leave the actual applications up to native experiences. While this work is very exciting for some, including myself, it still has some rough edges. While it works great for Android and Jvm, Javascript and Native platform support is not quite as fleshed out yet. But it’s getting there. The recent Kotlin 1.4 previews are showing a lot of nice Kotlin Multiplatform improvements.

As you’ve laid out, you can inject some fun (and other improvements) into your work with a new and exciting programming language. But at work, tools and platforms choices are sometimes made on high. Have you ever been in the position of arguing that a team you’re on needs to adopt a new language? How should engineers in that position make the argument?

I advocated for our migration to Kotlin while I was at Udacity. This was before Google officially supported the language, so it wasn’t necessarily an easy argument to make. When adopting anything new – whether language, tooling, etc – I think engineers need to focus on the value it brings your team and organization. What problems will it solve? How will it improve your product or processes? How does the cost of adoption compare to the benefits gained?

Costly rewrites are absolutely a barrier to adoption of any new tooling or language. Again, we have to weigh the cost of rewrite or refactor against the perceived benefits. What are the concerns? What are the potential drawbacks or problems that might arise? How can you mitigate those and safely examine the impact to minimize risk and optimize benefit?

In my experience migrating a codebase to Kotlin, I presented my experience building a non-trivial app with the language. I demonstrated compelling language features. I demonstrated that Kotlin could be easily integrated into our existing app, and finally I made the case that we could try Kotlin in production, with minimal risk, by refactoring a single low-traffic screen in the app. As we had success with one screen, we migrated a larger module to Kotlin. And slowly over time, we migrated the majority of code to Kotlin. After each successive release, we gained more confidence in Kotlin and our ability to use the language effectively.

There is a school of thought that believes basing your engineering career around gaining expertise in one or two languages isn’t smart, with the argument being that it’s more useful to be a code-agnostic coder. You’re definitely a Kotlin whiz, so I’d love to hear where you stand on that?

I agree with that core sentiment: We shouldn’t define ourselves by a single language or tech stack. I think as engineers, we should think of ourselves as problem-solvers, as builders, and as product developers.

It’s true that learning many new languages is good for expanding our view on how to solve problems and how to think about writing code. Experience gained from one platform or language can completely change how we understand another.

All of that said, I don’t think there’s anything wrong with taking those experiences and using them to dive deep into a specific area. I 100% believe I will not be writing Android/Kotlin forever.  I would be surprised if Android, in its current form, lasts even another five years. But while it’s here, and while I still find it compelling, I fully embrace investing expertise into a small set of skills that help me build great products and solve real problems. If I wake up tomorrow and find I’m completely tired of Android, I would be perfectly happy to start investing in the next language.


Share Article

Continue Reading