About

Teams usually have a change in mind before they call me. Move this part to Swift. Replace the navigation. Fix the thing making the app feel slow. Get the migration moving again.

The change is rarely the hard part on its own. The hard part is working out what it will disturb.

In a mature app, a small change can reach more of the product than expected. In a new product, the code is not difficult yet. The work is choosing what must be true before the first release and what can stay easy to change. I have done that as the iOS owner of an early device-connected product, from 0.x testing builds through clinical studies and clinical builds.

I work with the team through it: the code around it, the product it supports, and the release that has to follow it.

I have spent about fifteen years in iOS, across existing product codebases, cross-platform delivery, production stability and performance work, and device-connected clinical products. I have led iOS, Android, and QA work as well as written the code. A recommendation is not finished merely because it reads well in a document; it has to work for the people building and maintaining the product.

The first conversation is about the piece of work in front of the team. I need to see the relevant code and context. After that, we should know whether the work is small, defined, or pointing at a different problem.