Dowell Dev

I just published version 1.1 of Tomo Time, my simple Pomodoro timer app. It used to be called Tomatimo, ten years ago. Over the years, I got too busy to deal with the upkeep, Swift kept releasing new versions, the codebase fell further behind every year, and eventually even the UI looked dated because SwiftUI exists now and UIKit doesn’t get invited to the party anymore. The gap got wide enough that catching up felt like its own project.

A couple of weeks opened up on my calendar. I had an old repo and an AI agent ready to help me debug, so I went for it.

Sledgehammer first, precision later

Step one: upgrade the Swift version to something the latest Xcode would work with. Step two: fix the deprecation warnings, and there were a lot of them. Step three: find a SwiftUI bootcamp so I could get the UIKit out entirely.

At that point it felt like I was taking the house down to the beams and rafters just to modernize it. But it worked. The app was theoretically shippable again, assuming the old one had been.

The bug that survived seven years

There was one bug a user reported seven years ago: the app would forget where it was if it went into the background. I’d learned a lot since then, mostly about how aggressively iOS garbage-collects anything not currently on screen. The fix was simple in concept: serialize the timer state to JSON, write it to a file, and resync it to the current time when the app comes back to the foreground.

But my old data model was working against me. Old me didn’t mind double-tracking the same data — I was storing both how much time was left on a timer and when I expected it to end. That was fine when the overhead was minimal, but SwiftUI put more pressure on keeping the model clean, and adding serialization on top of that made the redundancy impossible to ignore. A running timer only cares about its end time, since remaining time is just a calculation from that. A paused or idle timer only knows its remaining duration, because it doesn’t have an end time yet. Tracking both meant every read had to guess which one was actually true.

The right shape for the data

In Kotlin, this would be a clear use case for a sealed class with data class members. Swift’s enum associated values are the closest native analog:

swift

case running(endTime: Date)
case paused(remaining: Double)

That change did most of the work, and Swift made the enum Codable automatically, so I got JSON and UserDefaults serialization for free. I didn’t need a private index to track which timer was “currently running” — I could just filter for the one that said it was running. Resyncing to the current time became a matter of finding the first timer with an expiration date still in the future.

It’s Interface Segregation for data models: don’t make a type carry state it doesn’t need. Ten years of drift, and the fix that finally stuck was making the model say what it meant.

I’m a creative person; I like to make things. My “fidget toy” is crocheting little gifts for my engineering team during crunch week. Sometimes I paint, or I play music. And I write code for the same reason — because there’s something deeply satisfying about making a thing that wasn’t there before.

Modern culture likes to frame computer science as a discipline of pure logic. Vectors and matrices. Number crunching and data mapping. And yes, that’s true, but there’s an art to it. It sings. The developers I know have a creative outlet — music, woodworking, photography, and so on — and the ones who love building software tend to find that the craft itself scratches the same itch.

One problem, three ways

Here’s a simple example: given a string, return the most common character. If you’re in a functional programming mood:

val mostCommon = text.groupingBy { it }.eachCount().maxBy { it.value }.key

A nice concise one-liner. Until someone asks for edge cases in your unit tests.

Okay, we can prioritize some readability and maintainability here. The HashMap approach is still fine, but you’ll break it into multiple lines and leave some comments.

// Group characters and calculate frequencies in a single pass.
val charFrequencies = inputString.groupingBy { it }.eachCount()
// Find the map entry with the highest frequency count.
val highestFrequencyEntry = charFrequencies.maxByOrNull { it.value }
// Extract the winning character, default to ' ' if empty
val mostFrequentChar = highestFrequencyEntry?.key ?: ' '

It’s chattier, but the next person will understand easily where to start.

Or maybe performance is what you’re after. In that case you’d skip the HashMap entirely and iterate with an IntArray keyed by ASCII code:

fun maxAsciiChar(text: String): Char {
    if (text.isEmpty()) return ' '
    
    val counts = IntArray(256)
    var maxCount = 0
    var maxChar = text[0]
    for (i in 0 until text.length) {
        val char = text[i]
        val code = char.code
        if (code < 256) { // ASCII only
            counts++
            if (counts > maxCount) {
                maxCount = counts
                maxChar = char
            }
        }
    }
    return maxChar
}

Wordier and limited to ASCII, but it runs efficiently. The decision points are explicit, you know exactly where to put your breakpoints, and the unit test cases write themselves.

Three valid solutions to the same problem, each one a different expression of what you value. That's the art of engineering, shining through.

Build the thing that doesn't exist yet

The best way I know to keep that creative muscle alive is to build something just because you want it to exist.

Pick a problem that's yours. Make a weather widget and you'll learn about APIs. Build a to-read list that syncs across devices and you'll learn about user data. Or what I'm doing right now: build a music streaming app that generates endless lo-fi beats to work or study to.

That last one has been a genuinely fascinating learning experience, because the limitations I put on it are self-imposed. To make it sound right to me, the threads have to fire at the exact millisecond — even a tiny slip in timing pulls the listener right out of their concentration zone. The OS has opinions about what you're allowed to do in the background. Other developers have been here before you, and reading their solutions is half the education.

I have a background in digital music, so this project sits at the intersection of things I already love. But the specific topic almost doesn't matter. What matters is that you defined the requirements yourself, which means you're solving a problem you actually care about, which means you'll push through the frustrating parts instead of giving up when it gets hard.

And it will get hard. You will frustrate yourself. You will make mistakes that take two hours to find and thirty seconds to fix. That's the process: playing with the tools, learning from the mistakes, stretching a creative muscle you might not have known you had.

It can be hard to grind on side projects after a full day, and that's why building something you care about matters so much. The developer who stays interested enough in their side project to keep working on it, even when it's difficult, is the one who stays curious about what they're building.

Coding is a creative act — the act of building something new, from just an idea. Give yourself permission to play with it.