The stand-up meeting was a sea of tired but triumphant faces. We’d done it. The last critical bugs squashed, the features merged, and the build was green. That beautiful, rare moment of calm before a release.

Then, the project manager cleared his throat. "Great work, everyone. Just one last thing... who's on release notes?"

Silence. I swear I saw one of our most senior developers pretend his connection froze.

It was housework nobody wanted to do. Like being asked to write documentation for code you didn't write. I wish I'd known sooner how valuable release notes can be, but I didn't. Not then.

For years, I treated release notes like a chore. A mandatory text field Apple forced me to fill. I’d cobble together a few lines from commit messages: “Fixed a bug,” “Improved performance”, and hit submit, convinced no one read them, anyway. In the age of silent, automatic updates, who even looks at the "What's New" field?

Recently, I was helping out on a project, and just because I had the opportunity, I ran the repo through my release note generator, to analyze and generate notes for their latest version. The discovery was illuminating: not only did it reveal the latest new features with surprising clarity, but it also highlighted the many other unrelated changes happening silently in the code and identified those who had been diligently working on them. It even showed me developer collaborations, and unsung heroes who quietly excelled by cleaning up and paving the way.

It hit me that release notes can be so much more than a last-minute "Bug fixes and minor improvements". A good changelog is a team-building artifact, disguised as paperwork.

Subscribe now

Although I cannot share release notes from that project, let me paint a picture using Signal, an open-source project I’ve previously used as an example.

The reason I keep using Signal as an example is that it's close to my heart because it's an iOS app, and obviously, because anyone can look at its source code. It's on GitHub!

So, let's have at it. For their latest release, version 7.71, they wrote the following:

Persistence pays off, but it's even better when things work on the first try. We fixed a bug that sometimes required multiple attempts in order to send a sticker from the iOS emoji keyboard. The same fix also works for Genmoji too, so we hope you Genjoy it.

That’s a surprising amount of heart infused into their what’s-new compared to other projects, but I suspect they’ve accomplished even more between this and the previous release. Let's dig deeper.

I cloned the Signal repository, ran version 7.71's commits through Release The Notes!, and here’s just a taste of what popped out:

• Fixed Voice Message Playback Crash with AirPlay. (Pete Walters)

• Restored and ensured proper swipe gesture functionality on iOS 26 devices. (Elaine, Kate)

• Reduced unnecessary UI updates during backup attachment downloads. (Max Radermacher)

• ..and 6 more.1 ⬅ See the footnote for for the full changelog.

That’s far more than a mere emoji fix. Pete, Harry, Max, Sasha, Elaine and Kate put in a ton of work. There's even a fix for the upcoming iOS 26 in there.

Keeping chronological release notes like this builds the team's collective memory. When did we add the feature flag system? It's right there.

Onboarding a new teammate? Point them at the last quarter's release notes. In twenty minutes they'll know what you actually ship (not just what the roadmap promises), who to ask about what, and the recurring themes. Patterns pop, gaps show up, and improvements follow. It’s a lot better than tossing someone a 40‑page crusty dusty “architecture” doc.

A good release note makes the invisible visible. Refactors, cleanups, process tooling, performance work, this is real value no one hears about unless we take care to highlight it. Not only that, but it feels good to see your name show up. It proves you're contributing, that you're part of this joint effort. It's a morale booster. Kudos to Elaine and Kate for fixing swipe gestures. Shout-out to Pete for improving translations. Recognition isn't a perk; it's fuel. Share the release notes as widely as you can, and celebrate the achievements.

Release notes aren’t a chore after the work. They’re the story of the work. When you make the invisible visible, you not only boost morale, you also show customers that this product is alive, improving, and cared for.

You shipped. Tell the story.

Dreaded questions:

• “What’s new in this release?” appears just as you’re ready to launch a new version.

• Your boss asks you to summarize the changes in this release.

Your mind goes completely blank, as if someone flipped a switch and turned off the lights.

​

That pain ends today.

Having polished every feature to perfection—because I truly enjoy this stuff, I’m thrilled to announce that Release The Notes! is now live on the Mac App Store.

​

What it does

You point it at your git repo, and tell it what commits to look at. It meticulously reviews each commit, transforming them into easily digestible, consolidated insights. Then it writes two types of release note - one for users, and another for stakeholders. Want a more technical, witty, or more concise version? Just one more click.

​

Why you’ll care

• No more git archaeology - let AI do the digging, you keep coding.

• Flip between a user-friendly tone and an executive summary—effortless.

• Less expensive than one developer hour, it pays for itself on the first day.

​

Try it free

​Download Release The Notes! and test the trial. No strings attached.

​

A 90-second demo

Not sold yet? Watch me turn 86 commits from the open source Signal app’s latest release into publish-ready release notes before my coffee gets cold.

When My AI Hammer Hit the Wrong Nail

The ChatGPT integration seemed brilliant when I first wired it into Gitonium's commit flow in early 2023. Automatic commit messages. Like finding cheat codes for developer productivity: no more paralysis facing that blinking cursor, no more "Fixed typo" cop-outs. My new AI companion would clinically dissect each diff - "Increase login button padding from 5pt to 10pt (ViewController.swift)" - and I'd commit with the smug assurance of someone who'd "solved" productivity.

But pretty soon, something didn't feel right. My shiny AI companion's notes felt shallow. Accurate? Sure. Helpful? Hardly.

The thrill wore off quickly. I found myself at first tweaking the commit messages and then rewriting them entirely. Eventually, I stopped using the feature altogether. Why? Because knowing "what" changed wasn't enough; I needed to know "why."

The Problem with "What"

Let's face it: commit messages describing only the "what" rarely offer any value. I can clearly see from the diff that padding was increased from 5 to 10, but WHY was it done? It's making the view look bad in some languages (hello, Germans!), and I want to know if I can just set it back to 5 or if we need to order new translations.

Aviv Ben-Yosef from Codelord.net put it best:

“These mean nothing. You may as well supply no commit message. Why did you even bother to write it?”

Then we have the developers who throw their hands up and just type something, anything! into the commit message field. We've all been there, groaning when navigating a git history filled with gems like "fixed," "make it work!", "minor changes," or even "blargh."

And it's more common than you think. Redditor, nelmo44, shared the pain:

“One coworker commits everything with just 'mods'.”

Ouch.

Why "Why" Matters

Code evolves rapidly in software development, but the intent behind decisions is timeless. Clear commit messages give context, reasoning, and crucial details for future debugging and refactoring. They're breadcrumbs for your future self, guiding you back through the maze you built months or years ago.

Contrast "Updated padding from 5 to 10" with "Increased padding to improve touch accuracy on smaller screens." Now, that's something you can work with.

As Dgant from Hacker News reflected:

“Commit messages might be pointless. Bad commit messages certainly are. I do a fair amount of git blaming on my own code and I find that my years-old messages do help me understand the purpose of old code.”

Why Good Messages Mean Better Teams

Clear, intention-driven commit messages don't just benefit individuals; they improve team communication and collaboration immensely. We always insist code should be readable for humans, not just machines. Yet we forget this principle when it comes to commit messages.

Ever spent hours tracing a bug through commit logs and blame, only to find unhelpful notes like "updated class"? Yeah, me too. Or perhaps you've worked in teams where every commit must have a Jira ticket number? A great idea in theory, right? Until a developer with writer's block decides to put ONLY the ticket number. Or until you click the ticket and find: "Change padding from 5 to 10" – the same shallow "what" in a different container. Zero intent, zero context. It turns out that ticket authors can be lazy, too.

Meaningful commit messages become indispensable when debugging or refactoring old code from long-lost colleagues, regardless of what other systems you use.

As Stephen Whitmore from DEV Community puts it:

“I see lots of commit messages that are like "Added x" or "Removed y". It drives me nuts because I have to investigate further. Messages that give the reasoning behind the change saves time.”

Writing Better Commit Messages: A Quick Guide

Want practical steps to improve your commit messages? It's simpler than you think. Before hitting commit, quickly answer these three questions:

1. Why was this change necessary?

2. What issue does it resolve or address?

3. What do future developers need to understand about this change?

Think of it as "Why Before What." A simple mental checklist that ensures your commit messages remain meaningful.

Looking Ahead: Leave Yourself Better Clues

Looking back, my journey from AI-driven excitement to a deeper appreciation for clear, human-centered communication taught me a lesson. Technology can simplify many things, but human clarity and intention remain irreplaceable.

Commit messages aren't just chores. They're opportunities to document your thought process clearly. They're "our aid in times of great need," as Aviv Ben-Yosef wisely notes.

So next time you're about to type "fixed stuff," pause and tell future-you why it matters. Six months from now, when you're knee-deep in a critical hotfix at 10 PM, you'll finally understand: commit messages aren't documentation. They're love letters to your future self.

Hello everyone! This week has been crazy. Bone-breakingly crazy. I'll get back to that. First, I have a new app to announce.

Release notes: loved when witty and honest; hated when it's your turn to write them.

Recently, as I wrapped up a quality-of-life update for one of my apps, I once again faced the dreaded empty "What's New" field. I was ready to submit the app update and move on, but first, this tedious busywork stood in my way. Every update always has more changes than I remember, and sifting through commits to recall them is painfully mechanical and dull. Inevitably, I start seeing commit messages like "make it work!" or "blargh," which means I need to dig even deeper. Turning raw commit messages and diffs into clear, engaging summaries takes too much mental energy.

But despite the dread, good release notes truly matter. Personally, I love reading them because:

• I'm curious to see what competitors or my favorite apps have improved.

• I want confirmation that specific bugs or frustrations have been fixed.

• I'm always on the lookout for hidden gems or amusing notes from fellow developers.

• (Secretly, I'm also judging how creatively or transparently others handle this thankless task.)

There had to be an easier way, but every existing solution I found was either a hardcore command-line tool with poor usability or a heavyweight online service that needed layers of corporate approval. Frustrated, I realized I was uniquely positioned to solve this problem myself. After all, I'd already built ​an entire Git client​ and had everything at my fingertips: code for repository interactions, diff computations, and even AI for interpreting code changes.

After a few quick tests, it became obvious I was onto something real. And so, Release The Notes! was born.

Release The Notes! is a macOS app that transforms your commits, diffs, and branches into clear, natural-language summaries. Think instant, polished release notes without lifting a finger.

An early version is already in testing, and I'll soon invite more testers. If this sounds like something you'd love, visit ​releasethenotes.com​ and sign up now!

When It Rains, It Pours

This week, the universe decided to redefine "improbable" for our family. On Monday, both of my boys managed to break their wrists. Yes, both wrists, both boys, on the exact same day. And no, they weren't even together: one was snowboarding while the other was at football practice. Seriously, what are the odds? At this point, I'm torn between buying lottery tickets or investing in extra insurance.

Fortunately, they're both healing well, spirits intact, and thankfully pain-free.

Have a great day!

Steffen.

"I've been blamed for code I've never even seen.1 "

“All I did was format the entire repo one long time ago and now I'm getting blamed for everything...”2

While Git is a powerful tool, its literal nature often leads to some unintended consequences. Here's why and how to stop these things from happening to you.

POV: You've chased a hard-to-catch bug for hours only to find the offender in a cryptic code block. Who wrote this? Why? When was the bug introduced? Git has just the right tool for this situation: git blame!

Blame is the tool that tells you who changed any part of a file. It is a great way to understand why something was changed in a piece of code.

Whitespace Commits: The Silent History Killers

Eager to get to the bottom of this, you look up who's to blame for that fishy code line. To your surprise, the commit message says "Fixed indentation," and the author is... yourself!

Reformatting makes it hard to find the "real" author behind a code line. Even if all you did was replace some tabs with spaces, change the indentation level of a code block, or move the braces to a separate line, as far as Git is concerned, the original author is lost to time. You now own the blame for this because you were the last person who touched it.

Whenever we make a formatting commit, we lose critical context for why code exists, making it much harder to fix or improve. The code's original intent is gradually buried under a flood of cosmetic changes.

Squash Merges: Erasing Authorship

Many teams prioritize maintaining a clean and linear Git history. Unfortunately, history-altering workflows can wreak havoc on git blame. A striking case is squash merging, where you combine all the changes in a branch into a single commit before merging it into a target branch. In this scenario, the last commit touching each line might just be the big merge commit, not the original contributor.

“git blame shows ME as the perpetrator of every changed line in every changed file in the squashed commit. (...) This ruins git blame!”3

I've previously written about developers' tendency to overvalue a clean looking commit-graph. As one redditor vividly puts it:

“[squashing] makes it more difficult to pinpoint why something was changed when everything is just 1 mega commit in the git blame. (...) it serves the same exact purpose as having separate functions/methods in code versus shoving everything into main; each commit (function) is for a specific unit of work.”4

Squashing does look clean and neat, and some projects genuinely need to do it, but it often comes at the cost of losing the "story" behind why changes were made. This lost context can be critical when tracking down bugs or understanding the evolution of a complex piece of code.

Refactoring's Dark Side: When Moving Code Breaks Blame

You finally decide to clean up a messy codebase: renaming variables, splitting functions into smaller files, and fixing inconsistent naming. But git blame isn't impressed.

After moving a critical function to a new file, blame points squarely at your refactor commit. The original author? Lost in the shuffle.

These disruptions aren't just technical; they affect team behavior, too.

The Blame Preservation Paradox: Why Teams Avoid Clean Code

Here's the tragic irony: git blame's flaws punish developers for doing the right thing.

A developer shared their team's unspoken rule:

"No, don't fix the formatting there—everything will assign blame to you!5"

The result? "Way too many unreadable files accumulated over time."

This fear isn't theoretical:

• Developers disable IDE auto-formatting to avoid "stealing" blame.

• Teams delay code cleanup for years, fearing history pollution.

• Engineers waste hours manually tracing changes because they can't trust blame.

As one engineer put it:

"We want clean code… but not at the cost of losing our history. So we live with the mess."

Having an accurate history isn't about assigning blame to developers6; it's about preserving context to facilitate debugging and collaboration. Knowing why something was done and the intention behind the change can be hugely valuable for the one doing the debugging.

So why does this keep happening? The root cause lies in how Git tracks changes at the most basic level...

Why Git Blame Can't "Just Work"

Git's core philosophy is simple: track changes, not meaning. It doesn't matter if you're fixing a critical bug or adding a comma; every edit is a "change" to be recorded.

This makes Git brilliantly flexible… and infuriatingly literal.

But this isn't laziness; it's by design. Git was built to version files, not parse logic. It can’t tell a cosmetic change from a semantic one. When you refactor code, Git sees:

- Deletions: These lines vanished from the file.

- Additions: These new lines appeared in the file.

Git has no idea you moved code. Similarly, when you reformat, Git only sees lines rewritten, not preserved. Imagine rewriting a sentence in a book: Git only sees that a new sentence was written, not that it's the same idea moved to a new chapter.

The takeaway? Git blame isn't broken; it's just blind to context. But with a few tricks, we can give it glasses.

Fixing Git Blame Without Sacrificing Clean Code

If Git blame can't "just work," does that mean we're stuck with unreliable history?

Not at all. Here's how to bend Git's rules to your advantage:

Ignore the Noise

• Use git blame -w: This skips whitespace changes to avoid blaming cosmetic fixes.

• Make blame skip certain commits. Here’s how:

1. Create an ignore list for the noisy commits (like reformatting).

# .git-blame-ignore-revs
123abc  # Commit: "Style: run Prettier"
456def  # Commit: "Fix whitespace"

2. Make your repo read that ignore file by updating your git configuration:

   git config blame.ignoreRevsFile .git-blame-ignore-revs

Track changes

• Use git blame -M: This parameter attempts to detect lines that moved within the same file

• Use git blame -C: The C parameter tells Git to search and attempt to detect lines copied or moved from other files.

• Combine them all: git blame -w -M -C <filename> , and set up an alias for it.

• Alternatively: Pickaxe searching! git log -S <search string> lets you search for any string and find where it was introduced, removed or moved. Some developers prefer pickaxing over blame. (The term pickaxe comes from digging around in the repo, looking for the search term.)

Commit Smarter

• Isolate formatting changes: Run auto-formatters in dedicated commits (e.g., [style] Run Prettier). Tag commits for easy ignoring. You could even automate your CI system to automatically add commits marked with [style] to the ignore-revs file.

• Never mix refactors with fixes: A golden rule: "One PR for formatting or cleanup, another for logic changes." I know, it can be hard to resist, but it’s worth it.

Educate Your Team

• Update your onboarding docs and make everyone use the ignore revs file.

• Normalize using git blame -w, by setting up aliases or configuring IDEs.

The Bigger Picture: Why This Battle Matters

Accurate blame isn't about finger-pointing. It's about context. When a code line's history is preserved, you can:

• Understand why code was written (via commit messages).

• Ask the original author questions during debugging.

• Avoid reintroducing old bugs.

As one developer pleaded:

"I just want git blame to work."

With these fixes, it finally can.

Clean Code and Clean History: No Compromises

Git blame's flaws have forced developers into a false choice: clean code or accurate history. But it doesn't have to be this way.

By isolating noise, leveraging ignore files, and adopting smarter workflows, you can:

• Reformat fearlessly (no more unreadable code!).

• Refactor aggressively (move code without breaking blame).

• Blame confidently (find the real author in seconds).

So go ahead: embrace the auto formatter and let your code's true history shine through!

You know those features that haunt the back of your mind? The ones you want to build but can't bring yourself to start on. For me, a big one was visualizing Git's branch relationships. I'd scribbled ideas in Obsidian for years—algorithm sketches, dead ends, "what ifs." Every time I opened that note, it whispered: Too hard. Too messy. Maybe someday.

Then, last Monday happened.

Rain tapped the window. Kids off to school. Coffee in hand. I had planned to tweak Chinese translations on another one of my apps—mundane, safe work. But out of nowhere, clarity struck: Today's the day.

I flung open Mission Control, spawned a pristine desktop (no clutter! pure possibility!), and summoned Xcode, Cursor, ChatGPT, and that infamous Obsidian note. For hours, I wrestled with half-baked AI-generated algorithms. They'd pass one unit test, then slowly crumble into spaghetti as AI tried to cheat, inserting hard-coded fixes. By afternoon, I'd scrapped it all.

For hours, I'd leaned on AI to brute-force solutions—and while it helped untangle smaller knots, this problem demanded something different. Not complexity, but simplicity. Not code, but clarity.

Then, in a moment of quiet defiance, I pared everything back. Deleted the noise. Wrote just 100 lines by hand, iterating on the AI's scaffolding.

And there it was: a grid of green—tests passing. No fanfare. No fireworks. Just steady, quiet proof that years of notes and one stubborn Monday could add up to something right.

Introducing the Update Born From That Monday

New:

✅ Git Graph Lines

Those sleek branch visualizations I'd obsessed over? They're here. Trace commit relationships effortlessly—no more mental mapmaking.

✅ Git References

See "main," "origin/feat/new-thing," or tags like "v2.0" right in your commit history. Context, instantly.

Improved:

✨ Redesigned Commit List

Cleaner, faster, resizable. Shape it to your workflow.

✨ Enhanced Commit View

• Gravatar author pics (put faces to commits)

• Smarter rename highlights, no-noise deletions

• Expandable messages, change counts, intuitive indicators

This update isn't just features—it's a testament to small steps. For years, I added notes to that Obsidian doc, unsure if they'd ever matter. Then, one Monday, they did.

To anyone nurturing their own "someday" project:

Keep the faith. Clear the clutter. And when the spark lands? Follow it.

Try the new Gitonium. Here's to quiet persistence.🥂

P.S. To the Obsidian note that haunted me for years: rest easy. You've earned your retirement.

• Gitonium Black Friday/Cyber Monday Sale

• Have You Been Having a Lot of Headaches Lately?

Did you ever struggle with interpreting a cluttered diff?

When you've made a code change that causes indenting to change over a large part of the file, it takes some effort to understand the diff. One of the newest features I've added to Gitonium lately is a keyboard shortcut to toggle the rendering of white space in diffs on and off. If you ignore all the changes to tabs and spaces, the diff becomes much simpler. See this video:

Gitonium is my Git app, and it is on a Black Friday & Cyber Monday Special: ​Get Gitonium​ at 50% off in the Mac App Store! The offer ends on Tuesday, December 3rd.

Have you been having a lot of headaches lately?

I've had migraines my whole life. My mom has them, and so does my grandmother. Mine aren't as debilitating as others can be, but they knock me out well enough anyway. A recurring theme at home is me having another migraine and my wife saying: "It feels like you've been having a lot of them lately?" followed by me shrugging and replying, "Yeah, maybe.." but I can't remember.

I decided to start keeping track, so I downloaded a headache tracker app to help me with that. I didn't like how it was designed, and I kept forgetting to reopen the app after my attacks had ended to tell it to stop tracking. I'd open the app because I got a headache, and it would say, "Hello, you've been having a migraine for 25 days!", still counting.

Then I would try to start logging a new attack, and it would require me to fill out a ton of details:

• Which of these 19 parts of your head does it hurt in?

• Is it pounding pain, throbbing pain, or pulsating pain?

It went on and on. I'd be like, STOP, I DON'T KNOW, MY HEAD HURTS! I can't be going through a survey on my phone during a migraine attack. I don't even want to look at the phone.

I decided to make my own headache tracker app, Headaches. It integrates with Siri, so I can tell Siri my head hurts and leave it at that. If I want to add symptoms, I can add them later when I feel better. I also integrated it with Live Activities and Apple Watch, so I can tell it's tracking right on the home screen, in Dynamic Island, or on my arm. It supports App Intents and Shortcuts, so you can create automations, like having it dim your lights when an attack starts.

Headaches is on the iOS App Store now, and it's free! If you've been having a lot of headaches lately, try this app. It won't bother you, I promise. If you like it and want to help me, leave a positive review. Reviews really help.❤️

Have a great day!

-Steffen

Chasing Ghosts

I recently encountered a crash in one of my apps that I couldn't reproduce—it works perfectly on my machine, as we developers like to say.

Trying to fix bugs without enough context is like searching for a contact lens at a Metallica concert—an exercise in futility. Before shelving the investigation, I documented the issue as a bug ticket for my future self, including as much information as possible. This frustrating experience got me thinking about how we handle defects and the tools we use to manage them.

Last night, I saw this tweet mentioning an ad for Atlassian, saying, "Happy teams start with Jira," and it made me smile. I've never liked Jira. The tweet made me think about this blog, "I F***ing Hate Jira" dot com, which is both hilarious and sad at the same time.

How did Jira become so bad?

Why Developers Hate Jira (and Other Issue Trackers)

Issue trackers, by nature, focus on problems—bugs, tasks we haven't completed yet, that aren't good enough, or that aren't working at all. When you close a task, another one pops up.

Sometimes, seeing a bug in an app from a major player like Apple feels oddly reassuring. It reminds me that we are all human and everyone can make mistakes. It makes my own struggles feel less daunting.

Working on such a never-ending backlog understandably leads to a constant feeling of inadequacy. Even when you're competently closing issues, there's always one more waiting for you.

I worked on a successful and popular app for many years but struggled to appreciate it. My day began and ended with the task list in Jira. The constant stream of problems, bugs, and unresolved issues overshadowed my achievements. It was hard to see past the flaws—I saw nothing but bugs, bugs, bugs.

I've come to realize that many developers experience this tunnel vision. Are we all just ticket-closing automatons? When we fixate solely on problems, we lose sight of all the good things we've made. This constant problem-focused mindset keeps us from appreciating our achievements and hinders our ability to see the broader impact of our efforts. Eventually, this can contribute to burnout, as the joy and satisfaction in our work fade away.

It would help if we learned to celebrate our wins more. Tools like Jira should do a much better job of highlighting what we've achieved. Did you ever see an issue tracker system say, "Wow, look how much you've accomplished!"? It's more like, "Okay, you finished that? Here's the next problem."

Allegedly, Grace Hopper once said, "A bug report's title is the first impression. Make it count." This Redditor has the right idea:

Finding the Positives: The Role of a Good Ticket

If you can understand the problem well, you won't have to always feel like you're in firefighter mode. Sometimes, the ticket says something like "Feature X isn't working," but it doesn't tell you how it's not working, why it's a problem, or what to do to reproduce it. You end up spending more time investigating than actually solving the problem.

The quality of the ticket you're working on can be the difference between having a productive day or feeling like you're expected to solve Rubik's cubes in the dark.

What Makes a Good Ticket?

• A clear title: It should grab attention without the need for clickbait.

• Steps to reproduce: Detail everything you did that led up to the problem so that someone can follow the steps and get there.

• Expected behavior: What did you expect to happen after performing the last step?

• Actual behavior: What happened instead?

• Context: Does it only happen at a special time or place or when working with particular content? Did anything else happen at the same time?

• Environment: What device do you use, and what platform? What are your language and locale settings? What was the version of the software with the problem? Do you have a username? Do you have screenshots, recordings, or logs of it happening?

• No assumptions: Don't jump ahead of yourself by assuming or suggesting what you think the problem might be. You may be wrong, and you may send the person trying to fix it on a wild goose chase.

• Remain neutral: Don't frame it negatively, like "it happened again" or "still doesn't work." Explain in detail what happened as best you can, and leave it at that.

"As an X, I Want Y" and Other Ticket Templates

Developers often mock the User Story template because of its rigid language and roots in Agile methodology. The User Story helps communicate business value between stakeholders. It also helps in prioritization and explaining why a new feature is necessary. Stories aren't made for bugs or technical tasks, but you'll often see the format creep into all kinds of tickets by accident.

• As a user, I want the app to work properly, so I can use it.

• As a database admin, I want to increase the query performance by indexing tables, so that the system runs faster.

Using this template for technical tasks can make tickets sound condescending and detached from reality. Many adopt it, thinking it's standard procedure.

A third type of ticket is the Spike. Use this type when the task is to investigate something. It differs from the bug type because it doesn't have steps or expected behavior. It should have a list of questions that need answering and a timebox field where we specify how much time we're willing to spend on this investigation.

Other reasons to loathe Jira

Of course, there are also many other technical and user experience reasons to despise Jira, but you usually don't have a choice if you're a Jira user. In that case, venting your frustrations might be the best thing you can do.

Make Jira Work for You, Not Against You

In the end, a ticket can either make or break your day. By investing time and effort into writing clear, complete tickets, you can streamline your work and improve your team's day. Next time you're logging an issue or a new feature, remember the power of a well-crafted ticket—it can turn frustration into productivity and help create a more positive work environment. Let's take control of our tools and make them work for us, not against us. If we all commit to this, perhaps our teams could stay happy, like in that "Happy Teams" ad.

Subscribe now

Meet the Source Code Analyzer

When I wrote my Ollama post a week ago, I promised to polish up and give away my File Analyzer Quick Action for free. We developers like to think of ourselves as intelligent, capable individuals. Estimation should be easy, right?

In software development, there's something called the ninety-ninety rule. It refers to the tendency for projects to become more complex and time-consuming as they near completion. The initial phase goes quickly, but the final stages—such as optimizing, debugging, and handling edge cases—often take much longer than anticipated, sometimes doubling the expected effort.

I'm proud to say I am no exception to this rule, but be that as it may. Perhaps I should write about estimation next? In any case, I've finished the Analyzer!

You Feel Exhausted by Tickets

You don't understand the code you're assigned to fix. Coding under stress is a real passion killer. Your entire days are meetings scattered throughout, and you have more tickets to close.

Programming is a highly creative skill, and you know how good it feels to be productive, but you're left scrambling for time to get the work done.

What if you could drop in quickly and resolve the issue? What if you could understand what this code does without reading through every detail? You could skip right to the deep thinking, spending that mental bandwidth on actual problem-solving⏤today.

Coding tickets really drags after a while, but it can also be deeply satisfying when you have the right tools.

Meet my File Analyzer Quick Action. Just right-click any file and quickly know what it does, how it's structured, who created it, why, who else contributed, and what changes were made.

Close those tickets calmly, efficiently, and with peace of mind.

You can be the tech guru people count on during critical times to parachute in and save them.

Download my Quick Action now for free, and start mastering your workload, learning, and growing in no time.

Have a great day!

-Steffen

Gitonium Update: Save on API Costs with Local LLMs

After writing last week about the AI dilemma developers face, I decided to act on a feature request that's been sitting in Gitonium's wishlist for a while—one that could save users real money.

Introducing Ollama Support for Automatic Commit Messages

Users have been asking for Ollama support to reduce API costs when generating automatic commit messages. I tested this earlier in the summer, but wasn't satisfied with how long it took my Mac to generate a commit message. So, I put it on hold.

Recently, after writing my Apple Intelligence post, I revisited the idea with a different approach. Instead of using a big model like Llama, which felt like overkill, I tested Google's smallest Gemma 2 model. It worked well and ran relatively fast on my M1 Mac.

New Feature in Gitonium: Choose Your AI Provider

I’ve added the option to select your AI provider in Gitonium’s Settings, allowing you to choose between using remote APIs or local models.

Benefits of Using Local LLMs:

• Privacy: None of your source code is sent to a third party (like OpenAI). Everything stays private on your machine.

• Offline Capability: You can generate commit messages even when you're offline.

The new update was approved by Apple and is now available for download on the App Store.

Free Tool for Newsletter Subscribers: File Analyzer Quick Action

Speaking of productivity tools, I received some questions about the file analyzer script I mentioned in my Apple Intelligence post. So, I thought—why not clean it up and release it?

Struggling with Legacy Code?

You're fixing code you barely understand, swamped with meetings, and rushing to close tickets. Coding should be creative, but stress is draining your energy.

Here’s How the File Analyzer Helps:

• Quickly understand any code—like you wrote it yourself.

• Skip the guesswork and get right to solving real problems.

File Analyzer Quick Action Features:

• Right-click any file to receive an instant breakdown:

  • What the file does

  • Its structure

  • Authorship and history

  • Recent changes

Note: The File Analyzer isn't available quite yet. I'm still polishing it up to make sure it's as useful as possible. But as a subscriber, you’ll be the first to receive it once it's ready!

Subscribe now

Want to make your life easier? Subscribe to my newsletter, and you'll be the first to get the File Analyzer Quick Action for free—so you can start streamlining your work as soon as it’s released!

As Apple prepares to launch iOS 18 and macOS 15 Sequoia next week, excitement is building around the new Apple Intelligence features. With promises of a smarter Siri and AI-enhanced system apps with summarization and intelligence capabilities, the future looks bright for users. However, as a developer, I can't help but feel let down. Despite the advancements, there's a glaring omission that could have unlocked a ton of innovation: the absence of a built-in generative language model integrated into the OS. This missing piece could have empowered developers to create a new wave of innovative apps and solutions.

So, what exactly is Apple Intelligence?

• A more personal Siri that can do more for you, like searching and performing actions across apps or prioritizing and summarizing your notifications. As developers, with some effort, we can let Siri reach into and integrate with our apps.

• Writing tools that let users rewrite, adjust the tone, or correct their grammar. These tools will appear in most apps that let you edit text.

• Generate new emojis on the fly or create images using the Image Playground API.

The Glaring Omission: No On-Device LLM for Developers

So, basically, we can now generate images in our apps, but there's no way to generate and process text. If Apple offered something like this as an API, the potential for innovations and creative ideas would have exploded. It could have triggered a new wave of innovative apps and a lot of fresh enthusiasm around their platforms.

The AI Dilemma for Developers

When you want to make an AI-powered app, you face a dilemma.

You could rely on cloud-based LLMs like OpenAI or Claude or use a local model. Both have considerable downsides.

Cloud-Based LLMs: Cost and Security Issues

If you choose the cloud-based method, the most significant factor is the cost. These API vendors charge you based on use, and if your app gets popular, it could cost you. Deciding what to do with these costs is a challenge because you basically have two options:

• Absorb the API costs and hope that the price of your product will cover all its usage.

• Pass the cost over to the user, either by selling in-app purchases based on usage or having the user provide their own API key, which they pay for.

The final challenge is security: Your app could be hacked, your API keys stolen, and you could wake up to an unexpected bill from your provider.

On-Device Models: Licensing and Size Constraints

Should you choose the on-device model approach, you have other problems. You could use an open-source model and bundle it with your app, but this brings its own concerns. Firstly, is the model licensed in such a way that you are allowed to distribute it commercially? If it is, we come to the second problem: these models are huge -- several gigabytes huge. If you decide to include one of these models in your app, then not only will your app take a long time to download, but it will take up a ton of space on your user's devices. If everyone did this, we would all quickly run out of drive space, and every app would need to load its own model, gobbling up all your device's memory, too.

Exploring Alternatives: The Case of Ollama

There is a third option, an app called Ollama. It runs in the background on your machine and lets you download and run models locally. It's basically a locally-running AI API. I've been using it to write lots of useful scripts that help me day by day. I have, for example, one small script that runs on my Mac that looks through the news and pings me about stuff it thinks I'm interested in. Another script I've made analyzes and summarizes files and their git history. It has come in handy when looking for regressions in files I wasn't familiar with or when I wanted to get up to speed on what some code does.

The downside to building apps with Ollama appears when you want to distribute them. You must require the user to install Ollama first, or your app won't work. For best results, they'll likely also need to install the exact model you have been tweaking your prompts to work with, and they'll need to use the terminal. This also means it isn't feasible if you want to distribute your apps on the App Store.

Final Thoughts

To fix all these problems, Apple should have included a basic local system-reachable language model in the OS that any app could hook into and use. Having something like that would make all these worries go away. It would eliminate the cost and licensing barriers, reduce app sizes, and open the floodgates for a ton of innovative native AI-powered apps. Doing this wouldn't just benefit developers—it would enrich the entire Apple ecosystem with a wealth of new and advanced functionalities.

Over the last few years, many developers have felt increasingly alienated by Apple. By overlooking this, Apple has missed a significant opportunity to empower its developer community.

• Welcome to My Echo Chamber

• Gitonium gets an update

Welcome to My Echo Chamber

A while back, I felt tired of Twitter because it's full of indie hacker influencers either bragging about their MRR or spewing advice on getting thousands of followers like they have (buy my course!).

Hoping to find a more meaningful way to keep myself up to date, I joined Substack and began subscribing to a bunch of newsletters that popped up and seemed interesting.

Last night, I found myself reading a newsletter about how You, too, can generate eight income streams when it clicked for me. Why am I spending time reading this? As I reflected on this last night, I realized I'd recreated the same environment that I had on Twitter.

Half of the newsletters are from people writing about how to succeed on Substack or how you, too, can have thousands of followers (grind!) and live life on your terms, et cetera ad infinitum. Am I just hooked on success porn? Please gloss over all complexities and failures along the way and seduce me with this easy six-step success blueprint.

Are we predisposed to seek out what we want to hear? Why did I do this to myself? More importantly, how can we break out of this cycle?

Gitonium Gets an Update

As you may know, I make a git client for macOS. Its primary purpose is to make merges as easy as possible. Many users have been asking me to add support for pushing and pulling, and it's taken me a while because I was used to mostly doing that from the command line. It's a feature I've been wanting to make, and now that I have it, I'm not sure how I managed without it. It sounds like such a simple thing to add to an app, but there are many corner cases and things to consider.

This spring, I spent much time learning about the actual business parts of running a business, so it felt comforting to make things again. Before submitting this version to Apple, I took the opportunity to update Gitonium's icon. The old one was a Launched-inspired one that I thought would be temporary, but it stuck.

Designing a new version was a fun process. While still blue, this new one stands out better next to all the other blue icons on my Mac.

The new version 2024.7.1 is rolling out ​on the Mac App Store​ right now!

I hope you're all having a fantastic summer! I just returned from walking through a forest inside an old log flume to reach a secret swimming spot. Never stop going on adventures!

Have a great day!

-Steffen

• Pay Yourself First

• Talking to My Therapist

Pay Yourself First

I was a software engineer working for one of the big tech companies. I spent my time sitting in endless meetings scattered throughout the day. I had frequent headaches and neck pain. 

Pay Yourself First is a strategy in personal finance where you set aside a portion for savings before paying your bills, forcing yourself to adjust your spending accordingly. I have begun to apply the same concept in life, prioritizing my health and well-being above other commitments. 

When I worked the corporate job, I had it all backward. Work came first, and then the rest of my life, sandwiched between deadlines. When there was a big launch, the first thing that had to go was exercise, quickly followed by eating well and spending time with loved ones. A sure sign you've entered burnout season is when PMs start calling the team fam. 

Subscribe now

On top of my headaches and neck pain, I injured my knee, and for a while, I could barely walk. If you've ever been sick or injured, you'll know that nothing matters more to you than getting well. Why don't we take better care of ourselves? Instead, we work our asses off, thinking that it'll all be worth it one day when we retire.1 At work, they offered free mindfulness lessons; at one point, I recall they sent emails announcing this month was Wellness Month. The only problem was I was too overwhelmed to get through all my emails and notifications, much less spend my evenings attending online seminars (meetings!) about burnout risk.

I was burnt out and had reached a point where the only thing I could do to remain sane was quit. I had to decide to put myself first. Today, 7 months later, it's been one of the best decisions I can recall making. Many people were shocked when I said I quit my job and looked terrified by the mere thought of spending some savings. (Either that or they couldn't grasp that I had savings.) On that note, if you're not setting aside some money every month, you should seriously reconsider your priorities because not having any savings is how you ensure you'll be trapped in the hamster wheel forever.

You can take some time off even if you don't quit your job like I did. I know people who have negotiated paid—or partly paid—sabbaticals with their employers. When I resigned, I, too, was offered a sabbatical, but I was too burnt out at the time to even consider that offer. I needed a clean break. Thus far, I've treated my time off much like a sabbatical. Historically, sabbaticals were a period off for study, travel, rest, and pursuing personal interests, and it was something university professors would do occasionally to stay relevant. If quitting feels like a drastic move, consider discussing sabbatical options with your employer, highlighting how it can benefit you and the company by preventing burnout and renewing productivity.

A lot of people online are advocating taking time off. In his newsletter, writes2:

I suspect that we'll look back on continuous employment throughout adulthood as a temporary phenomenon of industrialization. In a world where more work is creative, abstract, and specialized, I think the "break" from work will become far more common (if not expected).

When you no longer have to squeeze your life into a schedule designed for factory assembly lines at the Industrial Revolution, many new opportunities open up. Like exercising during the day and working when you feel the most creative.

What I do now is prioritize my health and wellness. I won't be one of those older people who have trouble getting out of the chair—I'm making sure I won't be. The first thing I do in the morning, before waking the kids or brewing coffee, is put on my workout clothes. When the kids leave for school, I go to the gym. Why wouldn't I? I'm already wearing gym clothes!

When you work out every day, you don't need to work as hard as those who do it only once or twice. The gym is full of busy people trying to cram as much exercise as possible into the least amount of time. They'll be running between machines, trying to exercise multiple muscle groups simultaneously so they don't have to sit still for a minute between reps.

The need to save time and be more productive is so deeply ingrained in us that we no longer question it. We frown upon leisure time and feel bad for doing nothing.

The ancient Greeks had the right idea. The Greek word for leisure, σχολή (scholē), is actually the basis for the English word "school." To the Greeks, leisure wasn't just about relaxation but also about engaging in activities that improved the mind and the soul. Being free from 9-5 has been an eye-opener, and I'm now looking forward to Mondays instead of dreading them.

Just like how you quickly stop noticing when you Pay Yourself First that the sum is gone from your budget, I also no longer notice the effort of working out. My neck pain and headaches are a thing of the past, and I feel stronger, more creative, and more focused than ever.

You should consider a sabbatical.

Talking to my therapist

Exercise might not only make your stiff neck and your mouse arm pains go away—There is substantial research34 in support of the theory that physical exercise leads to reduced symptoms of depression and anxiety, improved cognitive function, stress reduction, and generally a sharper, more creative mind.

Memes say it so much better, though:

Have a great day!

-Steffen

I’m in charge of an app, and it’s stressing me out. How do I stop panicking?

More responsibility means more stress.

I worked as an iOS tech lead for over a decade, and I've experienced my fair share of this. I kept checking my email, Twitter, app reviews, customer service reports, and crash statistics, thinking everything was about to come crashing down.

I can come up with a very long list of small things you could do to mitigate the problem. Still, the main thing - the most important thing you have to learn when you are in this position, is a seemingly simple idea, and you might not like what I'm about to say because it requires a mind shift. It is a mental effort; if you don't learn to do this, you're on the path to a total meltdown.

Subscribe now

You have to accept that shit will happen. AWS will go down. Apple drops an update that makes your app crash. Facebook logins will stop working, or OpenAI will go down. It might be beyond your control, and your users will think it is your fault. Maybe even your boss at first. Hell, it might even be your fault, too. It doesn't matter. 

Take the stoic approach and let go of it all. You can't control these things. What matters is how you react. The most important thing that helped me was to tell myself that it's only an app. This whole incident is an inconvenience at worst. It's not like I'm making pacemakers. I'll fix it, or whatever was down will come back up, and everyone will forget it soon after. 

These things are unpleasant, but do not allow them to impact you before they happen.

Protect your mental health. It is more important than anything else.

I had planned to end this post on this quote:

Worrying does not take away tomorrow's troubles, it takes away today's peace.

But then as I was finishing writing this, I opened Twitter and the perfect one rolled right into my feed:

Have a great day!

• I Should Be Leading a Team by Now

• On the Subject of Happiness

I Should Be Leading a Team by Now

You're in bed at night, thinking about your life and job.

I feel stuck, like I've stagnated. With my years of experience, I should have come further by now. I've only ever been an Individual Contributor, fixing bugs and building new features. I've never led a team.

​Why am I not successful enough?

Be careful what you wish for.

​
I followed the Default Path—the standard path society tells you is the road to success. I was a Developer, then a Senior Developer, then a Tech Lead, then a Team Lead. One night, I was lying in bed thinking about my life and job, and I realized I didn't like it at all. I did not look forward to getting up tomorrow and getting to work. In fact, I dreaded it. Why, though?

As long as you're not homeless and your fundamental human needs are covered, your baseline happiness will stay the same, even when you get a raise, a bonus, or a fancy title. You might get a brief high, but then you wake up again, and your bar for what's normal has reset itself, and you're just as happy or unhappy as before. You're on the Hedonic Treadmill, and as soon as you accomplish something, your mind defines this as the new norm, and you start wanting more.

You might say you need that raise. Why though?

Do you really need all that stuff you are buying, or are you just buying it because that's what everyone does?

Too many people spend money they don’t have, to buy things they don't want, to impress people they don't like.

- Will Rogers (ca. 1920)

Optimize for everyday happiness, and forget about prestige.

You're a great developer, and now you want to be a leader, too. When jockeying for that promotion to management, many fail to consider how different that job is. This is an entirely different skill set, and what you'll be doing all day is very different. You'll find yourself in endless meetings. Lots of planning and performance reviews. You'll be in charge of the growth of everyone on your team. You have to cater to the personal needs of all of them and have regular 1:1s all the time. You'll learn about Performance Management—how to coerce the most out of your subordinates. You may even have to stack rank everyone on your team, having to let the ones you ranked lowest know that they are Low Performers.

Do you like to make things?

I once overheard my manager say something like, "Wow! I'm getting so much work done today! I've had 11 meetings!"

Did you ever feel that being in meetings is how you get things done?

There are two types of schedule, which I'll call the manager's schedule and the maker's schedule. The manager's schedule is for bosses. It's embodied in the traditional appointment book, with each day cut into one hour intervals.
​​
Most powerful people are on the manager's schedule. It's the schedule of command. But there's another way of using time that's common among people who make things, like programmers and writers. They generally prefer to use time in units of half a day at least. You can't write or program well in units of an hour. That's barely enough time to get started.
​
When you're operating on the maker's schedule, meetings are a disaster. A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in.
​

Excerpt from Maker's Schedule, Manager's Schedule, by Paul Graham (2009)

There is a whole field of education around becoming a manager, entirely skipping the part where you work as a developer for years first. Ask yourself why you didn't do that in the first place.

I've known highly talented developers who did not enjoy being in a management role and went back to being Individual Contributors. I am one.

So what should I do then?

If you work in Big Tech, there are senior ​IC​ paths (architect/staff/principal engineer) that are generally much more pleasant roles for those of us who enjoy making stuff.

Show initiative. Demonstrate why you are valuable. Talk to your manager about what you want, and see if you can join a mentor program or pitch a project you could own. If your company can't offer a clear path onward, consider switching somewhere that does.

Or, for an alternative path to self-growth, join a small startup or make extra income from a side project.

​

Just don't become a manager.

On the Subject of Happiness

When you know that you'll be writing about happiness, you'll think about it and subconsciously spot things and connections that relate to it everywhere

While Hedonic adaptation is a real thing, you can still choose to be happy. You'll see this theme a lot in Stoic philosophy. I particularly like this quote from Boethius, written while he was in prison awaiting execution:

Nothing is miserable unless you think it so; and on the other hand, nothing brings happiness unless you are content with it.

- The Consolation of Philosophy (524 AD)

I'll leave you with this wonderful TED talk by Dan Gilbert: The surprising science of happiness:

Have a great day!

-Steffen

P.S. You can reply to this email; it will get to me, and I will read it.

A surefire way to get into trouble with Git is by using rebase. Messing up here is so common that developers who use rebase often say they expect to make a mistake eventually. Before you know it, you're entering a world of pain, and getting out of trouble can prove very complicated.

Last night, I was reading an excellent blog post by Julia Evans called Git Rebase: What Can Go Wrong? In the post, Evans describes some of the most common problems you can encounter when rebasing and how to solve them. Some of these solutions may save you if (or when) you get into trouble.

Common problems include:

• Fixing the same conflict repeatedly is annoying

• Rebasing a lot of commits is hard

• Undoing a rebase is hard

• Force pushing can cause lost work

• Force pushing makes code review harder

• Loosing commit metadata

• More difficult reverts

• Rebasing can break intermediate commits

• Accidentally run git commit --amend instead of git rebase --continue

• splitting commits in an interactive rebase is hard

• rebasing long lived branches can be annoying

• (and more!)

All these pitfalls, and still, we keep rebasing. We keep getting into trouble because many Git beginner guides and HOWTOs frequently introduce rebase as a tool people should use far too early in their Git learning journey.

Another reason is that we care too much about having a neat and linear commit history.

Evans says it, too:

I think the goal of rebase is to have a nice linear commit history, which is something I like.

Rebase is a way to accomplish this, and because of that, developers tend to romanticise rebasing.

Git is built for concurrent and distributed workflows and does not care if history is linear. The bigger your team is, the more complex it becomes to make the commit history linear. Git rebase is a way of rewriting history. Like a time machine for your code base, it can move commits around and change the order of events.

Evans states that the goal of the "What can go wrong?" post isn't to convince anyone that rebase is bad and that you shouldn't use it. It is a potent tool in your tool belt, but as the Peter Parker Principle says, with great power comes great responsibility. Most of us may have seen a movie or two involving time travel, but have you ever seen one where altering the space-time continuum is considered safe?

In Conclusion

My advice to developers is this: unless you're a Git expert, do not rebase. It's not necessary. Far too many developer hours have been lost attempting to avoid "ugly" commit graphs. Having a "clean" commit history is less important than you think.

I'll leave you with this YouTube Short from Prefab, where he explains how to configure your computer to play Highway to the Danger Zone whenever the rebase command is triggered.

Have a great day!

-Steffen

P.S. You can reply to this email; it will get to me, and I will read it.

• 8 App Design Tips for Self-Conscious iOS Developers

• The Productivity Paradox: Letting go of Your Inner Boss

8 App Design Tips for Self-Conscious iOS Developers

How do you build good-looking side projects and indie apps if you don't know anything about design? When it's just you, but you still want your app to look good. For many developers, what designers do feels like magic. Surely, it's not done on the fly as you go, right?

Building apps is hard enough.

Don't worry; here are 8 simple steps that will get you off to a great start:

1. Spend time with the system apps and Apple's other applications. Notice how they function and flow. This understanding is crucial in designing intuitive interfaces.

2. Read the HIG. Apple publishes and maintains its Human Interface Guidelines, packed with great advice, guidance, and best practices for how Apple thinks interfaces should work. The HIG is essential reading for anyone looking to develop on Apple's platforms.

3. Sketch out a UI draft. Don't overthink it. Just draw an ugly napkin sketch. The less realistic, the better. One thing I've done a few times is to print out this handy phone template, which Matthew Stephens, one of the founders of DeviantArt, shared back in the day.

4. Use system components. SwiftUI (and UIKit) provides components for navigation, menus, layout, input, and more. If you find yourself looking for some element that doesn't exist, and you're considering building a new one, then that's a red flag that you're trying to do something too complicated.

5. Use default padding and spacing, and be consistent across views. If your components are spaced differently from one screen to another, your design looks clumsy.

6. Use system fonts, and only use the built-in text styles. Check how your app looks when using a larger text size. Remember that some 20-30% of users use larger-than-standard font sizes.

7. Use SF symbols. Apple provides over 5000 icons and symbols that work seamlessly in all sizes.

8. Colors: use as few as possible, and stick to the system colors like you did with the text styles.

If you follow these steps, you will already be ahead of most other apps. Your app will be functional and fit well on the platform.

​Remember that all those well-designed apps that you're looking up to have been iterated on for a long time.

The Productivity Paradox

I've been thinking a lot lately about how to get into a state of productivity. I have a near-infinite number of things I want to explore and work on; the list is not getting any shorter. Yet, frequently, I catch myself just daydreaming or staring blankly at the world (or the wall). Do you feel guilty when you're not productive? After quitting my job, I don't have a boss anymore, but often, it's like he's still there, telling me to hurry up. I have to keep reminding myself that it's okay to not do anything right now.

​
While trying to be productive, I read this great post by Ayon Bhattacharya called How to beat creative block every time, and I just wanted to quote him here because this speaks to me:

It’s interesting that children rarely seem to have creative block. They don’t expect themselves to produce something spectacular. They’re just playing and having fun.

​To create quality work, you have to restore your sense of play. To restore your sense of play, you have to release expectations and get into the flow of the work.

How do you get into The Flow?

Speaking of The Flow, something else that spoke to me last night was this Tweet by Kyle Lambert about the Focus Blast Radius of meetings. I would sit at my desk between two meetings, staring at the wall, just waiting for the next one to begin.

Finallly let me leave you with this wisdom in tweet form, by Suhail, the founder of Playground AI:

Have a great day!

-Steffen

P.S. You can reply to this email; it will get to me, and I will read it.

• I've Forgotten More Than You'll Ever Know

• Should Solo Developers Use Continuous Integration?

I've forgotten more than you'll ever know

- Unknown

The first thing I do in the morning when I open my Mac is start a new journal entry in Obsidian. I add to it whenever I see, read, or think of something interesting. Obsidian is tremendously powerful. I've been journaling like this since ~2020, and I have a lot of notes in there.

Today, I fell into a rabbit hole again. I was thinking about whether or not I should write down some "purpose" for this newsletter and perhaps even my blog. Who is this for, and who am I serving? Then I remembered Paul Graham's legendary blog post, Keep Your Identity Small, arguing not to. I quickly found the note about this in my Obsidian vault, and inside that note, I had also written down a link to a post by Derek Sivers about The Now Page Movement. In this post, Sivers encourages adding a "/now" page to your blog, where you state what you are into right now. I am trying to remember writing this down, but there it is. Obsidian didn't say when I wrote it, but then I thought - there must be a plugin for this!

A quick search later, and I am installing the Update Time on Edit plugin for Obsidian. After doing so I now have "Created:" and "Updated:" fields in the Front Matter of all my notes! I can tell that this note about Graham's post is from January 2021, and I updated it with the note about the Now Page Movement in September 2021.

Now I need a Now Page!

I have yet to conclude on any purpose or who to serve, but that's rabbit holes for you.

Should solo developers use continuous integration?

You might have heard about Continuous Integration/Delivery in software development. I'm referring to it as just CI, for shortness's sake.

CI is something that teams in companies use to automate their testing and release processes, catch bugs, and ensure they don't depend on single developers to make builds and releases. CI systems can be incredibly complex and expensive, and some software companies have teams dedicated to running and optimizing these systems.

For solo developers, is it worth the overhead?

The short answer is that you don't need this stuff. For indies, solo devs, or someone with a side project, the time saved isn't likely to add up to more than the time it took to do the CI setup. Independent developers usually build and upload a version from their laptop whenever needed, which takes little time.

There is a longer answer, though. Although you don't need it, it can still be advantageous. The first thing I do after creating a new project is set up the CI. Setting up CI is quick and easy these days, and if you've never done it before, I recommend doing so to learn how to do it. It doesn't take so long that it isn't worth the learning experience.

The other day, Apple announced that starting January 2024, your Apple Developer Program membership includes an Xcode Cloud subscription at no additional cost. Every small iOS developer now has a "free" CI system. This is huge news, so make sure you take advantage of it!

The benefits of CI are smaller for individuals than for teams, but they are more than worth it. You'll know that the project works on another machine or for someone else, and it'll tell you if you forgot to check in a file or made a test fail. If you want to develop using a beta version or some other IDE, you can do so on your machine without affecting your ability to release. All you need to do is git push, and it will get built correctly "in the cloud."

Earlier this fall, I wanted to make an update to an app of mine that I hadn't updated in a while. When I attempted to build the project, it spewed numerous errors. What was going on? The app was OK the last time I worked on it!

What had happened was the march of time and progress. While this project sat still, I had an updated Mac and a more recent version of Xcode. The code needed to be updated. Fortunately, I had set up CI on this project, so I could hop in there and try building on multiple older versions of Xcode until I found one that worked. After that, it was just a matter of downloading that working version, fixing all warnings, and updating all dependencies, and I was back in business!

You don't need CI, but for iOS developers in particular, it is now both simple to set up and free, and having it may be more helpful than you think.

-Steffen

P.S. You can reply to this email; it will get to me, and I will read it.

I just wanted to let you know that Gitonium is now available at a 50% discount on the Mac App Store. Get your copy for Black Friday or Cyber Monday. The fine folks at GitKraken called it a must-have tool for developers. 👑

I have some personal news, too. I recently decided to resign as iOS Tech Lead at TIDAL/Block. It has been a 10+ year-long roller coaster ride, but it's time for something different. Can I make it on my own? I don't know yet, but I do know I will have much more time to dedicate to Gitonium from now on.

Thanks for following along!

​

Steffen.

In my previous newsletter, I wrote that I was getting near a point where I could ship this app, except there was always one more remaining feature I wanted to build first. Then I slept on it and decided there wasn't any good reason why I couldn't just submit it. I will keep working on it anyway. Why not put it out in the world?

So on that faithful Thursday night, I said, "screw it," and submitted Gitonium. It didn't take long for it to go into review.

I went to bed that night feeling a mixture of relief and excitement. The following day I was still in review. At lunchtime - still in review. It has been a long time since I submitted a new app to the App Store. And that was only on the iOS app store. It's my first time on the Mac app store, so how long would it take? I told myself this could take a few days even.

​When I went to bed that night, it was still in review. Next morning: same thing. I decided to busy myself working on the next update. I found a crash and eventually tracked it down. It would crash whenever it tried to syntax highlight more than 69 hyphens in a row. I better fix this so that when I get approved, I'll submit this crash fix immediately. This took me a couple of evenings to figure out and fix.

​Each morning and afternoon, I checked if I was still in review, and I was. After being in review for five days, I felt increasingly uneasy. Will I ever go out of review? I began searching for and finding horror stories about developers who submitted their apps to Apple and never got approved. Is there something about my app they don't like or approve of? If so, why won't they tell me? Days passed.

​After 7 days of review, I talked to some friends and filled out Apple's Expedited Review Form, hoping that might get me unstuck. I submitted the expedite request and got a response that my request was granted. I went to bed hopeful. I woke up on the morning of the 8th day and found my app was still in review. Evening came - still in review. A few more days passed. On the 11th day of being in app review, I asked ChatGPT for suggestions for why an app could be stuck in review and got an intriguing response.

Make sure your app fully complies with the guidelines. What guideline could I be bumping up against? I spent an eternity combing through the rules, looking for a possible reason.

In the end, I found two rules that one could interpret in such a way:

- 3.1.1a Apps may not use their own mechanisms to unlock content or functionality, such as license keys

- 2.4.5(vi) Apps may not present a license screen at launch, require license keys, or (...)

I have one feature in Gitonium that needs an API key: the automatic commit messages. It uses openAI's API and artificial intelligence to analyze the code and its changes, which costs money. I want to avoid paying a monthly bill because my users are making commits. For one person, it's cheap - like cents per month, but it could add up if enough people use it. That's why I designed the feature so users can bring their own OpenAI API key. Could Apple want me to make this an in-app purchase? Was that why I'm stuck in review? I'd prefer not to have to do that. Here you buy this app, and immediately you must pay a dollar or whatever to use one of its features. I would be nickel-and-diming people.

A few more days passed, and I was still in review. After 13 days of being in review, I resigned to my fate and began implementing in-app purchases for this. It would be a lot of work for something that feels like a worse user experience.

​On day 14 in review, right before bed, I posted a tweet saying that I'd been in review for two whole weeks, and one person replied that he had been in review for more than 2 months!🙀 (Hi Xavier!👋)

That's terrifying!

I went to bed thinking about in-app purchases and token counting.

The following day, I woke up to this on my phone. OMG, it's approved!🎉 What is happening? Did someone from Apple see my tweet? Is this just randomness? The stochastic world?

I quickly clicked the release button, and now Gitonium is live on the App Store! Wow! I'm relieved I didn't have to go the in-app purchase route.

​That, my friends, is how Gitonium ended up on the App Store. It's a one-time purchase of $39.99, and because it's the Mac App Store, you can use it on as many Macs as you want, forever. You can find it on the App Store here.

​I've since submitted my 69-hyphens-crash fix, which was reviewed and approved in less than two hours!

I use Gitonium daily in my day job, and many more features and improvements are coming soon. Next time I'll talk about some of them.

​Thanks for following along!

​

Steffen.

Have you ever needed to merge a long-living feature into the main repository? You may have been working on a new feature for a long time, and now it's time to integrate it with the Main branch. While you were off coding on your part, someone else may have changed some code in the same places as you, or perhaps they did some refactoring and removed a function that you had modified on your branch.

It could be even worse, too: you're merging branches that other developers on the team have worked on. You have to understand both sides of every conflict to solve this safely. You need to know who changed what, when, and why. Git knows, but it isn't helping. Gitonium makes it easy.

The purpose of Gitonium is to give you complete situational awareness when merging code. You'll step through the merge process, conflict by conflict, in a focused manner. Gitonium shows you the conflicting code and every Commit leading up to it on either side, starting from where the conflicting file diverged, letting you see who changed it, when, and why.​

Gitonium saves you time, so you can merge your code and continue your day. You have more creative things to do, like actually building something. Be done with the administrative busywork and get back to making stuff.

How to test Gitonium

If you haven't already, you can install the latest Gitonium Beta using this TestFlight link: Update: Gitonium is now in the App Store

Please keep suggesting things to improve (reply to this email).

​I feel like I'm getting near the point where I could ship this now.

I'm already using it myself, which was my goal when I started making it. To quote from my first newsletter:

So what's the matter, McFly? If you’re already happily using it, why not just put it in the App Store?

I guess I'm scared to.