Month: June 2026

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.