Failing harder, better, faster makes us stronger June 24, 2012 Tweet
I’ve been meaning to put together a talk on how failure is big part of being a software developer for a while. Sometimes we fear failure too much to a point of never moving forward, especially from intelligent perfectionists.
What inspired this blog post was a meeting I was having recently about helping high school students learn to program. Topics revolved around fear, lack of goals and inspiration. In thinking about how to conquer these issues I thought about how I go about solving programming problems when I want to accomplish something.
Recently, prior to the above meeting, I set out to redesign some slide decks for upcoming talks I was giving at Nordic Ruby and Scottish Ruby Conferences. I’ve had the thought to start making my slide decks using an HTML-based framework instead of my traditional use of Keynote. But there was one problem.
I rely heavily (probably too much) on Keynote’s presenter display feature. Specifically I have my presenter display configured to show me:
- The current slide
- The next slide
- Presenter notes
- The current time
- Time left in my presentation
Having this gives me the level of comfort I need to deliver a presentation that doesn’t completely suck.
HTML-based slide deck frameworks do not make affordances (that I know of) for presenter displays. It’s really not their problem to be honest. So in order get the best of both worlds I set out to make my own OS X program to give me this feature.
Now, I’m a Ruby programmer. At least that’s what I code in about 90% of the time. You can look at my github account and see that I do have a little bit of Objective-C/Cocoa code in there, but it’s by far not extensive or close to idiomatic. But I need to write some Objective-C/Cocoa to build what I want.
Enter “The Spike”
Generally, when I come to this point – not knowing enough about the language, runtime, API, build tools, etc – I split my problem into a couple small “spikes” to familiarize myself with the major aspects of potential solution that will come out the other end. In this I can [usually] focus on some small goals that will push me forward to an eventual final application that pulls everything together.
In this case there were two specific problems I wanted to spike to get better clarity on what I was doing and a start to see what the end of this tunnel might look like.
First, I needed to tackle the ability to put a window on a different display. So I opened up my OS X development environment – AppCode in this case as I am spiking out using IntelliJ’s OS X/iPhone development environment as well :) – and generated a basic project. Do a quick “Build & Run” to test that everything is working. Looks good.
Now I figure in order to put a window on a different display, I need to know what displays are available. Google to the rescue. I search for code to enumerate the list of displays. It takes looking at a few sites and digging through some forum replies (very typical) but I find what I need. I don’t need anything fancy to test this so I just throw the code into the application somewhere I know will be run at some point and
NSLog (print to the console) the stuff I need. BOOM! I have a list of display ids.
Now I need to know which display is a different display and which is the normal display. Some more googling and I find a class method for returning the “main screen”. Now I can compare the list of displays to the “main screen” value and I now know which is the “alternate display”.
Last here is to write some code to push my application’s window to the alternate display. Some more googling and I have some test code and an idea where to put it. “Build & Run” and we have lift-off!
Based on my understanding of what needs to be done to complete this entire project (deliverable code) I’m now about 20% done. This code of course will be re-written, better abstracted and tested in my yet-to-be-started “final project”.
If you’re curious the other spike I think I need in order to complete this is to have two seperate windows completely in sync with each other when the slide deck change events happen. I’ve started this one, but have yet to complete it. It’s certainly bigger (for me) than the first spike due to my lack of knowledge in how AppKit windows work. Perhaps there are some sub-spikes in there.
This concept of “the spike” is probably not new to most programmers. In fact it’s probably more like second-nature to many. I know that it has helped me many times in pushing through to a solution. Breaking problems up like this allows you to setup a framework for failure that will guide you to make better decisions.
Maybe you’re taking the wrong approach? Maybe your thing is actually ten smaller things? Maybe you shouldn’t be building that thing at all? These may seem like negative things, but not solving these issues is paralysis and too many times we fail to realize we’re paralyzed. Paralysis is usually way worse than being wrong.
- Don’t be afraid to fail. Failure will set you free and you’ll be better for it.
- Break your problem into small chunks. This applies at every scale in your projects, but picking the smallest, quickest thing that could fail will help you forge better paths.
- Don’t get bogged down in the details. In my example, an OS X application, it’s easy to get paralyzed with where the right place for code to go, especially for someone who is new to OS X programming. This is usually unimportant in a spike. Just make it work.
- “Throw away” your code. It’s likely your code needs re-working or better abstraction to go in your application. Give it the respect it deserves. If your spike solves a previously unsolved or hard to search problem, consider open sourcing it!
- Don’t be afraid to ask for help. Go to a user group. Ask a question on a forum. Pair program with someone.
- Dave Hoover calls this “breakable toys”. If you’re discovering these kinds of things, you should consider buying his book “Apprenticeship Patterns”