February 25th, 2015


Welcome to my new blog!

It’s like my old blog, but with a much lighter appearance and hopefully provides a nicer reading environment. It should also be faster, and much better on mobile. As well as nearly all of my old posts, I’ve added a spiffy new More About Me page with a succinct version of my life story, if you’re interested. I’ve also spruced up the My Apps and Archive pages.

I’ve tried my very best to make sure all the links from my old blog work with this new one, but if you spot anything amiss I’d appreciate you getting in touch with me on Twitter or emailing blog at this domain and letting me know.

I actually ended up going through an interesting journey while putting this together. To make sure that every post was formatted properly in the new engine, I read through every single one of my posts all the way back to 2004 — and let me tell you, ten years ago I was an idiot. I seriously considered removing all the posts I found embarassing, but in the end I decided that the journey is just as important as the destination, so they stayed. The only posts I removed where ones that were nothing but links to now-defunct websites.

Technical Details

My previous blog was generated by Octopress, which is a blogging product built on top of Jekyll. However, Octopress’ main selling point for newbies to this whole thing (i.e., me a few years ago) is also its biggest drawback — it’s a complete blogging platform out-of-the-box. This makes diving in and customising it extremely daunting, rather like being presented with a car, a spanner and being told to replace the clutch plate. I did manage to customise a couple of little things on my old site, but not much.

So, a couple of weeks ago I sat here, new theme in hand, ready to try to put it into Octopress. It was soon apparent that I’d basically have to rip the entire thing apart to fully understand what was going on, and if I was going to do that, why not look at alternatives?

I’d recently tried out another static site compiler called nanoc for another project of mine, and really liked it. Where Octopress provides a fully featured blog out-of-the-box, nanoc provides nothing. The default site is literally a white “Hello World” page with no CSS at all. While this is daunting at first, it’s actually quite liberating — it took me about a week to put this whole thing together from scratch, and I now know every intimate detail about it which makes me really comfortable customising it in any way I need.

How The Site Is Put Together

  • There are three “things” in this entire site:

    1. Posts. These are markdown files.

    2. Pages. These are HTML fragments.

    3. Special items like the RSS feed.

  • Posts are put through a markdown parser (kramdown) then wrapped with the site’s template.

  • Pages are rendered pretty much as-is with nothing special going on other than being wrapped in the template. These include the About, Apps, and Archive pages, as well as the site’s home page.

  • When the template is rendered, pages containing the in_menu tag are placed in the site menu. This allows me to have “hidden” pages (like the 404 page) without any extra work.

  • Binary files (images and the like) live in a submodule to the blog’s source repo. Yes, git isn’t great at binaries (and there’s over 300Mb of them for this site), but it works alright for my needs. These files get copied to the output directory with no processing at all.

I’m really pleased with the results of my work, and it gives me greater control over my presence on the web. Over time, I hope to add more features to the site as I work on my web skills.

February 13th, 2015

Secret Diary of a Side Project: Getting To 1.0

Secret Diary of a Side Project is a series of posts documenting my journey as I take an app from side project to a full-fledged for-pay product. You can find the introduction to this series of posts here.

In this post, I’m going to talk about something that strikes fear into the heart of any programmer: planning. You won’t get to 1.0 without it!

If you’re anything like me, it’s likely that you have some form of issue tracker for your side project, detailing various bugs to be fixed and features to be added. In my instance, that ended up being a sort of rolling affair — I’d fix a bunch of things, see that my issue list was diminishing, then spend a while with the app prodding around until I found more things to add to the tracker. This was a perfectly acceptable approach in the beginning.

However, shortly after I committed to do this full-time, I realised I had no longer-term plan. So, I sat down and decided that I’d try to release 1.0 relatively soon after going full-time, allowing plenty of time to gain feedback from real photographers. You see, I have tons of feature ideas but until photographers tell me what they think, I don’t really have any data to tell me if these ideas are any good. Releasing a 1.0 early allows the app to be shaped by its users, rather than my idea of what I think users want.

This is the result, based on nothing more than a loosey-goosey feeling of the state of the project so far:

Milestone Date
Start collecting beta invites 2015-03-10
First beta release 2015-03-24 → 28
Post-beta questionnaire 2015-04-28
1.0 App Store submit 2015-05-05

Of course, I’ll be amazed if those deadlines stick. Still! It’s great to have something to aim for. I felt much better about myself.

…for a while.

A few days later I looked at those dates and started to feel a bit of dread. That March 10th date is when I really commit to releasing something – it’s when my marketing starts! I had no idea if I’d be able to do it or not. Eventually I realised the problem — the tasks in my issue tracker didn’t connect my project from where it is now to that 1.0 on May 5th.

It’s time to do some serious planning!

Shhh… Don’t Say “Agile”

I have a love-hate relationship with Agile. My first exposure to it was when I started at Spotify in early 2011. The company was very small at the time, and we were using… scrum, I think? I forget. Anyway, as the company grew the thing we were using turned out not to work so well. So, we tried a new thing. Then another new thing. Then the first new thing again but with a slight modification. Eventually, I flat-out stopped caring. “Just tell me how you want me to stick the notes on the wall, and I’ll be fine”, I’d say.

Fast-forward a few years, and a fellow named Jonathan joined the company. He’d written a book on Agile and handed out some copies. I took one with moderate-at-best enthusiasm, which then sat on my desk gathering dust. A few weeks later, he did a talk on a thing he called the “Inception Deck”, a method of planning out your product at its inception stages.

“This is perfect for Cascable!” I thought, and started furiously scribbling notes. After his talk, I told him I thought it was great. “Oh, really? I’m happy you think so — it’s all from my book though.”

At that point, I returned my copy of his book and bought an eBook of it instead, partly because I feel uncomfortable furthering my own app on something my employer paid for, but mainly because I like supporting good work.

I feel really uncomfortable plugging things on this blog — it’s not what it’s for. However, Jonathan’s book has immensely helped me as an independent developer trying to get an app out into the world, and a good deal of this post is inspired by things I learned from it. It’s called The Agile Samurai: How Agile Masters Deliver Great Software, and you can find it here at the Pragmatic Bookshelf.

Step One: Figure Out What You Want To Sell

If you were planning your app from the beginning, you’d start by planning what you want your 1.0 to actually be. A side project is completely the opposite of that — you just create a new project and go, plucking ideas out of your head and going with them.

However, that isn’t sustainable if you want to ship a quality product, no matter how much you claim to “live in the code”. At some point you’re going to have to stop and figure this stuff out, which can be pretty daunting if you’re just chugging along in your code editor.

The “Inception Deck” I spoke about earlier really helped me with this. I won’t go into it in detail — it’s in the book I mentioned above as well as on the author’s blog – but it’s basically a set of small tasks you can do to really help kick a project off in the right direction.

Now, I’m not kicking off a project at all, and some of the items in the Inception Deck are geared a bit towards teams working on one project rather than the lone developer, but still — if some of the tasks help bring clarity to my project, I’m all for it!

Alright, it’s time to jump out of development and pretend I’m doing this properly by doing the planning at the beginning. I cherry-picked the most relevant tasks from the Inception Deck, and here’s what I came up with, more or less copy and pasted from my Evernote document:

The Inception Deck for Cascable 1.0

Why Are We Here?

This task helps establish why this project exists to start with.

The applications that come with WiFi-enabled cameras tend to be pretty terrible. We can do better, and make a WiFi connection an indispensable tool on a camera rather than a toy.

Elevator Pitch

This is a fairly standard thing in the software world these days. Describe the product in 30 seconds.

For photographers who need intelligent access to their camera and photos in the field, Cascable is an iOS app that connects to the camera over WiFi and opens up a world of possibilities. Unlike current apps, Cascable will develop and evolve to become an easy-to-use and indispensable tool for amateur and professional photographers alike.

The Not List

This is one is new to me and was incredibly helpful. Defining what isn’t in scope for 1.0 can be as useful as defining what is.

In Scope for 1.0 — Things that will definitely make it.

  • Remote control of the basics: exposure control, focus and shutter.
  • Useful overlays for the above. Thirds grid, histogram, AE mode, AF info.
  • Calculating exposure settings for ND filters and astrophotography.
  • Saving calculation presets.
  • Viewing photos on the camera in the list.
  • Downloading photos to the device.
  • Viewing downloaded photos fullscreen, deleting downloaded photos.
  • Sharing downloaded photos and opening them in another app.
  • Apple Watch widget for triggering the shutter.

Not In Scope for 1.0 — Things that definitely won’t make it.

  • Cameras that aren’t Canon EOS cameras.
  • Cloud functionality.
  • Automatic downloading.
  • Support for videos in Files mode.

Unresolved — Things I’m not sure about.

  • Second screen mode for AppleTV, etc.
  • Applying Calculations Mode results to the camera.

What Keeps Me Up At Night

This exercise was also new to me. What things should you worry about, and which of those are beyond your control?

  • Not having dedicated QA.
  • Keeping “on the rails” and getting everything done properly and on time.
  • App Store rejection.
  • Canon getting uppity.

The first two of those are things I know can fix myself already. The fear of App Store rejection is pretty much life as normal for iOS development, so there’s no real need to worry about that as long as I’m familiar with Apple’s guidelines and don’t bump into the edges of the (admittedly sometimes vague) rules. That last one is more nuanced, and something I need to get legal advice about. That is where I should concentrate my energy into gaining knowledge.


So, what’s the benefit of writing all this down? Well, I’ve understood what this project is about the whole time, but succinctly describing it to someone else is a bit of a challenge. Not having answers to questions like “Will you support X camera?” or “Can I work with video?” was a bit embarrassing. Now, I can answer “Not at 1.0, no.” with confidence. Sure, I don’t need to answer to anyone else while making my own app, but being able to answer questions to others with confidence does great things for your own internal confidence, too.

Step Two: Fill The Gap Between Now And Then

Alright, so I’ve got an issue tracker full of tasks and a ship date. I also have a general overview of what Cascable 1.0 should be with the Inception Deck. However, I still haven’t brought all this together to form a set of directions to take me from where I currently am on the project to where I want to be for 1.0.

The problem is, as the lone developer of an app, I’m just in too deep. I can’t see the wood for the trees, and various other clichéd sayings about not having a clear view of the whole situation. I came up with all that stuff above completely on my own. How do I know if it’s any good, or just pure garbage?

What I need is an outsider.

Don’t be fooled, she packs a mean punch.

Meet Alana (that’s “Ah-lay-na”, not “Ah-lar-na”), who has agreed to be Cascable’s Product Owner while I get to 1.0. She’s also my wife, so I suppose she’s also the Product Owner of, well, me. She’s agreed to have meetings with me once every two weeks, splitting my journey into Agile-like sprints. I’ll get to explain why I didn’t meet any missed targets and why, which targets I did meet and what targets I plan to meet in the next two weeks.

However, we’re getting ahead of ourselves — my current problem is that even though I have a nice Inception Deck I don’t know exactly what 1.0 should be, never mind how to get to it. Alana also had a concern: “How can I be your Product Owner if I don’t know what the product is?”

It turns out that my problem and her concern can be solved in one step. The reason my issue tracker doesn’t connect between the current state of the project and 1.0 is because I just picked ideas out of my head when I ran out of tickets in my issue tracker. The Inception Deck helps, but it’s still a bit wishy-washy — I need a well thought-out master list of stories to work against. A good way to have Alana know the product? Have her make the list!

Business Time

One Saturday, we sat opposite one another at the dining room table with a pile of Post-It notes, some pens and a camera.

“Alright, “ I said, “You’ve just bought a camera and have realised how crappy the supplied app is. You’re going to hire me to write you an app that enhances your photography experience. I want you to tell me what it should do, and we’ll write each thing down on a note.”

She picked up her camera, prodded at it a bit then said “Erm… I guess it should connect to camera, right?”

Great! Our first story — but this was the very first page, not where the storyline ends. We spent the next hour talking about photography and she made feature suggestions along the way, mainly based on her previous photography experiences. I didn’t make a single contribution to the notes, other than to ask “Why do you want the app to do that?” to make sure that information got written down. Each idea got a note, and after an hour we had a fairly sizeable pile.

After we were done, I quickly added some more notes that contained features I’d already written but she didn’t independently come up with, then started the second half of the exercise:

“Now, I want you to put these all in a line in order of importance to you.”

Again, I didn’t interrupt other than to help when she wasn’t sure. “Should this go higher than Delete photos from the camera or lower?”

This is what we ended up with:

For the first time, I sat back and actually studied the notes. I was floored. In front of me was a complete journey to 1.0 and beyond. Features I hadn’t even thought of were high up the list, and of course they were — they were so stupidly obvious. Conversely, features I’d spent a fair amount of time working on (in particular, a “Night Mode” for the app) were right down towards the bottom, probably past the cutoff point for 1.0, and looking at the list I completely agreed with it being down there. In fact, I couldn’t really argue with the order of the notes at all once I heard the reasoning behind Alana’s chosen position.

I’ve been working on this thing for well over a year and a half now, and two hours with someone with fresh eyes completely changed the project and set it off on the journey to 1.0 with a flying start.

What’s better, every single outstanding bug or feature in my issue tracker fit into one of these Post-It stories perfectly. The app doesn’t handle a camera in pairing mode quite right? Well, that goes in the “Connect to camera” story. Oh, crap — that’s the most important story of them all, I should fix that right away!

Step Three: There’s No Step Three!

This is an absolute lie. Step three is the hardest one of all. Now you have a spiffy plan, you have to execute it.

My project isn’t a “side project” any more. Far from it — it has deadlines, a prioritised story list, and a product owner. Between the start of this post and now, it’s transformed into a fully-fledged software project, and I’m letting it down by only working on it in my spare time. Four weeks from today, however, that’s all going to change!

Next time on Secret Diary of a Side Project, we’ll swing back to some coding and talk about what happens when you ignore my advice and decide to refactor a piece of code that really doesn’t need it.

February 8th, 2015

Stripping Unwanted Architectures From Dynamic Libraries In Xcode

Since iOS 8 was announced, developers have been able to take advantage of the benefits of dynamic libraries for iOS development.

For general development, it’s wonderful to have a single dynamic library for all needed architectures so you can run on all your devices and the iOS Simulator without changing a thing.

In my project and its various extensions, I use Reactive Cocoa and have it in my project as a precompiled dynamic library with i386 and x86_64 slices for the Simulator, and armv7 and arm64 for devices.

However, there’s one drawback to this approach - because they’re linked at runtime, when a dynamic library is compiled separately to the app it ends up in, it’s impossible to tell which architectures will actually be needed. Therefore, Xcode will just copy in the whole thing into your application bundle at compile time. Other than the wasted disk space, there’s no real drawback to this in theory. In practice, however, iTunes Connect doesn’t like us adding unused binary slices:

So, how do we work around this?

  • We could use static libraries instead. However, with multiple targets and extensions in my project, it seems silly to bloat all my executables with copies of the same libraries.

  • We could compile the library from source each time, generating a new dynamic library with only the needed architectures for each build. A couple of things bother me about this - first, it seems wasteful to recompile all this non-changing code all the time, and the second is that I like to keep my dependencies static, and making new builds each time means I’m not necessarily running stable code any more, particularly if I start mucking around in Xcode betas. What if a compiler change causes odd bugs in the library? It’s a very rare thing to happen, but it does happen, and I don’t know the library’s codebase well enough to debug it.

  • If we don’t have the source to start with, well, we’re kinda out of luck.

  • We could figure out how to deal with this at build-time, then never have to think about it again. This sounds more like it!

Those Who Can, Do. Those Who Can’t, Write Shell Scripts

Today, I whipped up a little build-time script to deal with this so I never have to care about it again.

In my project folder:

$ lipo -info Vendor/RAC/ReactiveCocoa.framework/ReactiveCocoa

→ Architectures in the fat file: ReactiveCocoa are:
    i386 x86_64 armv7 arm64

After pushing “build”:

$ lipo -info Cascable.app/Frameworks/ReactiveCocoa.framework/ReactiveCocoa

→ Architectures in the fat file: ReactiveCocoa are:
    armv7 arm64

Without further ado, here’s the script. Add a Run Script step to your build steps, put it after your step to embed frameworks, set it to use /bin/sh and enter the following script:


# This script loops through the frameworks embedded in the application and
# removes unused architectures.
find "$APP_PATH" -name '*.framework' -type d | while read -r FRAMEWORK
    FRAMEWORK_EXECUTABLE_NAME=$(defaults read "$FRAMEWORK/Info.plist" CFBundleExecutable)
    echo "Executable is $FRAMEWORK_EXECUTABLE_PATH"


    for ARCH in $ARCHS
        echo "Extracting $ARCH from $FRAMEWORK_EXECUTABLE_NAME"

    echo "Merging extracted architectures: ${ARCHS}"
    lipo -o "$FRAMEWORK_EXECUTABLE_PATH-merged" -create "${EXTRACTED_ARCHS[@]}"
    rm "${EXTRACTED_ARCHS[@]}"

    echo "Replacing original executable with thinned version"


The script will look through your built application’s Frameworks folder and make sure only the architectures you’re building for are present in each Framework.

Much better! Now I can throw fat dynamic libraries at my project that contain all the architectures I’ll ever need, and my build process will deal with which architectures are appropriate at any given moment.

February 4th, 2015

Secret Diary of a Side Project: Cold, Hard Cash

Secret Diary of a Side Project is a series of posts documenting my journey as I take an app from side project to a full-fledged for-pay product. You can find the introduction to this series of posts here.

Moolah. Cheddar. Bank. Cash. Benjamins. There are so many slang terms for money it’s hard to keep track. It’s not surprising, really — people typically dislike talking about money, and it’s human nature to try and make light of something that’s not even slightly fun. It’s the same reason people make jokes at funerals, I suppose.

Money puts a roof over your head, food on the table and is a required thing to function in modern society (yes, Bitcoin still counts as money - there’s always that one guy, isn’t there?) successfully. A fool and his money are easily parted, the saying goes. Nobody wants to be a fool.

However, if you’re serious about your project you’re going to have to spend money on it at some point. If you don’t, you’re going to damage it in ways you might not be able to see until much later.

It’s very difficult — perhaps even nonsensical — to spend nontrivial amounts of money on something that’s solely a side project. However, now we’re getting serious about this thing it’s time for that to change — something that can still be really difficult to do even though we’ve shifted our perception of this project in other areas. It really doesn’t help that money tends to have a tendency to suck the fun out of things, either. It cuts fun stuff out of holidays, limits the size of your TV, and gets in the way of that Ferrari that should be on your drive. Spending money on software I’m perfectly capable of writing on my own? Where’s the fun in that?

This post is really text-heavy, so please enjoy this photo of the Northern Lights my wife took while you take a breather.

Invest In Yourself

Time to be blunt: Without a bit of money put into it, your project will never be as good as it could be. If you refuse to put money into it at all, you should really stop now, or at least reverse course and keep your project as a side project. It’s a harsh thing for me to say, but I really believe it.

Trust yourself.

If you’re there “in theory” but are still struggling with it, try my patented FREE MONEY technique.

NOTE: I should probably point out that I’m not a financial advisor, and you really shouldn’t listen to me. This will become apparent in the next paragraph, but still — I’m an idiot. Go talk to someone smart when deciding what to do with your own money. Like I said, money is serious business.

You know when you find a bit of money in your coat you completely forgot was there? Your immediate reaction is “Sweet, free money!”, despite the fact that it was your money to begin with and you’re exactly back where you were before you lost it. You can just take that mental effect to an extreme — open a new savings account called “App Fund”, choose a sensible amount of money to put aside and transfer it over. For bonus points, make an automated monthly/weekly transfer in there. Your money hasn’t gone anywhere, it’s still safe and sound.

Then, don’t look at it for a while. Go do other things. A month or two later, when you’ve survived without that money completely without incident, come back to it. Sweet, free money!

Now you’ve followed my terrible advice (or hopefully not) and put some money aside for your project, how can it actually benefit your project?

Hire Someone Better Than You

Universal Rule #1: Time is money [citation needed], particularly if time is constrained. If you can hire someone to do a way better job as you in a fraction of the time, you should seriously consider it.

Me? I’m terrible at designing stuff. I can throw together some lines that look sort of like an arrow, but that’s it.

A few months ago, the core functionality of the app was settling down and it was time to start working on the UI properly, particularly the part of the app that dealt with photos.

My photo view was a simple grid. When you had a camera connected, it showed you the photos on the camera. When you didn’t, it showed only the ones you’d downloaded. Seems simple enough! However, in practice, it was horrible.

On the left, you see some photos you’ve downloaded. Then you switch on your camera and a couple of seconds later the view changes to the one on the right. Where’d my photos go? Well, I can see the speedboat towards the bottom there, but what about the one of the house?

I banged my head against this for a little while before throwing in the towel and taking to Twitter for help:

I got a few replies and picked two of the most interesting-looking designers to take a look at my UI. One of the two I was impressed enough with that I extended his assignment a bit, and plan to use a lot more as this project goes full-time.

Anyway, a stupidly short amount of time later, I had some great mockups that made complete sense, and I felt a bit stupid for not thinking of it before. Still! I’d spent not a crazy amount and come out with a professional designer’s take on my problem, and the walls I was bumping against crumbled away and development picked up again.

It was money well-spent, in my opinion, particularly taking the “time is money” rule into account.

Buy Tools

Universal Rule #2: You can’t build good things without good tools.

Having a little bit of money set aside lets you invest in those tools that make your life a lot easier but are difficult to justify on projects that don’t have a dedicated budget.

In particular for me, the time saved by a single feature of Sketch — the ability to automatically export to @1x, @2x and @3x with a single click is well worth the $99 it costs. Before I had a budget it was a struggle to justify when I get Photoshop as part of my $10/month Adobe Creative Cloud subscription. With a budget? No brainer.

Buy Hardware

Universal Rule #3: Always test with real hardware.

Alright, this one isn’t really that universal. However, you really must work with real hardware when building software. Emulators are crappy.

Depending on your project, you might be able to get away with an iOS device or two and be done with it. It’s really important, in my opinion, to get hold of the slowest device you support and test on that as much as you possibly can. If you run your app day-to-day on the slow thing, you’ll kinda do performance optimisation as you go, which is much nicer than working with the latest and greatest for a year, then thinking “Oh, I should test on that old one” a week before release and finding it runs at 2fps!

For my project, though, I work with cameras. For a long time, I was just using the camera that started this whole thing, my Canon EOS 6D. It works perfectly well, but there’s a few problems:

  1. I can’t really say I support “Canon SLRs” if I’ve only tested it with this one model of camera.

  2. The constant testing and debugging cycles have really take a toll on the battery.

  3. This is my personal camera, and as such I’ve spent a great deal of time setting it up to my liking. However, for testing purposes I have to screw around with it all the time, which gets annoying fast when I just want to go outside and take photos. Even worse, if my tests fill it up with photos of the wall and mess with the settings, I might end up missing a great photo opportunity.

To solve these problems, I bought a different model of camera that’s dedicated to testing. This solves all of my problems — I can screw around with it all I like and not care, the mains adapter I bought with it means I don’t need to worry about the battery, and the fact it’s a different model means I can be more confident about compatibility.

However, you do have to kind of feel sorry for the poor thing. Some cameras get to take photos of beautiful models, some get to see the Northern Lights, others record a couple’s most treasured memories on honeymoon. This one is destined to have a life chained to a desk by a power cord, taking photos of the wall.

Once Cascable ships, I should take it to somewhere beautiful to celebrate.

My Expenses

Adding it all up, I’ve spent well over USD $1,500 on Cascable and I’m still only working on it part-time. Even with this in mind, it’s been absolutely worth it in my eyes — the benefits the tools and services I’ve bought have boosted the quality of my project no end.

If you’re interested, here’s a list of my current and near-future expenses.

Item Cost (USD)
Test Camera (Canon EOS 70D) $999
Canon Mains Power Adapter $119(!)
Design Services $430
JIRA License $25
Sketch License $99
iOS Developer Membership $99

As I approach launch, the costs will start to pile up:

Item Cost (USD)
Various Hosting Costs ~$40/month
SSL certificate $100-$500
Another Test Camera ~$600
Design Services ~$1,000 - $2,000

Not including workspace costs (which I’ll discuss in a future post) or the cost of my own time (time is money!), I’m going to be several thousand dollars in the hole by the time I launch.

Once upon a time, a few mistakes ago, this number would have scared me away big time. But! If I’m not willing to invest in myself, how can I expect customers to invest their money and time into me and my app?

Next time on Secret Diary of a Side Project, we’ll talk about taking your project and taking it from whatever state it’s in right now through to launch, through careful planning and a little help from an outsider.

January 25th, 2015

Secret Diary of a Side Project: Coding Practices

Secret Diary of a Side Project is a series of posts documenting my journey as I take an app from side project to a full-fledged for-pay product. You can find the introduction to this series of posts here.

In this post, I’m going to talk about some of the coding practices I’ve picked up over the years that really make a difference when working on projects that have a limited time budget.

There are tons of coding practices that help us be better, faster, more understandable as coders. However, although this post is pretty long, I only talk about two practices — both of which are focused on keeping projects simple to understand for people new to the project. That’s really important for a side project you intend on seeing through — because you’re working under severe time constraints, you may well go months between looking at a particular part of a project. You’ll be a newbie to your own code, and future you will love past you a lot more if past you writes a simple, easy-to-understand project.

Keep Dependencies Down, Keep Dependencies Static

Might as well get the most unpopular one out of the way first — I dislike third party dependencies, so I keep them to an absolute minimum. CocoaPods is a third party dependency to manage my third party dependencies, so I don’t use that at all.

My app has four third party dependencies, one of which isn’t included in release builds (CocoaLumberJack).

  • CocoaLumberjack
  • Flurry
  • MRProgress
  • Reactive Cocoa

The list itself isn’t important. What’s important that each item in it only got there after careful consideration of the benefits and drawbacks.

There’s a huge amount of discussion online about CocoaPods, and I’m going to ignore all of it — CocoaPods doesn’t really add much for the way I approach projects, so I don’t use it.

So, how does a dependency end up on that list?

  1. If I end up in a position where a third party library might seem useful, I figure out if I should rewrite it myself. After all, I don’t truly know how something works unless I wrote it, and if I want 100% confidence in my product, I should write it all (within reason).

  2. If I actually decide I want to use the library, I’ll find the latest stable release of it, add it to my project, and start using it.

  3. I never touch or update that dependency again unless I have a good reason to.

Point 3 in particular makes most of CocoaPod’s usefulness moot. A requirement for me to use a third party piece of code is that it’s mature and stable. If they’re updating the library frequently and I’m required to keep up with those updates to avoid problems, well, that library gets deleted and I find something else.

Using this approach, I can concentrate on making my app better rather than making sure the spiderweb of dependencies I’ve added don’t screw things up every time they get updated.

Model Code Goes In A Separate Framework Target

While preparing for this post I had a look back at my previous projects and it turns out I’ve been doing this since I started programming in Objective-C and Cocoa back in 2006, and I really love the approach.

Basically, if it doesn’t involve UI or application state, it goes in a separate framework. My iPod-scanning app Music Rescue contained a complete framework for reading an iPod’s database. My pet record-keeping app Clarus contained one to work with the application’s document format.

Even though my camera app isn’t ready yet, I have a stable, tested, fully-documented framework that cross-compiles for iOS and Mac OS X. That framework takes complete care of camera discovery, connections, messaging queues, and all that jazz.

It’s true that this actually adds more work for you, at least at the beginning. Isn’t this post supposed to be about making your life easier? Well, the long-term benefits far outweigh the extra work.

It Provides Separation Of Responsibilities

A huge benefit to this is code readability and separation of process. Suddenly, your application has a huge set of problems it just doesn’t have to care about any more. Sure, you need to care about them, but your application doesn’t. It makes the application lighter, easier to work with and that bit less complicated to understand.

It Encourages You To Future-Proof and Document APIs

This is an interesting one. Now your logic is in a completely separate target, suddenly it’s a product all of its own. It needs documentation. It needs a stable and thought-out API.

This code in the Mac Demo app hasn’t changed since 2013, even though camera discovery has been refactored at least twice in that time.

This pays dividends down the road if pulled off correctly. Designing APIs is hard — I’ve been designing public APIs for Spotify for a number of years now, so I’ve stumbled through all the terrible mistakes already. Some pointers for designing APIs that stand the test of time:

  • No non-standard patterns get exposed publicly. Sure, your task abstraction layer/KVO wrapper/functional programming constructs are amazing now, but in two years? You’ll regret exposing it publicly when you move to the new hotness. Plus, users shouldn’t need to learn your weird thing just to connect to a camera — even if that user is you in six months.

  • Document everything as you go. Header documentation is great in Xcode these days.

“How does this thing behave again?” Opt-Click “Aha!”

  • If you need to do background work, have the library completely deal with it. The client application shouldn’t have to care about it at all. A common pattern is to have public methods dispatch to a queue/thread privately managed by the library, with the aim of making the library somewhat thread-safe. If clients find themselves needing direct access to the private queue/thread, rethink your APIs so they don’t — it’s a pretty bad code smell. Always document what queue/thread callbacks come back on, or take a parameter to let the client tell you.

It Makes Quick Prototyping and Testing Crazy Easy

This is my favourite benefit of the multi-target approach, and where you really start to reel in the time savings. Making the core of the application compile for Mac OS X means I can prototype super easily.

I have a Mac target called Cascable Mac Demo. It’s a wonderful little debugging tool — it supports viewing all of the camera’s properties, taking a photo, browsing the file system and downloading files, and streaming the camera’s viewfinder image. Thanks to having a feature-complete library with a thought-out API, the entire application is less than 250 lines of code.

This little application makes building and testing new functionality a breeze. When launched, it’ll connect to the first camera it finds and sets up just enough state to allow me to add some code to test some new stuff as it’s being built.

This is a much better approach than adding some random code somewhere in the main iOS app to make sure new functionality is coming together properly, and makes sure my core functionality is mostly working and complete before it ever goes into the main app.

It Gives You Flexibility

What if I want to release a Mac version of my app one day? Well, the core functionality is already compiling, running and tested on Mac OS X. Hell, the Mac Demo app is more full-featured than some proof-of-concept apps I’ve seen!

If you want to be really flexible and are seriously considering multiple platforms, write your core framework in something cross-platform, like C# (or C++ if you hate yourself). The benefits of a constant, mature, tested library across all of your platforms will pay dividends.

Cascable in C#? Why not?

Next time on Secret Diary of a Side Project, we’ll talk about one of the most difficult things in this whole process: cold, hard, cash money.

January 12th, 2015

Secret Diary of a Side Project: Perception Shift

Secret Diary of a Side Project is a series of posts documenting my journey as I take an app from side project to a full-fledged for-pay product. You can find the introduction to this series of posts here.

In this post, I’m going to talk about some of the mental shifts you need to do when taking the leap from side project to real product.

That pivotal moment. It’s weird. You’ve been looking at this project for months, maybe years, slowly adding code here and there. Features slowly form, and the bugs get less “Oh, don’t push that button — it’ll crash” and more “Yeah, I need to make sure those buttons line up”.

Then, one day, you’ll use it for real. In my case, it was in a photography studio learning about portrait lighting. I was taking a break and wanted to look at some of the pictures I’d taken. I happened to have my iPad with me, so I fired up whatever build of the app I had on there and used it to download some photos from my camera. Then, we passed my iPad around and discussed the merits of my photos and how to improve them.

I read or heard or saw a piece by Wil Shipley a while ago (long enough for the memory to have faded a bit, so apologies if I’m mis-quoting him), where he said he takes “Is that all it does?!” as a compliment, as it means that you’ve made something that ‘clicks’ with the user so well that they can just get on with their task without all the stupid computer things getting in the way.

I had that big-style on that afternoon in the studio. At that point, the app was around 15,000 lines of code, which isn’t tiny to say the least — the main breadwinner from my previous company was 18,000. From a programming point of view what I did is pretty complex task — detecting the camera on the network using their stupid thing that isn’t Bonjour, connecting and handshaking with it, dealing with its finicky protocol, downloading a stupid Canon RAW file to the iPad, converting it to JPG and allowing the user to view it fullscreen.

Downloading photos from a WiFi-enabled SLR in an early build of my app.

My app distilled that down to two taps. Three, if you count launching it in the first place. And in this busy place with lots of people wanting to see my picture, it worked flawlessly. I launched the app and it found and connected to my camera and presented the photos within. “Can I see that one?” someone said. I tapped the “Download” icon, watched a progress bar for a few seconds, then tapped the thumbnail that appeared in the “On this Device” pane to view it fullscreen. “Cool!” the guy said “…but I think if you moved the light down a bit, you’d make that shadow softer, which I think would make the photo look nicer.”

At that moment, I felt so proud. This is why I make software. The process was so smooth that it completely melted away into the background, to the point where nobody else even noticed the app. Instead of spending time using my app, we spent time learning about studio lighting.

Evidently I missed the “Try not to look like a scruffy hobo” preparation step of going to a studio.

That day, my project shed its “side project” status and became a thing I knew could be genuinely useful to people. I’d been idly considering it for a long time, but I knew that I should try to finish this and ship it.

Once this big perception shift has happened, everything changes. It’s really important to take this perception shift seriously and be strict with yourself — if you carry on as before, your side project will stay a side project and you’ll end up shipping something not up-to-scratch.

Before we continue, let’s take a moment to define what a side project actually is:

  1. The primary attribute that all the others derive from is that it’s a project written in your spare time, which gives extreme time limitations.
  2. Features are typically written on the path of least resistance, throwing best practices out of the window in the name of getting a feature done in the hour you have before you go to bed.
  3. Unit tests? Nah. Error checking? // TODO: Handle this properly

Obviously, these behaviours need to change. So, how do we manage the transition?

Keep Refactoring Strict

As soon as you decide to turn a side project into a real product, it’s very tempting to go back and refactor everything immediately. Rebuild the code! Undo all the shortcuts! Add tests! But, if it works… don’t. Not yet.

You need to be really strict about rebuilding if you ever want to ship the thing. The rule of thumb I follow is: If I ship a build to testers with no changes except this refactor, will they notice? Sometimes the answer will be “yes”, and if that’s really the case then go ahead. However, if the answer is “no”, think hard before touching that code.

An example of this is the library that actually speaks to the camera in my app. It has three layers — the outer layer defines a very generic API for the application to consume. “Take a picture please”, “List the files on the memory card”, etc. The middle layer defines slightly lower-down APIs, but still fairly generic. “Send this command with these parameters, then give me the response here”-type stuff. Basically RPC. Finally, the very-internal layer actually deals with the grunt work of encoding the binary messages properly, handling responses and dealing with the upkeep of keeping the camera happy.

These three layers work in concert so the application doesn’t have to care about the workings of the camera at all. I’m actually pretty pleased with the design of most of it.

However, that inner layer. The most important one. The most intricate one, dealing with TCP sockets and threads and all that fun stuff. It’s terrible from a code-style point-of-view.

However! It works, and it works well. The last commit on that class was in June 2014, adding a minor feature. Before that, I last touched the code in July 2013!

I must’ve been severely sleep-deprived when I wrote this glorious mess. But, it works, so it stays.

As an engineer, I would love to refactor that class. I could redesign the shit out of it — it’d be a work of art! However, by now that class must have handled over a million commands to and from cameras in my care, and it just plain works. That code is over a year and a half old, and now this project is a real product with a release looming in the not-too-distant future, it just doesn’t make sense to mess with it.

…and Do It Right When You Do

Alright, so it’s time to refactor some code from the side project era. Make sure you do it right — design it properly, add tests, etc. Replacing some old crappy code with slightly less crappy code that hasn’t been thought through or tested properly isn’t worth the effort.

A Commit A Day…

I got this tip from Simon Wolf: do something on your project every single day, no matter how big or small. I started doing this and bar my honeymoon, I’ve kept up with it pretty well. Sometimes (like today) all I do is tweak the in-progress website a bit. Yesterday I moved my icons from Photoshop to Sketch. The day before, I spent nearly 11 hours working on an advanced feature.

Every time you touch your project in any way, unless you’re doing it very wrong, it’s getting better. It might only be a tiny bit better, but it’s getting better.

Over a year’s worth of tiny bit betters and my project is pretty damn mature.

Keep Away From New Shiny

Remember: This is a real product now. If you bring in every shiny new library or even language that comes along, you’ll end up spending hours working and not moving forward at best, and end up with a half-working project that has hundreds of dependencies at worst.

This Is Starting To Feel Like Work!

These restrictions take away a lot of the fun things about side projects. This can be a little discouraging at first, but stick with it. You’ll (hopefully) start to find joy in the results of your work rather than the process of making it. Sure, mucking around with autolayout for hours is a pain in the ass, but just look at that UI! It’s glorious!

Next time on Secret Diary of a Side Project, we’ll talk about some actual software development practices and idioms that’ve helped me. There’ll be code and everything!

January 10th, 2015

Compile-Time Image Name Checking

In my continued quest to banish as many string literals as I possibly can from my project, I wrote a little tool to generate a header file containing string constants for the names of all the images in my .xcassets bundle.

This means you get compile-time checking of two things — you misspelling the image name, and images being named incorrectly.

The tool is very simple, and is mostly a duplicate of the generate-string-symbols tool I wrote a while ago. It runs through your .xcassets directory and writes the found image names out to a header file. You can see the source over on GitHub.

For consistency’s sake, you can pass -prefix and -suffix parameters to the tool, which do what they say on the tin. A prefix of CBL and a suffix of ImageName will convert and image named Awesome into CBLAwesomeImageName, with a value of @"Awesome".

Putting It All Together

To integrate this into your project, there are three steps:

  1. Generating the header files when your project builds.
  2. Telling Xcode where to find the generated files at build time.
  3. Importing the generated header files so you can use them.

First, you want to create a custom build step in Xcode before the Compile Sources build step to generate header files from your image assets. My custom build step looks like this:

    -assets "$PROJECT_DIR/Cascable/Images.xcassets"
    -out "$BUILT_PRODUCTS_DIR/include/CBLImageNames.h"
    -prefix CBL
    -suffix ImageName

It uses /bin/sh as its shell, and I have the generate-imageasset-symbols binary in the Vendor/generate-imageasset-symbols directory of my project. It places the generated header file in the include directory of the build directory.

Next, you need to tell Xcode where to search for your files. Make sure your project’s Header Search Paths setting contains $BUILD_PRODUCTS_DIR/include.

At this point, you can start using the symbols in your project. However, you’ll need to #import your generated header files(s) in each file you want to use localised strings in.

To get around this, can #import them in your project’s prefix header file.

#import <CBLImageNames.h> // Generated from image assets

UIImage *image = [UIImage imageNamed:CBLAwesomeImageName];

…and you’re done! You can find the generate-imageasset-symbols project over on GitHub under a BSD license. Enjoy!

January 8th, 2015

The Antisocial Network

I have a love-hate relationship with Facebook. I opened my first account after my girlfriend (since fiancée, now wife) wanted to tag me in stuff she did. I survived maybe a couple of years before getting bored and deleting my account.

I opened a new account in 2010 to organise a leaving party when we moved to Sweden. I’ve kept that account to this day.

Starting on a positive note, I enjoy that 99% of my friends are on Facebook since it makes organising events super easy. Their Messenger app isn’t that bad either.

However, my Facebook timeline is absolute trash. I wrote about it a little in my Mental Health post last year, and it’s summed up beautifully in the short (~2:30) film What’s on your mind?, but the lives I’m seeing in tiny, out of context snippets through my Facebook timeline are completely false. Hell, I’m guilty of it myself.

The thing is, I know the people in my Facebook timeline are nice people. Sure, I unsubscribed from some friends long ago since they were just spewing out nothing but “funny” pictures and KEEP CALM AND _____ ON slogans, but by-and-large my friends are lovely people. I wouldn’t be friends with them otherwise!

Recently it was getting to the point where I was starting to dislike people I know I really like, even childhood friends I’ve known for decades.

“Why don’t you just unfollow them?”, my wife asked.

So I did. I unfollowed every single person I’m friends with. My Facebook timeline is now completely empty.


The obvious question is “Why don’t you just delete your account?”. Well, since 99% of my friends are on there, I can still chat with them directly and organise events with them, and Facebook is a decent tool for that.

I’m hoping that not receiving a constant stream of tiny snippets will make me think “I wonder what x is up to these days?” sometimes, ending up contacting that person “properly” via some sort of two-way direct chat (IM/phone/whatever). I haven’t spoken to some of these people for over a year, but Facebook has tricked me into thinking that we’re in contact because I see their face on a timeline once in a while, and they see my face in theirs.

Somehow, a social network has made me an unsocial friend.

December 29th, 2014

Secret Diary Of A Side Project: Introduction

Nearly ten years ago, I founded KennettNet Software Limited. It was a small software company that came into being after a couple of years of making Mac OS X software on my own led to an income that was enough to support me full-time. Ostensibly, the company was successful — it had four employees at its peak, and its failure was, at its core, due to my being a poor businessman.

This was at a simpler time, when making applications for Apple platforms was a niche thing to do. The iPhone was non-existent, and mentions of Apple in the press were almost always accompanied with the word “beleaguered” right there in the headline. You could make a living writing Mac applications, but there was no gold rush — and, more importantly, no rush to the bottom either.

When I shut the company down in early 2012, it was still earning enough to support me if I went it alone with a clean slate. Unfortunately, the sum of the company’s liabilities and my own debts far out-shadowed the company’s income, so it had to go. It was a bittersweet moment — it was sad to shut my company down, but it released a lot from my shoulders and I was able to repay all of my debts over the next couple of years.

I had a sign! A real one!

Now it’s almost 2015 and I have that clean slate, and all I want to do is try again at indie development — it’s in the fibre of my being. Despite the latter years of KennettNet being nothing but pain, I still remember the whole experience as one of the best times of my life.

I’ve been trying to fight it for over a year — after all, I have a steady income from a great company that’s been more than accommodating in letting me work on projects that are rewarding to work on (I got to go to Cupertino and work inside Apple for a couple of days on a then top-secret project — how cool is that?). From all logical points of view, it’d be crazy to even think about leaving.

Times have changed. It’s hard to do things the “old way” — that is, to make an app, sell it for money and be able to put a roof over your head, and there’s been plenty of documentation of this fact recently.

I could try the “new way”, of course. We’re still (just about) in the gold rush phase of iOS development. I could half-implement an idea then convince a VC company to give me millions of dollars to finish it. I could then hire some people and spend the next six months trying to figure out how to make those millions of dollars back, pivoting several times until the product we’re working on no longer resembles the original vision and so scared to charge customers money that we never exit beta and end up with an ad-riddled service that nobody likes.

The “new way” isn’t my style, as you can probably tell from the bitterness of the above paragraph. It just isn’t. It works for some people, and more power to them. However, I’ve spent enough time in the Silicon Valley bubble — or at least at the edge of it looking in — watching companies solve problems for wealthy, middle-class white people living in suburbia to turn me off that area of the industry for life.

I’ve been working on a side project for over a year and a half now, and you know what? At some point it went from a hacky side project to a genuinely useful app that’s just not ready for prime-time yet.

My project’s agile board in 2013.

It’s time to throw caution to the wind — in a careful and well-planned manner, of course. March 12th, 2015 will be my last day at Spotify for a little over six months, in which time I’ll be working on my app full time in an effort to release it the “old way” — I’ll charge money for it in an attempt to earn a living. It’ll no longer be a side project, it’ll be my full-time work, funded by my savings account.

Why the 12th? Well, on March 13th, my first day off, I’ll hop on a plane and fly over to the UK to attend NSConference — a community-focused event that always inspires me. It’s a fitting start to an exciting time, I feel.

This decision hasn’t come lightly. I’ve been fighting it for over a year, but I recently realised that if I don’t do it now while the opportunity is available, I’ll regret it for the rest of my life.

So, what’s Secret Diary of a Side Project? In the coming weeks and months as we approach March 12th, I’ll post a series of articles on this blog discussing the project — the disciplines I’ve used to keep it moving forwards, the lessons I’ve learned along the way, and other various tidbits about making an app as a “spare-time” indie developer.

In all likelihood, all I’ll achieve is proving Brent, Marco, Gus and a number of other developers correct in their assertions that you can’t make good money as an Indie developer on the App Store these days. However, I’m going to have a lot of fun doing so and you, dear reader, get to come along for the ride.

I’m really, really excited about this. The project is in an area I’m passionate about (photography) and at the very least, I’ll get to make an app I’m proud of. I’m also looking forward to re-engaging with the Cocoa development community — something I’ve not been able to keep up with as much as I’d like with a corporate job.

As always, feel free to keep in touch with me via @iKenndac on Twitter.

September 16th, 2014

Mental Health

Until today, this story has been shared with four people in the world. My wife, my manager (who only knows the parts of the story he actually took part in), my friend Tim and my psychiatrist.

Recent events in both my private life and the world at large have convinced me that discussing mental health can only be a good thing. If you only visit here for posts about programming and stuff, you’re welcome to give this a miss. However, I’d encourage you to give it a read — who knows, it may help you or someone you know.

There’s nothing quite like writing a letter demanding a solicitors release money from your dead Mother’s estate to make you feel like the scummiest person on Earth.

This is the pivotal moment that poisoned my mind for six months, damaging a time that should otherwise be only filled with wonderful memories — those of marrying my wife and buying a house together.

Grieving the loss of a parent is always going to be a shitty part of your life no matter what. Not to go all Batman about it, but my father died when I was younger and it’s a process I’ve been through before, albeit with a much less mature mind at fifteen years old. This time around I was doing fine, all things considered, and had settled into some sense of peace once I realised (amongst other things) that since death is a fact of life, a parent passing before their child is orders of magnitude less of a tragedy than vice versa. Yes, it’d be lovely if nobody had to die, but that’s not how life works.

However, being her closest living relative, I had the task of supporting the solicitors assigned to administer my late Mother’s estate. In May 2013 I sat in their stuffy office in Stevenage in the UK and was assured that the estate should be a fairly simple affair and that they couldn’t see it taking more than six months to complete. Two weeks later they sent me a document that contained a few currency conversions, all of which had been calculated wrong. And so started the most harrowing set of bureaucracy I’ve ever encountered in my life.

My breakdown came in a one-on-one meeting with my manager in October 2013. In a previous blog post, I hinted that I was thinking of trying to “go Indie” again, and in October I’d committed to take six months off from March 2014 to try just that. All the paperwork was signed, and I was looking forward to making my own apps “for real” again.

However, the process with the solicitors was still trundling along and having to research the multitudes of laws at play to make sure they weren’t making more mistakes was really dragging me down, and it was starting to affect my productivity at work. I thought it’d be a great idea to move this six month leave from work forward to January so I could combine making the app with taking some time off to recuperate.

The flat “No.” that came out my manager’s mouth hit me like a brick wall. “…I’ve seen you planning this leave for months now, and every time you talk about it your face lights up. If you’re unwell, you should use medical leave to get better, and make sure your time away is kept a happy thing.”

I just kind of sit there in a dumbfounded silence.

“Obviously, the company has no legal grounds to deny this request, so if you’re sure you want to do this I’ll approve it, but I really don’t think you should.”

“…are you alright?”

I realise I’ve been sitting there in silence for what must have been a minute. I can’t see very well, so I take off my glasses to clean them. To my surprise, I realise I’m crying quite heavily.

“Go home. Take a couple of days to catch up on your sleep, then call the doctor and get help. Don’t worry about your work, I’ll cover for you and tell people you have the flu or something.”



I get up in silence and scurry to my desk, staring at the floor hoping to God that nobody looks at me. I put on my hoodie and leave the office as fast as I can, tears streaming down my face. I don’t break pace until I’m sitting on the underground train, huddled in the corner with my hood up trying my hardest to be invisible. I’m sure everyone else thinks I’m some unstable lunatic as they avoid sitting near me. Hell, I feel like an unstable lunatic. I’m so upset and so confused that I’m genuinely wondering if I’d had a stroke, or if I’d ever be able to show face at work again.

After that day I do whatever I do when I’m going through a tough time, especially when I can’t rationalise and understand what’s going on — I withdraw into myself. Social interactions become more and more difficult as time draws on, mainly because I feel more and more incapable of functioning in civilised company. Suddenly the answer to “How are you doing?” becomes an elaborate lie, and the friend telling me about how he’s having a great time becomes a stab in the heart. Presenting myself for casual interaction becomes hard work, so I stop doing it.

Even online interaction becomes difficult eventually. You’ll notice a hole in this blog between October 2013 and July 2014 due to this, and while I can’t seem to find any tools to show my social network engagement over time, I’m sure you’ll find that my Twitter and Facebook use during that time dropped off a cliff, too.

Facebook in particular is completely devastating to someone going through a tough time. A quote I hear a lot goes along the lines of “You’re comparing your blooper reel to everyone else’s highlights” and it’s a fairly accurate little soundbite. My Facebook feed, just like everyone else’s, is full of people jostling for attention, desperate to prove they’re winning at life. Look at my amazing holiday! Look at my awesome new phone!

Instasham by Pandyland

Typically, all these posts don’t really bother me — hell, I do the same thing — and I unsubscribe from the people who are particularly obnoxious. In my broken state, however, each one of those posts became a slap in the face, causing me to further distance myself from my friends and coworkers. Eventually, I’d stopped talking to most of the people I knew and had stopped attending any social events at all.

Nearly a year later, I realise that manager practically saved my life. I didn’t return to work for well over a week after that incident, and only after doing as instructed — I spoke to my local doctor who referred me to psychiatric care at a clinic in Stockholm.

My psychiatrist (who I’ll call my doctor from now on, since it takes me about two minutes to type ‘psychiatrist’ correctly each time) and I pieced together what had happened. In short:

  • My Mother had died.

  • Being the closest living relative, I had to support the solicitor appointed to deal with my late Mother’s estate.

  • The solicitor was, to put it nicely, requiring a lot of support.

  • Being in a different country to the solicitor made their multi-month gaps in communication all the worse.

All in all, I was having a pretty shitty time. The combination of these factors, though, was poisoning my mind and I couldn’t even see it. Looking back, my correspondence with the solicitor is all like this:

  • One email to the solicitors was discussing that a multiple month delay to “wait for some paperwork” wasn’t acceptable since the paperwork in question was super easy to get, never mind the fact that I had copies of all of it that I’d have been able to supply in ten minutes if they’d only told me what they needed.

  • Another email discussed Section 27 of the UK’s Trustee Act 1925 and the liabilities of the various parties dealing the the deceased’s estate before and after the Section 27 notice was filed.

  • Yet another discussed finding records from my Father’s death and supplying them to the UK Tax Agency to get the correct tax status for the estate.

All of this is completely normal stuff to be discussing with legal representatives during this sort of process. However, the entire time it just felt like I was typing GIVE ME MY MONEY. GIVE ME MY MONEY. GIVE ME MY MONEY. over and over and over again. I felt like the worst human being alive simply for making sure my Mother’s estate was dealt with properly and promptly.

Except I didn’t know that’s why I felt horrible. I just felt like a horrible person and I didn’t know why.

Turning it Around

My doctor listened to my story and the most wonderful thing happened. She became autocomplete for my mind, filling in holes in my head I didn’t even know were there.

I told her about that meeting with my manager in which I completely melted down. “Yes, it can be funny how someone else noticing you’re not doing so well can make you realise how bad you’re actually feeling”, she said. I nodded a slight laugh and replied “Yes, it really brought it home”. Wait, it did? Of course that’s what happened! My mind flooded with a clear memory of that meeting — about how I was touched that my manager was so caring, about how I was really not coping well with the multiple jobs I had to do.

Later, I told her about the constant back-and-forth with the solicitor, and made an offhand remark about feeling “kinda greedy” even though I know, rationally, that this process has to happen no matter who does it. “That sort of thing can really eat at the soul, can’t it?” Of course that’s why I feel so bad!

On the way home, I’m bursting with excitement at finally being able to see my problems, and can’t wait to tell my wife all about it. Destructive Daniel kicks in and I start to feel guilty — my sweet, loving wife has done nothing but stand by me and support me while I turn myself inside out for months, and I end up going somewhere else to get help and am transformed in an hour. I wonder if she’ll feel like she’s not capable of supporting me. I wonder if I’m being selfish.

Of course, my wife is ecstatic that I’m making positive progress and I feel like an idiot.

Once we’d rooted out what exactly was wrong, we started a form of CBT which, very simply, is a treatment that embodies “If you were happy when you did x, you should do x.”. My doctor spent a session drawing a diagram on the whiteboard of the destructive cycle that’s common:

First, something crappy happens.

  1. Because you feel crappy, you can feel tired and have the instinct to stay at home and rest and avoid people.

  2. Because you’re at home, you miss out on the things that give you joy — seeing friends, taking part in hobbies, etc.

  3. Because you’re missing out on the things that give you joy, you feel more crappy.

  4. Goto 1.

“So, does any of this seem familiar?”

That session is when psychiatry ‘clicked’ with me and I realised just how powerful it was. Simply by drawing a diagram on a board, my doctor both showed me the negative cycle I was in and how to fix it. I don’t mean to belittle her when I say she “simply” drew a diagram — she drew it in the way I “simply” write a computer program to solve a problem or an engineer “simply” uses arches to build a bridge capable of holding up a desired load. Her years of training and experience allowed her to express a concept completely alien to me in no time at all.

My tasks were to force myself to do things I knew I enjoyed doing, even if I didn’t think I didn’t want to. I started out within the house — practicing guitar, doing stuff with my railway, etc. Once I was able to do that, I focused my efforts on actually leaving the house and attending social events. It took an absolutely herculean effort, but I was able to attend a group of friends’ weekly-ish “Hacktisdag” pizza-and-programming gathering again, if only for a couple of hours to start with. Baby steps.

From then on, I started recovering in leaps and bounds and I was able to pull myself out of the negative cycle with some dedication and help from my wife.

Back To Normality

When I think back to the six month period between late 2013 and early 2014, my mind should fill with happy memories of getting married to the love of my life and moving into a beautiful house together. Instead, my heart fills with a deep dread that the person I became — an introvert consumed by confusion and guilt, being driven away from his friends by his own hyper-destructive interpretation of events — is coming back.

It’s slowly getting better. Occasionally I’ll be taken by surprise as an otherwise innocuous comment manages to sting way more than it should, but those are getting rarer and I’m able to shake them off in a few moments.

I’m very lucky, though. By some absolute miracle, a wonderful manager noticed I was in trouble and led me to an incredible doctor who taught me how to identify when I might be having trouble and the steps I can take to mitigate the problems. I avoided depression. Just. Really, by the skin of my teeth.

When Robin Williams committed suicide, I read the same thought over and over again — what could someone so successful and wealthy possibly be so sad about?

I’m a successful young guy earning good money at a fun job, and I have lots of friends and live with my wife and dog in a beautiful home. I really have nothing to complain about. Yet all it took was a few emails and before I knew it I was so outside of my own mind I didn’t know which way was up. I wound up huddled on an underground train, scared and confused and crying and helpless.

And remember: I wasn’t even depressed.

We don’t hesitate to seek help with our cars, our computers, hell, even the rest of our bodies when they break. Somewhere along the way it became taboo to talk about mental health — a subject reserved for conversations that start with “Can you keep a secret?” or, too often, never start at all.

I really wish this would change. I genuinely believe it could save lives.


Just over a week ago I visited my Mother’s final resting place for the first time since she died — a remote spot on top of a mountain in the Alps near the French-Italian border.

My Mother’s Resting Place, ~2100m Above Sea Level Atop Combe Chauve

After an hour-long descent in a battered old 4x4, I slumped into my Mum’s old sofa and opened my laptop to find an email from the solicitor. They’d finished administering her estate, pending my approval.

That email was sent while I was standing on top of the mountain taking in the beauty of it all, less than five minutes after I took the above photo.

Perhaps I should have gone up there sooner.