<div dir="ltr">
<h1 class="gmail-general">Kotlin Q&A With Christina Lee of Pinterest</h1>
<span class="gmail-author_general">
<span id="gmail-spanLikeContent" class="gmail-item-like" style="display:inline-block">
<a id="gmail-toggleLikeContent" class="gmail-button--like gmail-authModal--trigger" style="color:rgb(40,106,178)"><span class="gmail-button--like__icon"></span>Like</a>
</span>
<em>|</em>
by
<span class="gmail-authors-list">
<span class="gmail-followable">
<a class="editorlink gmail-f_taxonomyEditor" style="color:rgb(40,106,178)" href="https://www.infoq.com/profile/Kesha-Williams">Kesha Williams</a>
<span>
<span class="gmail-follow__what"></span>
<a id="gmail-User113701004" class="gmail-user-button-blue gmail-user-button-small gmail-authModal--trigger"><span class="gmail-icon-add_circle_outline"></span></a><span class="gmail-followers" style="display:inline"></span></span>
</span>
</span>
on
Oct 01, 2018. Estimated reading time:
10
minutes
<em>|</em>
<a id="gmail-noOfComments" title="" href="https://www.infoq.com/news/2018/10/kotlin-pinterest#theCommentsSection" class="gmail-comments_like">
<span class="gmail-comments_counts">
<span class="gmail-nr">
Discuss
</span>
</span>
</a></span>
<ul class="gmail-sh_t"><li class="gmail-space">Share</li><li>
<a href="https://www.addthis.com/bookmark.php?v=250&username=infoq" class="gmail-standard gmail-addthis_button" style="background:rgba(0,0,0,0) none repeat scroll 0% 0%;text-decoration:none;color:rgb(28,73,123);padding:0px 2px;float:left;font-weight:bold;font-size:85%">
<img src="https://s7.addthis.com/static/btn/sm-plus.gif" alt="Share" width="16" height="15" border="0">
</a>
</li><li>
<span class="gmail-addthis_separator">| </span>
</li><li><a class="gmail-standard gmail-addthis_button_twitter gmail-at300b" title="Twitter" href="https://www.infoq.com/news/2018/10/kotlin-pinterest#"><span class="gmail-at-icon-wrapper" style="background-color:rgb(29,161,242);line-height:16px;height:16px;width:16px"></span></a><br></li><li><a class="gmail-standard gmail-addthis_button_hackernews gmail-at300b" target="_blank" title="Hacker News" href="https://www.infoq.com/news/2018/10/kotlin-pinterest#"><span class="gmail-at-icon-wrapper" style="background-color:rgb(255,102,0);line-height:16px;height:16px;width:16px"></span></a><br></li><li><a class="gmail-standard gmail-addthis_button_reddit gmail-at300b" target="_blank" title="Reddit" href="https://www.infoq.com/news/2018/10/kotlin-pinterest#"><span class="gmail-at-icon-wrapper" style="background-color:rgb(255,87,0);line-height:16px;height:16px;width:16px"></span></a><br></li><li><a class="gmail-standard gmail-addthis_button_facebook gmail-at300b" title="Facebook" href="https://www.infoq.com/news/2018/10/kotlin-pinterest#"><span class="gmail-at-icon-wrapper" style="background-color:rgb(59,89,152);line-height:16px;height:16px;width:16px"></span></a><br></li><li><a class="gmail-standard gmail-addthis_button_email gmail-at300b" target="_blank" title="Email" href="https://www.infoq.com/news/2018/10/kotlin-pinterest#"><span class="gmail-at-icon-wrapper" style="background-color:rgb(132,132,132);line-height:16px;height:16px;width:16px"></span></a><br></li><li><br></li><li><a id="gmail-bookmarkBtn" href="http://www.infoq.com/news/2018/10/kotlin-pinterest" class="gmail-read_later" title=""><q>Read later</q></a></li><li><a class="gmail-reading_list" style="margin-right:100px" href="https://www.infoq.com/showbookmarks.action"><q>Reading List</q></a></li></ul>
<div class="gmail-article_page_left gmail-news_container gmail-text_content_container">
<div class="gmail-text_info">
<p>InfoQ recently sat down with <a href="https://www.linkedin.com/in/clehrlee/">Christina Lee</a>, an Android engineer on the Core UI team at <a href="https://www.pinterest.com/">Pinterest</a>, and discussed adoption of <a href="https://kotlinlang.org/">Kotlin</a>
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, <a href="https://kotlinconf.com/speakers/#speaker=christina-lee">Representing State: the Kotlin Edition</a>, at <a href="https://kotlinconf.com/">KotlinConf</a><a href="https://kotlinconf.com/"> 2018</a>.</p>
<p><strong>InfoQ: Could you briefly introduce yourself, your role at Pinterest and specifically on championing the adoption of Kotlin?</strong></p>
<blockquote>
<p><strong>Christina Lee:</strong> 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. </p>
</blockquote>
<p><strong>InfoQ: What about the Kotlin language causes you to be such a strong and visible advocate for its adoption?</strong></p>
<blockquote>
<p><strong>Lee: </strong>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.</p>
</blockquote>
<p><strong>InfoQ: What organizational challenges did Pinterest face
during the adoption of Kotlin? How did Pinterest overcome these
challenges?</strong></p>
<blockquote>
<p><strong>Lee: </strong> 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. </p>
<p>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. </p>
</blockquote>
<p><strong>InfoQ: How did you convince your team to re-architect the entire Android code base to use Kotlin?</strong></p>
<blockquote>
<p><strong>Lee: </strong> 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. </p>
</blockquote>
<p><strong>InfoQ: What was the biggest lesson Pinterest learned while adopting Kotlin?</strong></p>
<blockquote>
<p><strong>Lee: </strong>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.</p>
<p>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).</p>
<p>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.</p>
</blockquote>
<p><b>InfoQ: What helpful tips can you share about making the transition from Java to Kotlin?</b></p>
<blockquote>
<p><strong>Lee: </strong>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.</p>
<p>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. </p>
</blockquote>
<p><strong>InfoQ: What is your talk about at KotinConf 2018? Why did you choose this topic?</strong></p>
<blockquote>
<p><strong>Lee:</strong> 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.</p>
</blockquote>
<p><strong>InfoQ: Thanks for taking the time to speak to us today. Is there anything else you would like to share with the InfoQ readers?</strong></p>
<blockquote>
<p><strong>Lee: </strong>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.</p>
</blockquote>
<p>Additional information on Kotlin at Pinterest can be found on the Pinterest <a href="https://medium.com/@Pinterest_Engineering">Engineering Blog</a>. Readers can also keep up to date with all Java-related news by visiting the <a href="https://www.infoq.com/java">InfoQ Java homepage</a>.</p></div></div>
<br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+<br><br> Harold F. Schiffman<br><br>Professor Emeritus of <br> Dravidian Linguistics and Culture <br>Dept. of South Asia Studies <br>University of Pennsylvania<br>Philadelphia, PA 19104-6305<br><br>Phone: (215) 898-7475<br>Fax: (215) 573-2138 <br><br>Email: <a href="mailto:haroldfs@gmail.com" target="_blank">haroldfs@gmail.com</a><br><a href="http://ccat.sas.upenn.edu/~haroldfs/" target="_blank">http://ccat.sas.upenn.edu/~haroldfs/</a> <br><br>-------------------------------------------------</div></div>