[lg policy] Kotlin Q&A With Christina Lee of Pinterest

Wed Oct 3 15:45:28 UTC 2018

 Kotlin Q&A With Christina Lee of Pinterest Like *|* by Kesha Williams
<https://www.infoq.com/profile/Kesha-Williams> on Oct 01, 2018. Estimated
reading time: 10 minutes *|* Discuss
<https://www.infoq.com/news/2018/10/kotlin-pinterest#theCommentsSection>

   - Share
   - [image: Share]
   <https://www.addthis.com/bookmark.php?v=250&username=infoq>
   - |
   - <https://www.infoq.com/news/2018/10/kotlin-pinterest#>
   - <https://www.infoq.com/news/2018/10/kotlin-pinterest#>
   - <https://www.infoq.com/news/2018/10/kotlin-pinterest#>
   - <https://www.infoq.com/news/2018/10/kotlin-pinterest#>
   - <https://www.infoq.com/news/2018/10/kotlin-pinterest#>
   -
   - Read later <http://www.infoq.com/news/2018/10/kotlin-pinterest>
   - Reading List <https://www.infoq.com/showbookmarks.action>

InfoQ recently sat down with Christina Lee
<https://www.linkedin.com/in/clehrlee/>, an Android engineer on the Core UI
team at Pinterest <https://www.pinterest.com/>, and discussed adoption of
Kotlin <https://kotlinlang.org/> 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
<https://kotlinconf.com/speakers/#speaker=christina-lee>, at KotlinConf
<https://kotlinconf.com/> 2018 <https://kotlinconf.com/>.

*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 <https://medium.com/@Pinterest_Engineering>. Readers can also keep up
to date with all Java-related news by visiting the InfoQ Java homepage
<https://www.infoq.com/java>.

-- 
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

 Harold F. Schiffman

Professor Emeritus of
 Dravidian Linguistics and Culture
Dept. of South Asia Studies
University of Pennsylvania
Philadelphia, PA 19104-6305

Phone:  (215) 898-7475
Fax:  (215) 573-2138

Email:  haroldfs at gmail.com
http://ccat.sas.upenn.edu/~haroldfs/

-------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listserv.linguistlist.org/pipermail/lgpolicy-list/attachments/20181003/a380a100/attachment.htm>
-------------- next part --------------
_______________________________________________
This message came to you by way of the lgpolicy-list mailing list
lgpolicy-list at groups.sas.upenn.edu
To manage your subscription unsubscribe, or arrange digest format: https://groups.sas.upenn.edu/mailman/listinfo/lgpolicy-list