Coroutines in Kotlin are ready for prime time.

Coroutines in Kotlin were a big topic for the conference. An organizer for the Kotlin Office Hours meetup, discussed how coroutines compare with the ReactiveX patterns widely deployed. My main take-away from the two talks was that coroutines are here, and they're ready for prime-time.

The coroutine semantics remind me of the async patterns I learned using the EventMachine library for Ruby, but the Kotlin implementers have gone beyond that, taking learnings from Go, Python, C# and others, and integrating it into a coherent "structured concurrency" approach. There's a strong case to be made for coroutines, and using them would still allow us to develop readable, maintainable async code without additional dependencies like the Rx libraries. One downside I took away was that the structured concurrency approach is specifically designed to promote imperative thinking about asynchronous processes. The Rx libraries, while initially difficult to learn, almost force developers into a more functional pattern, and those patterns can lead to more testable code over time.

Technologists need to remember and stand up for their ethics.

"Ethical Product Design and You" was the first keynote of the first day, and served as a good reminder to everyone that the products we're building as technologists and mobile developers have far reaching effects in the real world, and small choices made for convenience can have dramatic second-order effects. Liz Fong-Jones, the speaker, was encouraging everyone to think about what these second-order effects might be, and encouraging us all to always put our ethics first when building these products, to prevent these bad second-order effects before they become public, or, if already released, to work quickly and empathetically to correct problematic design.

The DroidCon App.

Early in the afternoon on Tuesday, the leaders of the DroidCon app team spoke about their experience running an open source development project. The DroidCon app was written by volunteers working remotely. In fact, the organizers mentioned that they met for the first time in person at the convention! The talk was more inspirational than informational and focused on their reasons for getting involved and how the team communicated. I was sufficiently inspired by the talk to reach out to the organizers and volunteered to work on next year's DroidCon app.

Machine Learning in mobile apps.

Late Tuesday afternoon, Erik Haddad gave a presentation on the topic of Google's new machine learning options for mobile platforms. He demoed ML Kit in particular and showed just how easy it is to add machine learning functionality to a mobile app. The main takeaway was the simplicity of the ML Kit API. There really is no excuse not to use Machine Learning in mobile apps any more.

I’m A Teacher And So Are You.

The opening keynote on the second day was given by Lyla Fujiwara. It was great to hear Lyla’s talk as I’ve greatly benefitted from her work when learning Android development, so this was a truly special opportunity! Teaching to help others and solidify my own understanding is a technique that I try and incorporate into my daily life. Lyla’s talk discussed a variety of things to consider when you’re teaching, speaking, or creating education content. Here’s a quick rundown:

Setting the tone

1. Avoid using ‘obvious’ language (e.g. it’s obviously this) - it reduces belonging for those learning

2. Don’t aim to make something hard

3. Get diverse reviewers when creating educational content

4. Be vulnerable, and share stories of being a beginner

5. Encourage a growth mindset

6. Start with a win

Coming up with a path for students

1. Aim for simple

2. Begin with the start and end goal

3. Focus on what the student can do

4. Be explicit about prerequisites

5. Tell students where they are

6. Beginners are great trail guides

I must pay more conscious attention to these considerations when helping others. This talk inspired me to teach as much as I can and to try and incorporate my own non-traditional journey to engineering into whatever I teach.

Inhibiting the Imposter.

Shortly after the opening keynote, I attended the talk “Inhibiting the Imposter” by Ana Baotić. There couldn’t have been a better talk for me to begin the conference with. I’ve struggled with imposter syndrome in various areas of my life for a very long time. These feelings cause me great distress, and can lead to exhaustion and feelings of shame. Hearing so many other speakers at this conference be so open about their struggles with these fears gave me a sense of unity within the community.

Ana guided us through a tour of imposter syndrome, from what it is to potential solutions to inhibit this mindset. Here are her Steps to Help Combat Imposter Syndrome:

1. Visualize Your Fear - Imposter syndrome is something very personal for an individual and hard to separate one’s self from. Giving a face to your fear can help you move away from it in your mind. “Distance yourself from what’s attacking you”

2. Set SMART Goals - Specific, measurable, achievable, relevant, and time-bound

3. Find Balance - “you need to allocate time to what makes you happy.”

4. Progress Over Success - Rather than seek a more senior job title or these labels of success, try to focus on personal progress and evolving as an individual.

5. Failure as a step to progress - “Failure is always an option.” Nobody likes to fail, but a ‘failure’ is an attempt to progress. Failure is a learning opportunity to figure out what doesn’t work.

6. Mentor others - “Sometimes the best way to help yourself is to help others” was the essence of this point.

7. Do it anyway

“We’re all evolving” was a favorite quotation for me. It’s a great perspective to have in all areas of life.

Automation Pipeline.

Several presentations at DroidCon discussed the benefits of having an automated pipeline within development teams. The two talks that stuck with me were “Building At The Speed of Thought” by Siamek (Ash) Ashrafi and “Using Automation to Spark Joy & ‘Boost App Quality” by Joe Cyboski. Both speakers approached automation as a tool to eliminate the need to manually perform repetitive tasks and bring greater enjoyment to the process of development. Minimizing the feedback loop by automating tests, issue management, builds for QA provides agility and security to build more robust software. It was emphasized throughout the conference that a comprehensive test suite is the key to having an impactful workflow. DevOps practices and automation engineering facilitates teams’ abilities to “build small and often.”

Coroutines and RxJava.

Coroutines were a hot topic at DroidCon, with a Monday keynote by Sean McQuillan, a comparison with RxJava by Anton Spaans, and Rick Galbraith’s “You’re Doing RxJava Wrong” talk at the Unconference.

I’ve had experience with Rx and coroutines in other languages, for very different use cases. I’ve dealt with RxJS observables for Angular 2+ on the front end. Scala has plenty of functional libraries (Cats, fs2) that remind me of Rx. Coroutines have been essential when programming some Unity games with C#. I also remember trying generators in KoaJs, an alternative for the server side library ExpressJs that never really took off, and wondered if coroutines would have a similar fate. I’ve seen clients and coworkers evangelize using functional patterns exclusively, and wondered if another pattern could compete at this stage.

In the end, I was convinced that I would want to use coroutines for most purposes in Kotlin. They benefit from being native to Kotlin, and are much more simple to implement syntactically. RxJava is a large library with about five most frequently used methods out of ~100 available ones. Multiple presenters believed it was overkill for common operations such as database querying and HTTP requests.

When working with Streams and going beyond the basics, RxJava was still a better choice according to Spaans. RxKotlin might be more compelling than RxJava, but is not yet stable or well tested. No one said RxJava is going away - but they’re definitely pushing for developers to simplify their codebase by using coroutines where possible. Now I’m disappointed that Scala doesn’t have similar support for coroutines.

Automation

Release woes were much discussed during the “Release the Kraken” talk and at my lunch table. At that second Unconference talk, Tom Wilson went over how his team went from monthly releases to biweekly ones, and have settled on weekly releases. He argued that the most important rules for a mobile release process are maintaining regularly scheduled releases and preventing the latest code from diverging too far ahead of production. He also described how automating testing and releasing helped the team be able to maintain a weekly cadence. Scheduled releases are less essential for backend development (which I’ve been focused on recently) so it was enlightening to hear how they were key for mobile (ensuring stability, predictability) and how that process could be sped up, versus a previous project which then had its own monthly release process. However, there was an important issue we caught just before a release. Rapid releases are a best practice, but can’t be done without automated and thorough testing, and dogfooding as well.

Everything was Kotlin.

In every talk I visited, slide I viewed, and presentation I chatted about with others, there seemed to be one glaring constant. Everything was Kotlin. As a React-Native developer with an iOS/Swift-heavy background, I greatly appreciated the “Building At The Speed of Thought” Siamek (Ash) Ashrafi gave. To him, Kotlin was a natural progression of languages, and seemed intertwined with Swift. Indeed, the Kotlin and Swift teams, to him, seemed to all but directly collaborate and share ideas, and took frequent inspiration from others’ work when extending their own projects. And it was easy to see why! Lambdas, elegant nullable values, enhanced support for functional programming, and even the simplest niceties that accompany a more concise syntax, all combine to form a language that is a pleasure to work in. Judging from the sheer use of Kotlin at this conference, I would take it as a sign that this sentiment — and other unmentioned positives — are being shared amongst other adopters of the language.