DevEx

Let me be upfront: the app I’m about to describe is useful for maybe three weeks out of the year. It helps you figure out when to tap a maple tree for sap. That’s it. The rest of the year it just sits there, waiting for February to roll around again. I can’t think of much else targeting such a specific, and time-limited, niche…

A year ago, I wouldn’t have built this. Not because it’s hard, but because the return on investment is laughable. A few weeks of utility for evenings of development time, if I finish it at all, is not worth it. I’d just check the weather forecast myself, squint at the overnight lows, and make a guess like I did last year. The motivation simply wouldn’t survive contact with the reality of actually sitting down to build it.

I’ve been experimenting with using Claude Code on iOS to build projects from my phone. It’s been a great learning experience, and I wrote about the broader experiment in I Built an App That’s Only Useful Three Weeks a Year. But before that project went smoothly, I hit some friction that’s worth sharing on its own.

Most of these tips are specific to starting greenfield projects from your phone. If you’re making changes to an existing repo that already has the right files in place, the experience is significantly smoother from the start.

When using a single computer for multiple categories of development (personal, work, etc), there is often a need to set a specific user.email value for each repository cloned depending on the use. For example, it’d make sense to use your work email for repositories cloned for work while you’d use your personal email for you own projects.

Without the following setup, it’s very easy to forget to override your user.email at a repository level and end up committing to one or the other with the wrong email attached. Though not the end of the world, I can imagine your company, coworkers, and security department would prefer to see your work email attached to all commits instead of a random Gmail account.

Over time, whether working alone or in a team, your Git environment can become cluttered and messy with branches of the past, both local and remote. Though this isn’t an issue in the short term, if left alone, it can lead to time wasting mistakes, out of date code that doesn’t work once pushed to origin, and clutter in any Git tools or GUIs you may use leading to lower productivity.