A First Time Speaker’s Journey from CFP to Stage

A First Time Speaker’s Journey from CFP to Stage

One Week to Decide

On October 29, I found out The Lead Developer New York had open CFPs — and the deadline was November 5.

I sent a slack message to my team saying “I’d love for us to send proposals regarding how multiplatform development, specifically kotlin multiplatform, changes your team, development, processes, lowers technical risk, schedule risk, cost, etc, etc.”

This was the first time I ever thought about responding to a CFP and didn’t know if it made sense to the company, to my schedule, or to any of my colleagues. What I did know was:

Thankfully, @namnum was super supportive, immediately responding to my slack message with “Hell yes! How can I help?” 

Since this is a “Lead Developer” conference, I roped in @samhill303, our head of engineering, to go through the process with me.

We only had a week, so we had to work fast. Here’s what we did:

  1. Brainstormed titles with very light outlines to add some context
  2. Talked through which ones resonated more with us personally, as a company, and the potential audience
  3. Stopped thinking about the ones that didn’t resonate
  4. Added more definition to the outlines that survived
  5. Talked about what makes a title and description interesting (both @kpgalligan and @namnum have read and written a lot of proposals)
  6. Turned 2 outlines each into descriptions with interesting titles
  7. Quick peer review
  8. Send 2 proposals each

Two Months to Wait

Normally, The Lead Developer organizers get back to applicants within a month, but, because of the holidays and some unforeseen scheduling changes, we had to wait until January.

I didn’t know that until they sent a note mid-december so I was looking at my email pretty often until then. Waiting is definitely not fun, but it is important that the people reading through proposals take their time to figure out if the talk will fit well with the conference goals and time-slots. I talked to @Geek_Manager afterwards about this and I was very impressed with how much effort the organizers put into choosing the talks for a successful conference.

The CFP response form also asked whether the talk could be 30 minutes or 10 minutes. Since I checked both options, I had the extra suspense of not knowing how long I would be on stage if I were accepted. Though that added to my anxiety, I was glad to have both options available.

In early January, I finally learned that I was accepted to give a 10 minute lightning talk!

Three Months to Prepare

The Long Outline

We had a lot going on at Touchlab in January so “prepare for the conference” was in the “Important but not Urgent” category. Being the first time I’ve done this, I really should have gotten started immediately, but, at the time, putting it off a little later made a lot of sense (see @allspaw).

The urgency came when I found out there was an opening for the February meetup. I got started right away (Feb 4) on an outline which turned into a MUCH longer effort than I planned so @kpgalligan filled in my slot with some KMP updates.

I promised to have things ready for the March meetup — and I did! It was difficult because I had such a long outline. The prep I put into the outline — organizing, researching, reorganizing, more researching, more reorganizing — was invaluable not only for putting together the meetup slides but for sharing knowledge with Touchlabers, and speaking more intelligently with existing clients and prospects. In fact, as a concrete benefit, I published an initial blog post for some of these which got picked up by Hacker Noon!

The Meetup Slides

Even though the outline was so long, it was incredibly useful for speeding up the slide making process. Here’s what I did:

  1. Move the outline 1:1 to slides — copy/pasting line items into slides, batching multiple lines into one slide if that seemed appropriate
  2. Replace outline in slides to more slide-friendly bullet points and move outline to speaker notes
  3. Lower the amount of text on each slide by incorporating graphical representations
  4. Replace outline in speaker notes with natural language

I went through a few iterations of graphics, speaker notes, and slide CRUD. By demoing sections of the slides internally, I could incorporate feedback and iterate towards the following goals:

  • Language sounds natural
  • Individual slides aren’t confusing given what I’m saying at that point or what I’ve said up to that point
  • Individual slides aren’t distracting
  • Organization of slides tells a story
  • The story isn’t more than 30 minutes

Not all the goals were met for the meetup but there was very good progress. Here are the Meetup slides with some transitions removed. The talk came in at about 20 minutes, there were a ton of good questions at the end, I was told the content was good, my ability to present was good, and, most importantly, I felt much more confident afterwards.

The Webinar Slides

This event was a “crazy idea” from marketing. We didn’t know if it made sense or if it would actually happen but from the blog post and the success of the meetup, we knew it could happen.

The meetup slides didn’t include the images from the blog post and our webinar was meant to be more about “How to Evaluate Mobile Multiplatform Solutions” so I worked on editing the Meetup slides to include them and also update the story for a different audience.

I followed essentially the same process as putting together the meetup slides, the big difference being Touchlab’s designers (Nelmer, Frances) gave me some help. They had only a few days to improve my slides and we were all working feverishly until 5 minutes before to integrate designs into the final version. It didn’t all get done, but they did an incredible job, and we knew this wouldn’t be the last time they could help (the real show would be Lead Dev). Next time, I’ll bring design in earlier, much earlier.

The webinar surpassed expectations! We were expecting about 50 people to show up…we had over 100 and 70% stuck around for the entire presentation!

The Lightning Outline

The meetup presentation was about 20 minutes and the webinar was about 30 minutes. I needed to take what I made and learned from both, and bring it down to 10 minutes. Making the meetup 30 minutes from the original outline was difficult enough, so I knew there’d have to be some drastic changes.

So I made a new, hyper-focused outline, the lighting outline and got to work slicing, dicing, mixing, and matching the meetup and webinar slides.

Keeping the technical model from the webinar, the 3 dimensional perspective inspired by the above-the-line/below-the-line framework, and the timeline from the meetup — even after removing all but the most currently relevant solutions (goodbye RoboVM, j2objc, etc) — it was nearly 20 minutes 😩.

The Lightning Slides

In order to make this a 10 minute lightning talk I started thinking of it as a movie trailer. If a 2 hour movie can have a 2 minute trailer, I should be able to bring this down to 10 minutes. Luckily, White October Events has a youtube channel with all of the past Lead Dev recordings. I could use previous lightning talks as inspiration.

I removed the intro to me, Touchlab, and the talk. I removed orienting the audience with what I will talk about. I removed extra details/context for various slides.

This got it down to 13 minutes…nearly there. I experimented with talking faster: down to 10 minutes! OK, but I didn’t want to rush too much. What was left was editing the speaker notes. I removed adverbs, adjectives, combined sentences then simplified them. I was ruthless in prioritizing details and removing the less important ones. Then, finally, I ran through a couple times clocking in under 11 minutes 😅 

Editing down from 30 minutes to 20 didn’t take very long. Editing down from 20 to 13 took a little bit longer. Editing down to 11 took a lot longer because there’s so much that I felt important that I didn’t want to lose and when I made the decision to lose it, I’d read through again and want to bring it back in favor of losing something else.

I knew I couldn’t make it shorter without modifying pacing so that’s what I worked on until the day of the conference. I also found out there would be a clicker and confidence monitors, so I tried to recreate that the best I could too.

One week before the conference, I was about to submit my final slides. But then Touchlab announced partnering with Square and introduced the Kotlin Xcode Plugin. These were both such important news I had to find a way to add them to the slides. I already had one slide where I described what KMP will look like for iOS in the near future so I broke it up into multiple slides to showcase the partnership, the plugin, and a few select multiplatform libraries that are pushing the ecosystem forward. My final lightning slides were finally final and I sent off the email to make it official.

10 Minutes to Speak

After all the prep — the meetup, the webinar, the seemingly endless rounds of practice while editing down to 10 minutes — I was feeling really good. I was still nervous (even writing this, thinking about “the day of” is making my heart race and my hands shake) but I knew it would work.

Thanks to the speaker’s dinner, I got to meet people I’d be sharing the stage with. Talking about stuff other than “the day of” allowed me to relax and, most importantly, understand that everyone else on the stage are also people who get nervous and have to prepare. I could think of them as friends which meant when I walked to the venue the next day, it felt like a reunion.

Because of my prep the weeks before and because of the speaker’s dinner, I was much less nervous. What I was worried about was the execution. Since I used Keynote, I expected the layout, size, animations, graphics would all be fine. But I had never used confidence monitors before and I knew from practice that it’s possible my speaker notes would be too small, I’d get lost in my notes, lose my pacing, and potentially choke (not really, because I did get lost in the Meetup and it was fine, but this was crossing my mind because anxiety is real).

That morning, I saw other speakers running over their talks one last time, I saw them chatting about nothing in particular, and I saw them go to the stage before the audience arrived to become familiar with the setup. So I asked to pull up my slides, I stood on the stage, and flipped through the first few to test the speaker notes. They looked great.

I spent the rest of the time before my talk watching those before me, getting into the feel of the conference, getting wowed at the presentations (while not feeling bad about mine).

And then it was time to mic up. I talked to @lara_hogan, @Geek_Manager, and @samhill303 before the lights dimmed. Then started feeling my hands shake again, but I wasn’t first on stage, so I did some breathing and thinking (sorry @iamagiantnerd for not giving you my full attention).

And then I was on the stage shaking @lara_hogan’s hand. And then I started to talk. And then I noticed I didn’t have the clicker. And then I saw the countdown clock. And then I heard the audience laugh. And then I saw some people look interested. And then I was done.

Closing Thoughts

Speaking in front of so many engineering leaders was amazing and I spent the rest of the day winding down talking to other speakers, audience members, sponsors, and even some potential business partners.

When the recording came online, I was expecting the worst. But other than looking down at my notes a bit too much, I’m actually really proud of how it turned out. Once again, @whiteoctevents did an amazing job with everything.

I know for sure that I have grown in so many ways from this experience and I plan to speak again. The personal benefits of going through this entire journey are immense and I highly recommend giving it a try. I hope writing down my journey helps you on your journey.

Engineering Manager Framework: How to Evaluate Mobile Multiplatform Solutions

Engineering Manager Framework: How to Evaluate Mobile Multiplatform Solutions

The following text is transcribed from our Kotlin Multiplatform webinar. There is a video at the bottom of the blog post if you would rather listen to the segment. If you find this segment interesting, you can register for the full webinar recording and slides here

 

Slide 1

This diagram. Here’s where we find out what Native really means, and, even simplified, there’s a lot going on here.

Definitions

This input category is how the app developer writes the app. A Native Language isa language officially supported by the platform. Swift and Objc on iOS, Kotlin and Java on Android, HTML/CSS/Javascript on Web. An Other Language is a language like JavaScript on mobile, or ClojureScript on the Web. It also includes WYSIWYG visual programming interfaces that some no-code multiplatform solutions use.

The Process category is what the build chain does to the input in order to create an output. I mentioned Cross-Compilation and Trans-Compilation earlier.

But to clarify both of these, cross-compilation here is when a high level language is compiled directly to the native code for each various platforms before outputting the final product. This is called Ahead of Time compilation or AOT for short.

Trans-compilation here is when a a high level language is compiled to a another high level language which can then be fed back as input to another process, usually to a language native to the platform that can then go through the native build-chain.

Runtime here includes things external to the platform that implements portions of an execution model needed to execute the app like virtual machines, interpreters, and necessary libraries.

The Outputs category determines the type of app generated. Native Code is the low level code executed natively by the platform. Native code generates Native apps. A Native Container bridges web technologies with platform specific technologies by running web code in a webview on the native platform. A native container plus web views generates Hybrid apps. As mentioned before, a Native Language needs to be processed again to become a mobile app. But, it could also create a Web app if the output language is JavaScript or Wasm.

Once I put this together, I searched through documentation looking for how different tools worked and fit them into this model. I’m going to talk specifically about Ionic because it is a Hybrid solution, but more importantly, I’ll talk about React Native, Xamarin, and Flutter because they are so popular and, of course, I’ll talk about Kotlin Multiplatform because that’s why we’re all here. One last thing before we move on. Notice how this starts to explain some of the negative feelings we have about cross-platform solutions. For any solution, If we need to code in a new language, it will slow developers down. And, If there is an interpreter or VM between code being asked to run and code being executed, it’s going to slow the app down. And for hybrid solutions, a webview is fairly heavyweight and will slow things down even more

 

Slide 2

Ionic is a popular Hybrid app development tool built on Apache Cordova. You write your app in standard web technologies; the runtime includes widget libraries and native platform interop libraries, then, everything is wrapped in a native container and you get a hybrid app. Now, the web and mobile are different. On mobile you need to handle things like the offline experience, the application lifecycle and back button expectations. Hybrid solutions promise to make things easy, but you actually need to work really hard to make a hybrid app meet native expectations. 

 

Slide 3

React Native takes something that worked really well on web (that is, react) and makes it work on mobile better than hybrid apps. You develop mainly in Javascript and the runtime provides native or native-like widgets along with tighter interop with the underlying platform. Native code is output at runtime by the JavaScriptCore interpreter which allows the app to be categorized as Native. The differences between web and mobile are still issues to consider, and it’s easier to meet native expectations with React native, but it’s still difficult. For example, one of the problems mentioned by both Airbnb and Udacity is the 3 platform issue: to make their React Native apps more native, they had to deal with the javascript bridge and code independently for Android and iOS. This was more of a pinpoint than expected and they needed to do it more often than expected

 

Slide 4

Xamarin was one of the first to focus on sharing business logic with native code across platforms. It was quite a bit later in Xamarin’s life that they introduced Xamarin.Forms to share UI as well. You write your code in C#, and it gets processed to include the .NET runtimes. On iOS, it is all compiled ahead of time because iOS doesn’t allow 3rd party execution engines on Android. The Mono VM is included in the distribution so it can just-in-time compile native code at runtime. AOT is generally faster than JIT and benchmarks do show Xamarin.Android is significantly slower than Xamarin.iOS

 

Slide 5

The Flutter solution is yet more native because it AOT compiles on both Android and iOS. You write your app in the Dart language and, for dev builds, the Dart VM will JIT compile, but for production builds it will AOT compile all the necessary run-time libraries for widget rendering and business logic directly to native code. 

 

Slide 6

Kotlin Multiplatform is the most native solution yet. It is first-class for developing Android apps. Kotlin is already the best for this and fully supported by Google. Flutter is not first-class for developing Android apps until Google puts a lot more money into it and commits to it because they will need to sustain both the Material Widget library on Flutter and the standard Android widget library. Neither Xamarin nor ReactNative will ever be first-class for developing Android apps. It AOT compiles on iOS to a standard Objective-C framework which is already first-class on iOS and, even though Swift is becoming more popular, Objective-C frameworks are still prevelant. ReactNative is difficult to use in existing apps. Xamarin is impossible to use with natively developed apps. Flutter is working on it.

And that’s a huge difference: Kotlin Multiplatform is about optionally and easily sharing code. ReactNative, Xamarin, and Flutter are foreign ecosystem with a disconcerting amount of vendor lock-in. Kotlin Native also outputs to JavaScript or Wasm for sharing code with web. It’s more difficult than it should be to share React for web and ReactNative, but there is a way. Xamarin isn’t officially supporting web output yet, but people are trying. This model is quite good and this is how most people approach the definition of native, even if they haven’t thought about it as deeply as this. Often it is simplified to just the final App Types, with Web being on one end of a spectrum, Native being on the other, and hybrid filling out the in between. 

 

Recording: Webinar Segment

 

The video is from our Kotlin Multiplatform webinar. If you find this segment interesting, you can register for the full webinar recording and slides here

The Future of Cross-Platform is Native

The Future of Cross-Platform is Native

Cross-Platform Baggage

Cross-platform development is not held in high regard these days, largely because the apps that purport to provide cross-platform support have never really done the job effectively. But I believe the time has come for us to reconsider.

The arguments in favor of cross-platform development are the same as they’ve always been (D.R.Y., Risk Mitigation and Feature Parity)

 

Don’t. Repeat. Yourself (D.R.Y.)

There’s the argument for gaining efficiencies and cost savings through streamlining the development process. Program once to create cohesive code that can be deployed simultaneously to iOS and Android.

 

Risk Mitigation

There’s also the argument for minimizing risk regarding how UI will be developed. The biggest risk is that the UI won’t meet user expectations on either platform. This is a major reason why development teams opt for programming apps independently from one another. At the same time, business logic and backend development are at higher exposure because both determine how all features within an app will work. Ideally, in a cross-platform development scenario, an organization could take the time to focus on the nuances of backend and logic development, while putting less strain on UI development.

 

Feature Parity

The other argument is for feature parity and inclusivity, that is, fewer differences in functionality, whether iOS or Android. The benefit – you treat all users equally because they are using essentially the same program, whichever platform they choose.

 

Native Multiplatform Development

However, what was missing from “cross-platform” is native multiplatform development: Native CPU, Native UX, and Native developer experience and tools for iOS and Android. Cross-platform programming has the potential to thrive if the focus shifts to native coding, which is a more direct approach to produce the same functionality across platforms and devices. To better understand this, here’s a quick look at the most popular cross-platforms solutions and their native limitations.

 

Xamarin

Xamarin was one of the first to focus on a native approach to programming across iOS, Android, and Windows, starting with shared business logic and working its way toward shared UI with Xamarin Forms. However, its native elements are limited because it lives within its own ecosystem and uses C# (a language not native to iOS or Android development) and Microsoft Visual Studio instead of Android Studio or Xcode.

Xamarin Mobile Architecture

 

React Native

React Native (RN) represented a leap forward in terms of how developers thought about cross-platform because it empowered them to apply their web development knowledge to build native iOS and Android apps. But, like Xamarin, it too, lives within its own ecosystem, using Javascript and non-standard editors . And like Xamarin, it needs to wrap native controls and view hierarchy from its own interop, making it necessary to construct the UI with its own language.

React Native Mobile Architecture

 

Flutter

Flutter, a newer addition to cross-platform programming, uses its language Dart to create iOS and Android apps. Flutter also makes use of rich widgets to provide remarkable native experiences on Android and iOS platform – but the widgets are not native. Flutter also employs a shared UI platform that only works on mobile with a language (Dart) that isn’t widely used.

Flutter Mobile Architecture

These are just a few examples of why cross-platform programming has traditionally been a serious challenge to manage. It’s one of the reasons I believe we should move away from the term “cross-platform.”  A more apt term is “multiplatform”, because the goal is that any code you share maximizes what each platform offers.

 

Kotlin Multiplatform

That brings us to Kotlin Multiplatform. It is the rising star in the multiplatform space, and is, in fact, more native than Xamarin, RN or Flutter. Currently the dominant Android language, Kotlin has a strong, enthusiastic base of developers worldwide, and is praised by the community for providing a superior developer experience. Kotlin Multiplatform enables developers to write once, and test once, then use the same code across iOS, Android, and Web apps.

While not the first multiplatform tool to split business logic and UI (for instance, Xamarin for logic/libraries and Xamarin Forms for UI), it’s more native than Xamarin, RN, and Flutter because it uses shared logic and libraries below the UI layer, which developers can interact with in the native developer environments — Xcode, Swift, and Objective-C for iOS; Android Studio and Kotlin for Android; JavaScript for the web — and it outputs native code for each platforms.

As a language, Kotlin enables developers to produce applications more cohesively. It’s a modern language that dovetails with native platforms on Android, iOS, Java, and the web, allowing development teams to build on what’s already been coded. And because it’s essentially an extension of Java, it’s relatively easy for Java developers to get started. Kotlin isn’t too much of a departure from Swift either and at Touchlab we currently have iOS developers coding in Kotlin.

Kotlin Multiplatform Mobile Architecture

Equally important, Kotlin is a way to future-proof applications developed today. It’s a sound technology investment because the code works on all platforms without vendor lock-in like Xamarin or React Native. So, whether the dominant platform in the future is web or mobile doesn’t really matter, because the code ports to either environment.

At the same time, development teams no longer have to be siloed, and instead can work together as a cohesive whole. There is no longer a need to have dedicated iOS and Android teams.  This unified mobile approach simply makes more sense operationally, technically, culturally, and financially.

Is Kotlin the safest bet? Everything indicates that it, in fact, is. In a world where we’re always looking for greater efficiencies in development time and costs, Kotlin has proven itself to be a very viable player – one that has already shown itself to be a truly multiplatform programming option.