It was an unremarkable flight until we began our descent. I had big plans for the flight, to get some work done on Kapowski, and the trip, getting even more work done on Kapowski. Well, that didn’t happen.
Here’s what happened: my right ear exploded in pain as the pilot began our descent into Vancouver a week ago. A day later, it started oozing pus and blood. Turns out I have a perforated eardrum and a really bad infection; every doctor points out how nasty my infection is. My ear has improved since, but it still hurts right now. Seen Shaun of the Dead? I’m Bill Nighy, half-zombie, in the car, turning off the radio in relief.
Just. Keep. Going. Do what you can.
I’m a dev/design team of one. Work has slowed to a trickle as I get through this injury.
It’s not a total loss, though. I created the home screen in Sketch, and clarified my thoughts on using tools like Sketch. Since returning home, I’ve also started coding the app, which has had its own benefits.
Usually, there’s a silver lining.
Harrison Ford nearly died on set while filming The Force Awakens. His ankle was crushed by hydraulic failure on the door to the Millennium Falcon. It could have been his head or something and that door weighs as much as a small car. They had to take time off for it. This allowed Abrams to reconsider the scenes between Rey and Finn in the Millennium Falcon. When they returned to shooting, they reshot all those scenes.
Without the time to reconsider, perhaps we wouldn’t have believed Finn’s motivations for later in the film? Or perhaps there wouldn’t be that subtle spark between Rey and Finn? We won’t ever know; while terrible what happened to Ford, they were able to refine the movie with the time off his injury afforded.
Something I’ll repeat over and over: the more time, the better. There’s a balance required, of course: take too long and no one will care once you ship. But generally, the more time you have to reflect while making your app, the more refined the app will be.
An injury or illness rates pretty low on the list of setbacks that significantly impact the project; once the person recovers, they’re back and the project hums along. Someone leaving the project will have a bigger impact, depending on their bus factor. This could be a big setback, but may not be too bad if you have sufficient process in place. We’ll come back to process in future posts.
Even higher on the list is the setback that upsets one of the core assumptions of your app. In my experience, these often crop up later in the dev cycle or during beta. Perhaps it’s a feature that turns out to be completely superfluous or actively harmful. These types of problems are insidious: they may not feel like setbacks to everyone, the “solution” may just be a band-aid rather than a good long sit down to reassess the project or feature. I think the ultimate setback is that you build the app and no one uses it.
Even then, all is not lost. There’s always something in the pro column.
Just. Keep. Going.