There’s a lot of talk in programming about challenges and eventual successes, about how a given problem stumped a developer for a long time, but eventually they overcame it and shipped it / blogged about it. But I think that paints a lopsided view of programming because aside from “outage post-mortem” posts, we rarely talk about the failures in programming. We rarely talk about how programmers struggle and fail at things, even though it’s a pretty natural and regular part of our job (and any job, really).
So this is my inspirational post about failing.
About a month ago, I started a project at Khan Academy to implement iOS State Restoration in our app. State Restoration is that feature where your app is supposed to pick up on the exact screen where you left off last time, even if the app happens to have quit in the background in the meantime. To the person using your app, it’s been running the whole time.
It was scheduled as a two week project, but I set a personal goal to do it in one (o’ past-Jason, you were so young). I tried to do everything right, from the start: I looked up relevant documentation on Apple’s site, which is decently comprehensive, if a little confusing at the start (when you’re not accustomed to the lingo of a given feature, many of the different parts sound the same. see also Core Data). I watched the relevant WWDC sessions (2012, 2013). I planned out the project in a task manager, trying to break things down into small logical pieces.
Pretty much all my prep work was successful. I did the right things. But State Restoration was still way harder than I expected.
Apple says it “Just works” but what they really mean is “If you use Storyboards and your view controllers use mutable, optional references for everything, it Just works.” I’m not really trying to crap on State Restoration, because it was built with Objective C in mind, and in that frame of reference, yeah, all your view controller references are going to be mutable and “optional.”
Most of the Khan Academy app is written in pretty Swifty Swift, which means we use immutable (
let), non-optional references (or when possible, values (
enum)) in our view controllers. As a consequence, that means we also inject most of what our view controllers need right in on
init. State Restoration kind of wants us to return initialized-but-bare view controllers, which can then be setup at some point in the future with restored data (like say, the ID of the object shown by the controller).
Unfortunately, we didn’t really distill the above two paragraphs until the project had already gone over its allotted time by a week. In the third week of the project, we came to those realizations, and I tried re-writing one of our view controllers to see what it would be like (spoiler alert: optionals are infectious; mutable references throw a wrench in everything).
The project was overdue and my solution didn’t seem feasible to redo throughout the entire app, so we decided to call it: continuing to implement the feature beyond the basics (the main UI of the app correctly restores, at least) currently isn’t worth the effort. There are better ways my time can be spent helping learners using our app.
This kind of sucked for me. I’ve been writing iOS apps since 2008. I’m a professional software developer and I’m pretty good at it these days. I even had a lot of help from a former UIKit engineer. But still, I struggled quite a bit with this.
My point here isn’t really about State Restoration (I’ll bet there are solutions to making it work in a Swiftier world, or if not, I’ll bet there are third-party solutions that work better). My point here is really just programming is hard, even people who have been doing it for a long time still struggle from time to time. And we don’t talk about this very much. It’s a little embarrassing, but it’s definitely natural.
I wish we talked about failure more often, because it’s really not as bad as it seems. Succeeded or failing, I’m still learning things either way, and I’m pretty sure I learn more when I fail than when I succeed anyway (or at the very least, as the phrase goes, if you’re not failing every now and then you’re probably not doing anything too interesting). But when we only talk about succeeding, we paint an inaccurate picture of what it’s like to be an experienced programmer, and that harms pros and newcomers alike. So lets talk more about failure. How have you failed?