InfoQ recently sat down with Christina Lee, an Android engineer on the Core UI team at Pinterest, and discussed adoption of Kotlin at Pinterest, organizational challenges Pinterest faced during the adoption, the biggest lesson learned, helpful tips for transitioning to Kotlin from Java, and the topic of her upcoming talk, Representing State: the Kotlin Edition, at KotlinConf 2018.
InfoQ: Could you briefly introduce yourself, your role at Pinterest and specifically on championing the adoption of Kotlin?
Christina Lee: My name is Christina, and I’m an Android engineer on the Core UI team at Pinterest. I arrived at Pinterest by way of an acquisition a few years ago, and at that company, I had had the freedom to use Kotlin extensively (and exclusively!) for several years. So when I began working at Pinterest, it was natural to pivot that experience and enthusiasm into my new work.
Within a few weeks of being at Pinterest, I had asked for and been granted, permission to trial Kotlin in the feature I was working on at the time (video support for Android). This work, along with some related internal advocacy efforts, eventually led to an expansion in Kotlin usage in our Android app, which culminated this year in our new policy that Pinterest is a Kotlin-first Android environment.
InfoQ: What about the Kotlin language causes you to be such a strong and visible advocate for its adoption?
Lee: Kotlin is not a radical departure from Java, as both produce bytecode for the JVM. But what makes it so nice to work with is that it is essentially a version of Java where best programming practices have been built into the language, so it is much easier to do the right thing than it is to do the wrong thing. This allows a developer to code with speed and confidence and removes much of the rote work that had been required while using Java.
Because coding, like writing, is an expressive art form, having a tool like this that allows you to express your thoughts clearly, quickly, and accurately is a satisfying phenomenon and one worth getting excited about. When you combine this with the industry-leading tooling and interoperability of the language and the thorough and thoughtful language leadership displayed by the team at JetBrains, it was difficult not to fall in love with it.
InfoQ: What organizational challenges did Pinterest face during the adoption of Kotlin? How did Pinterest overcome these challenges?
Lee: One of the biggest challenges we faced during the adoption of Kotlin was ongoing issues with Kapt (the Kotlin annotation processor) and other build related issues. We would find ourselves with errors in our CI build environs, as well as frequent build failures when switching branches locally because build state was not getting properly cleared out. There was a point where some senior engineers were even advocating removing the language because of these problems.
Some of these difficulties were the growing pains of adopting a young language -- Kapt itself had bugs and flaws that were inherent in the tool -- and not something anyone in our org could fix. These types of issues resolved as Kapt and the associated build tools improved, but in many engineers' minds, Kotlin was associated with build instability, which colored their opinion of the language.
However, another portion of these issues was a result of the inevitable blind spots that come when working with a new technology for the first time. These were issues that we had the ability to solve internally, and we did so through a concerted focus on education. An example of this was a common issue we saw at compile time where a developer would forget an import statement or make some other error unrelated to Kotlin but would have difficulty finding this error in the build output because of the way Kapt was outputting information in Android Studio.
Teaching people where to find the real compile-time error gave them the knowledge necessary to navigate such failures on their own. To help with this class of issues, the team set up several Slack channels specifically for asking questions about Kotlin or the build and set a precedent that all questions were always welcome and would be responded to.
Teaching the team how new components such as Kapt worked, what certain types of errors signaled, and where to start looking for resolutions went a long way in easing the pain of the transition.
InfoQ: How did you convince your team to re-architect the entire Android code base to use Kotlin?
Lee: At Pinterest, our policy is actually one of being Kotlin-first, but not Kotlin-exclusive. What this means is that all Pinterest Android developers must know how to read, write, and understand Kotlin, as it is the primary language for Android development at the company and all new code must be written in it. However, we specifically made a call not to preemptively convert existing Java files that we would otherwise not have a reason to change.
The logic behind this is two-fold. The first can be summed up as "if it's not broken, don't fix it". If something is working, and you change it, you introduce the possibility that your change broke an existing behavior. Unless there is a clear ROI on converting the file to Kotlin absent any other changes (sometimes there is!), it is better to let the working component continue undisturbed until such a time as you would be introducing other changes to it and assuming that risk anyway. Second, the sheer amount of time it would take to convert every file in the Pinterest code base to Kotlin would be a very large investment.
Given all the opportunities before us, that did not seem like the most valuable way we could spend such a significant amount of developer time.
InfoQ: What was the biggest lesson Pinterest learned while adopting Kotlin?
Lee: As a person, I have the unfortunate quirk of a rebellious personality. I don’t like to be told what to do, and so I believed that when it came to deciding whether to use Kotlin or Java, every Pinterest developer should get to choose for themselves. This was entirely possible from a technical perspective due to Kotlin’s excellent Java interoperability and was a sentiment shared by others in the company as well, but what it failed to account for was human nature.
People don't like uncertainty, and when a team can be easily divided into discrete camps (Team Java, Team Kotlin) conversations about things like API design or nullability patterns can more easily turn into "us vs. them" scenarios. By allowing the language to spread organically within the company, we eventually reached a plateau, where most of the developers who were keen to try the new language had adopted it, and many of the developers who weren’t as interested had opted out.
Given enough time, the organic path might have eventually converted all developers, but the schedule of that rollout would have left the team in a split state for far too long. When our platform lead Sha Sha Chu (in concert with other engineering leads) made the decision to roll out our definitive Kotlin-first language policy, there was concern that people would be upset at having the choice removed from them. But while there was a healthy discussion around the process, after the policy rolled out, the team cohesion and happiness seemed to jump significantly.
As a result of this experience, I think one of Pinterest’s biggest lessons learned is the value of providing clear and direct guidance earlier in the exploration and roll out phase to minimize the time a team spends in a split state. As a team, I think we’ve become much more aware of the value of testing thoroughly and then committing swiftly to a single path (either total removal, or full commitment).
The other big learning was that Kotlin (especially early on) caused some instability in the builds until we allocated adequate resources to monitoring and fixing any problems that arose (specifically with CI and Kapt). None of these problems were insurmountable, but they did require some thoughtful investigation, which was a non zero time investment for an engineer. We had not allocated headcount appropriately for this in the beginning, leading to longer than desired turnaround time for early build failure investigations.
Once we assigned a dedicated resource to this area, we were able to fix the major contributors to build flakiness in a relatively quick amount of time. This initial investment of an on-call engineer paid large dividends and is something we would likely try to do earlier in a framework rollout in the future.
InfoQ: What helpful tips can you share about making the transition from Java to Kotlin?
Lee: There is so much content out there right now about getting started with Kotlin (including talks from Huyen Tue Dao and me) that almost any learning style should be able to find content that eases their transition from Java to Kotlin.
But aside from the assortment of free talks and tutorials, the IntelliJ family of IDEs are the greatest learning tool I’ve found. They provide the ability to copy and paste Java code and have it be automatically converted to Kotlin. This gives a good rough mapping of what your Java concepts might translate to in the new language, similar to how Google Translate can give rough language translations when you’re trying to learn a new language. While the editor might make some incorrect suggestions, these tend to have very helpful error messages that can easily be looked up on StackOverflow.
Additionally, code reviews are key. As in most programming languages, there are many ways to accomplish the same task in Kotlin. As people were onboarding, we had special Kotlin-specific reviewers look at the pull requests coming from people new to the language. Their role was not to judge any technical soundness of the underlying code, but rather to focus only on how the language was being used and whether it conformed to best practices and our recommended style guide.
The back and forth arising from such code reviews led to diffuse organizational learning -- the reviewee received suggestions, the reviewer was forced to think more deeply about the language as they fielded questions and made comments, and the discussions were documented and able to be read or referenced by any other team member reading the PR.
InfoQ: What is your talk about at KotinConf 2018? Why did you choose this topic?
Lee: My talk at KotlinConf this year will be about how Kotlin language features give us the ability to more easily and accurately define discrete states in an application. I feel passionate about the topic of well-defined data structures as it is an area of programming that often gets overlooked in code reviews and architecture discussions, yet is the source of innumerable unhandled issues and bugs. Similar to how it is easier to keep an already clean room clean, investing time in setting up and maintaining logical data structures at the outset of a project can make it easier for code to do the right thing as it shifts through its many phases of use, which is a velocity win for developers and a stability win for our users.
InfoQ: Thanks for taking the time to speak to us today. Is there anything else you would like to share with the InfoQ readers?
Lee: One of the most striking things to me about Kotlin is that I can’t remember being approached by a developer who had thoroughly adopted and used the language and regretted it. My experience with Swift was one where people liked the language but had ongoing regrets about making the switch because of build time, interoperability, or language version migration issues.
In my experience, the vocal criticism of Kotlin has mostly come from those who haven't begun using the language, and exceedingly rarely from those who have used it extensively. I have had people who have debated with me for months over the adoption of the language show up at my desk weeks after making the switch to tell me that Kotlin has made them love developing for Android again.
Other developers I know who were initially reluctant to adopt the language now complain when they are required to switch back to Java to maintain a legacy file. This ability to charm even the most reluctant developers is, in my opinion, a stunning testament to the language itself, the tooling around it, and the teams that are shepherding its usage.
Additional information on Kotlin at Pinterest can be found on the Pinterest Engineering Blog. Readers can also keep up to date with all Java-related news by visiting the InfoQ Java homepage.
