This is Day 3 of the 14-day blogging challenge.

My Timelines app has a companion app for Apple Watch, and for a very long time, there has been a bug. Every once in a while, it crawled from the shadows and made itself seen – by making the app unusable for the particular unlucky user.

What exactly did it do? Basically, the list of entries for controlling tracking didn't get displayed. Instead, the user was stuck with this:
Apple Watch app broken

I superficially tried fixing it many times, but I just wasn't able to. The code that fetches the list of entries from the iPhone app is simple. There really wasn't much that could go wrong. I assumed that it's just a bug in the WatchConnectivity framework, and I shrugged it off as such. I decided to just hope that Apple will fix it in the next version of the SDK.

This must be a bug in the framework! –me

It was also very hard to reproduce, which made any debugging efforts really difficult.

But lately, it has been happening more often. And I got a very useful pointer from a user that it tends to always happen after the watch is restarted.

Today was the day that I was finally going to tackle this more seriously and find out what the heck is going on. I sat down in the morning, and.. I didn't feel motivated to do it at all. I wasn't very hopeful that this time I will be successful at solving it.

But I decided to at least take a look at the relevant code. And then I thought "maybe I can add just a few console logs to see if these methods get called and what parameters are passed". And before I knew it, I was hooked. I quickly got into a state where I was excited to dive deep and get to the bottom of it.

One discovery led to another, and I got into a complete flow. I hardly noticed the passing of time. I loved it. (Who knew figuring out bugs could be so fulfilling?)

As it turned out, there were several problems. To my credit, the two key ones were actually bugs in the framework. The callback for the phone becoming reachable wasn't getting called, and I had to work around it by using a repeating timer that kept asking "Is the phone reachable yet? Is the phone reachable yet?". As soon as the answer was yes, I could actually fetch the list of entries.

Long story short, it seems it's finally working reliably now. Yaay! I'm looking forward to shipping this fix to customers along with all the other features of version 1.4 in just a few weeks.

The takeaway

There are three lessons that I want to take away from this:

1) It doesn't matter who's fault it is

Understandably, users don't really care if it's a bug in the framework or a programming error of the developer. They want the app to work.

2) The longer you put it off, the seemingly harder it becomes

In your mind at least, it does. This has been my experience on multiple occasions. I've been aware of this fault in my decision making for quite some time now. There are multiple things that I just keep putting off almost indefinitely. Tracking the expenses was one of them. This had almost become one of them. I really need to try to combat that in the future.

3) Just a few deeply focused hours can do wonders

Working in a deeply focused state makes a huge difference on the output. It matters much more than how many hours you are working. That's why I'm not very concerned about the fact that in a typical week, I don't log nearly as many hours as some of the 'cool kids' - What I care about is how much work I'm getting done, not if my work hours sound impressive or not. What I am concerned about is that I'm not getting nearly as much work done as I'd like, but that's for whole another debate 😅.


A note to tomorrow version of myself: try to make it shorter next time ;). You're not keeping the rules and it's just the third day of the challenge.