DevAndAndroid

Ten years in, the label was doing me more harm than good.

For about ten years, the first thing I said about myself professionally was “Android developer.”

It was accurate for a while. Then it stopped being accurate, and I kept saying it anyway.

Year one

The title fit exactly. I wrote Android apps. Someone else wrote the API, someone else designed the screens, and my job was to turn the second into the first.

Being good at one thing felt like the whole job. For a while, it was.

Year two

I joined a company with three or four engineers. One person on infrastructure and architecture, the CTO on the backend, and me on mobile. At that size the lines between roles are thin, so when the backend needed a hand I picked it up: rewards logic, payment integrations, referral tracking, reporting dashboards.

Something small changed there and it stayed with me. Before, when the API returned data in an awkward shape, I’d write code in the app to work around it. That’s what you do when it isn’t your code. Now I could open the other project and fix it at the source instead. A whole set of problems stopped being a negotiation and became a ten minute change.

Year five

A client needed the same product on both platforms, and I volunteered to take the iOS side.

I hadn’t written Swift before. It was also a payments product, so alongside learning a new language I was learning what that domain asks for: secure storage, authentication flows, the sort of requirements you can’t get ninety percent right.

Two apps, one person, a lot of late evenings. It was not elegant. But it was the first time I’d carried something from the database all the way to two different app stores, and I noticed how much faster it went when nothing had to be handed to anyone.

Year ten

By then I was on a large distributed team, working on apps used by merchants in more than a hundred countries. A completely different problem, and I was underprepared for parts of it.

Some of what I learned there sounds basic written down. I had barely opened a pull request before. On small teams I’d pushed to main and mentioned it to whoever was sitting nearby. Suddenly my code was being read line by line by people in five time zones who didn’t have the context I had, and I had to learn to write a change a stranger could review. Small, explained, with the reasoning in the description instead of in my head. I had to learn to review other people’s work the same way, which took longer.

At that size you don’t own the whole thing, and you shouldn’t. I spent as much time working across teams as writing code, and I learned things there I could never have learned on a small team.

But I noticed the same pattern from the other side. The most useful version of me, on the small team and the large one, was the one who could follow a problem across the whole path. Not because I was better at any single part of it. Because I could usually tell where the problem actually was.

Now

I’ve built two products with Kotlin Multiplatform. Both platforms, one person, sharing the code that makes sense to share and keeping the rest separate on purpose.

So “Android developer” isn’t the honest description any more. The honest one is: I build mobile products end to end. The Android app, the iOS app, and the backend behind them.

Why the label mattered more than I expected

I’d assumed the label was a description. It’s actually a filter.

When your profile says Android, the work that finds you is Android. Every conversation starts in the same place: we need an Android engineer, here’s the Android work. Which is fine. I like Android and I could happily spend a career in it. But it meant I was being offered about a third of what I actually do, and the rest of it was invisible to the people deciding what to offer.

I want to be careful here, because there’s a version of this that’s just vanity. Adding platforms to a list doesn’t make anyone better at any of them. “I do everything” is usually a warning sign rather than a credential, and I’ve interviewed enough people to know what it sounds like when someone has done a tutorial in four things.

The claim I’d actually make is narrower.

For a small team, one person who can take a feature from the database through both apps to the app store is often worth more than three specialists.

Not because that person is better at each part. Usually they aren’t.

It’s that the whole path stays in one head. Nobody waits three days for an API change to unblock the app. Nobody discovers in week six that the contract two contractors agreed on doesn’t survive contact with the iOS lifecycle. The seams are where small teams lose their time, and one person removes the seams.

That’s the trade, and it does go the other way too. On a team of forty, hire specialists, and I’d tell you so. On a team of four, the seams cost more than the specialism is worth.

What I’m going to write about

All this is to say, I’m writing here again, roughly weekly, about a wider set of things than before.

Less “how to implement X in Compose.” More about what actually happens when you own a mobile product end to end. What’s worth sharing between platforms and what isn’t. The backend a small app really needs. What breaks in the second year. The decisions that are cheap now and expensive in eighteen months.

Some of it will still be Android, because that’s where I’ve spent the most time. Some will be Swift and SwiftUI. Some will be the API underneath, which is where a surprising number of mobile problems actually live.

Ten years in, I still enjoy this as much as I did in year one. The only thing that’s changed is how I describe it.

If any of that sounds useful, follow along.

---

I write here about building mobile products end to end: Android, iOS, and the backends behind them. Roughly weekly. If that’s useful, follow along on Medium or LinkedIn.

I also take on a small number of freelance projects a year, usually small teams building a mobile product from scratch, adding a second platform, or taking over an app that’s become hard to ship. My work is at devanddroid.com/portfolio.