- JetpackCompose.app Dispatch
- Posts
- JetpackCompose.app's Dispatch Issue #6
JetpackCompose.app's Dispatch Issue #6
💌 In today's issue, we meet Annyce Davis, discuss the decline of mobile dev, Storybook like tool from JetBrains, better way to measure “seniority” in software engineering & the badass developer of SQLite
What’s the status of the release?
What’s the status of the release?
What’s the status of the release?
What’s the status of the release?
Tired of answering the same questions every time you ship an update?
GM Friends. This is JetpackCompose.app’s Dispatch, the Android Development newsletter that's as satisfying as perfectly peeling an orange in one go.
This is Issue #6 and here’s what he got for you today:
🤔 Interesting tid-bits
Spicy blogpost from Donn Felker
Donn Felker, one half of the popular Fragmented Podcast, has dropped a bombshell with his spicy article titled “The Decline of Mobile Development”. Donn highlights how mobile development has morphed into a game of meeting restrictive requirements through forced updates, where developers spend more time wrestling with platforms than actually building cool stuff – you know, the fun part.
The post has stirred up quite the conversation among seasoned Android engineers, many of whom resonate with Donn’s sentiments.
Donn’s blogpost generated strong reactions from Android veterans that mostly agreed with him
Over the past six months, I’ve been chatting with people I respect and admire about a related topic: the un-sustainability of indie Android development. Unlike the iOS/Web ecosystems, where many can generate enough revenue to sustain themselves, indie Android developers often face an uphill battle. This is a crucial issue, and I plan to dive deeper into it in future editions of Dispatch. There’s a lot more to unpack here, so stay tuned for some more tangential topics that haven’t been discussed enough!
Cross-platform auto generation of code from design system tokens by Amazon
You know that feeling when you discover a fantastic tool way too late? Like finding out your phone has a flashlight after years of using a candle. That’s me with Style Dictionary.
For the past four years, I’ve been knee-deep in Design Systems and UI Infrastructure land. Yet, embarrassingly enough, I had no clue about this project. Style Dictionary, an open-source project from Amazon, lets you define your design token symbols in one place and auto-generates code for every platform you support. It’s like having a universal translator for your design system so that you never go out of sync across all platforms – that’s the magic here. This might sound a bit abstract so this video gives you a quick demo of how this library helps.
My team painstakingly built something similar internally, but if I were starting today, I’d be all over this. And guess what? They recently added support for Jetpack Compose and SwiftUI. So, whether you're on Team Android or Team Apple, this library has you covered.
JetBrains previews a Storybook like tool for Compose
Some of you might know me as the author of Showkase, the Jetpack Compose library that collects all the previews in your codebase and lets you browse through them in an auto-generated component browser. I launched it back in 2020, when Compose was still in pre-alpha, aiming to fill the void in the Android ecosystem compared to the web’s beloved Storybook. While Showkase isn’t a one-to-one replacement, it certainly plugs a lot of gaps.
Fast forward to 2024, and the Compose ecosystem has matured significantly, even becoming multi-platform. This evolution has caught the attention of JetBrains, who have recently previewed an early version of Storytale, a Kotlin Multiplatform product with similar ambitions. Wrapping your head around what it does can be tricky, so I highly recommend watching this short video (safe to download this video) to see its potential. If you only click on two things from this email, let this be one of them. The other, of course, is Runway, our awesome newsletter supporter.
Storytale allows you to develop Composables in isolation, along with documenting and testing all it’s behavior
I’ve always been bullish about the need for such a tool, and I’m excited to see how this space evolves. It’s still early days, but I have a strong feeling that tools like Storytale could become a staple in developing with Compose.
The badass creator of SQLite
Source code is often a treasure trove of hidden gems and easter eggs, and SQLite is no exception. Most of you are probably familiar with SQLite, the disk-based database that's become a staple in the software industry. It's used across major operating systems (Android, iOS, Windows), web browsers, and countless other critical software. Even if you haven't used SQLite directly, you’ve probably used it indirectly through libraries like Room.
Part of SQLite’s widespread adoption is due to the creator's decision to make it freely available for any purpose, without restrictions. Here’s a quirky snippet from its source code:
🫡
How badass is that? It’s philanthropy at its finest, even if most people don’t perceive it that way. While some aspire to be rich enough to buy a yacht, I aspire to write software and give it away for free all day, every day, just because I want to. We’ll get there someday, fellow nerds!
😆 Dev Delight
🥂 Tipsy Tip
LLMs (Large Language Models) have become an integral part of our workflows. They’re great for writing code, but it would be nice to also leverage them for reviewing the code we are writing/modifying. Sure, you can set up a fancy GitHub Action to handle this, but what if you need to ask specific questions about just the changes you made, not the entire file (especially if you’re making changes to something massive like View.java in AOSP 😅).
Here’s a quick pro tip 💡- add .patch at the end of any GitHub pull request URL. This will give you the Git patch containing the diffs of your PR. LLMs understand this format well and can focus on the exact changes you made, which is super handy for many use cases. Give this link a shot to understand what I mean
// Notice the ".patch" added at the
// end of the Github pull request url
https://github.com/airbnb/Showkase/pull/389.patch
LLM’s understand this format really well so you can copy-paste it and ask questions about specifically your changes
🎥 Media Player
About six years ago, I watched a video that influenced my views on software engineering career progression. I've referenced it countless times and frequently recommend it to my team. In this talk, Randall Koutnik argues for a better way to define and measure “seniority” in software engineering. He proposes a framework based on three levels:
Solution Implementer: Focused on writing code and solving specific problems.
Problem Solver: Focused on breaking down larger problems into smaller, manageable parts and finding solutions.
Problem Finder: Focused on identifying and prioritizing the most important problems to solve.
I find this framework much more effective than simply labeling engineers as “junior” or “senior.” Plus, using “years of experience” as a criterion for career progression is meaningless in a world where “rest and vest” is an open secret.
As a guideline to understand how these relate to the traditional levels that the tech industry has been using, this is my mental model to map them to the typical levels that we are familiar with:
Randall’s Eng Levels | Traditional Eng Levels |
---|---|
Solution implementer | L3/L4 engineers |
Problem Solver | L5 (Senior Software Engineers) |
Problem Finder | L6+ (Staff+ Engineers) |
I highly recommend watching this talk. It's a valuable investment of your time and I would encourage you to make sure your managers watch it as well. Hopefully, this will provide the ammo you need to make a compelling case for a promotion by the end of the year 😂. After all, I want every single one of my subscribers to get promoted – you’re dedicated to your professional growth and take the time to read Dispatch so you absolutely deserve it ❤️
👩💻 Featured Subscriber
This issue’s featured subscriber is Android GDE and OG Annyce Davis, who has been successful in growing her career in a prolific manner and was most recently a VP of Engineering at Meetup.
What’s your favorite Android Studio feature or shortcut?
Currently, enjoying “Interactive Mode” of the Compose Previews. It lets me iterate so quickly without having to launch anything on the emulator.
What's your daily driver?
Google Pixel for life 😜
You were able to grow in your career much beyond the Android specialization that you started with. What advice do you have for Android engineers who are hoping to do the same thing with their own careers?
Think of yourself as an engineer first and an Android engineer second. Our goal is to use technology to solve business problems. Sometimes Android is the right choice, but it’s not always. That mindset has helped me to stay open-minded and always eager to learn something new.
What was your go-to question when you were hiring an Android engineer on your team?
How would you describe the architecture of a modern Android application? This question is always relevant. It helps you to understand what “modern” means to them. What technologies they are familiar with. Also, assess their thoughts/opinions about the state of Android development.
What’s your favorite feature in Jetpack Compose
I love the simplicity of the navigation implementation. Having worked with Android for so long, I appreciate having the Navigation Host and clear visibility into the available composables and how they go from one place to the next.
One project that you feel most proud about shipping
I’d have to say it was a word game I built with my brother. There was so much to learn. How to use a game engine SDK, creating the proper graphics, animations, game play, monetization, etc. It was a labor of love and I still think about it fondly.
Favorite purchase in the last year
A handheld vacuum that’s for pet hair. I have four dogs. Yep, four! I use it every day.
If you weren't a Software engineer, what profession would you choose instead?
I’d be a teacher. There’s something magical about sharing what you know with others and getting to see their “ah-ha” moment.
👩💻 Code Corner
Sometimes you want to draw a border around a Composable function, but only on one or two sides. Andrey wrote this handy Modifier that allows you to specify which sides of the border should be drawn.
👂 Let me hear it!
What’d you think of this email? Tap your choice below and lemme hear it 👇
On that note, here’s hoping that your bugs are minor and your compilations are error free,
Reply