I recently reviewed some code at work that made me pause. The change affected a part of the codebase that we affectionately call “The Monolith”, which is some of the oldest code in our 16 year old app. While there are reasonable arguments that it’s hard to tease apart this older hairball of code, there are often small choices that can either move you closer to the decoupled promised land, or further entrench you in bad patterns.

I was recently pruning and organizing my RSS subscriptions and indirectly came across Jake Wharton’s hiring page. I knew he was on the job market, but I love the way he approaches this resume, by listing some of his values, clearly communicating what’s important to him and how he likes to work. This kind of straight-forward honesty goes a long way.

Over the past few years I’ve been driving an architecture and tech spec review process at work. This has been helpful in breaking down certain silos, distributing knowledge across the organization, and building skills and experience in more junior engineers. A recent tech spec caught my eye, and resulted in a really valuable learning opportunity.

A couple of months ago I was pair programming with a colleague, sharing my screen, and he was amazed to see the number of branches I had in my git repo. This wasn’t simply a case of poor git hygene, these were branches that I had started but never pushed, branches that were never merged. As I explained this I realized that my attitude towards starting and finishing projects has changed dramatically over the years.

I’ve been using feature gates for a long time. For all of their benefits, making sure that they get cleaned up and the old code is removed after roll-out is complete can be a challenge. By looking at some examples that I’ve come across recently I’ll share my strategy for making this boring work more likely to get done: just make it easier.

Many open source libraries allow you to extend them to work with your own custom data sources and data types. In this post we explore how Coil can be extended to allow you to use industry standard libraries in your own codebases.

Screenshot tests are a powerful tool, but come with some hidden costs. While they can help us quickly add test coverage to our UI code, for most of our behavioral tests they often test the wrong thing.

I recently gave a presentation about how Dagger works under the hood, and I was once again struck by the elegance of the javax.inject.Provider interface. The interface is so simple it almost seems useless, but it’s also incredibly flexible, and forms the basis of much of the code generated by Dagger.

Someone raised an interested question about how Android and iOS handle rounded corners in UI elemnets differently, so I used Jetpack Compose and Geometry to try to figure out why.

Modularization of Gradle projects can ease a team’s growing pains, but can also introduce challenges when architecting features that require knowledge of the specific modules used in an app. This post looks at approaches for dynamically aggregating dependencies in a project for reusable, extensible features.