"You never called any question impossible", said Harry, "until you had taken an actual clock and thought it about it for five minutes by the motion of the minute hand. Not five minutes metaphorically, five minutes by a physical clock.”
- Harry Potter and the Methods of Rationality
Last week I wrote about why I built Why Choose, this week will be about how. Since this was my first programming project, much of this will be about learning to code, but the approach was similar to how I try to learn most things. Spoiler: I had help.
Resources (the easy part)
I learned the basic concepts of coding in the fun ways, by playing with Human Resource Machine and Swift Playgrounds on my iPad. These got me comfortable enough with concepts like Control Flow and Functions that I could start imagining how my app might run.
After that, I took the Programming for non-programmers course on Lynda.com, and Beginning Table Views on raywenderlich.com, which got me over the hurdle of “code that works in a playground” to “code that actually does something on a device”.
From there, I started developing more skills using codewars.com, and moving to searching for things using Google, Stack Overflow, and so many blogs. There’s a ton of easy to absorb information out there, but most of it is useless until you know what you need.
Sidebar on codewars.com: If you’ve never used this before and you’re at all interested in programming, go try it. It uses a brilliant mechanism of giving you a puzzle to solve, then showing you everyone else’s solutions once you’ve solved it, with the best solutions upvoted. I haven’t seen anything more effective for learning advanced functions, since you’re exposed to them right at the moment that you most understand what they’re for.
I also came to love a bunch of iOS-development-specific podcasts, especially Swift over Coffee, Swift by Sundell, The Swift Community Podcast, and Under the Radar.
Having a puzzle to solve
I didn’t say they were good sketches.
I had tried to learn coding a couple of times in the past, but it was always with a desire to learn how computers work, not a desire to make something, so it never really took. If you’re considering learning to code, I would strongly recommend having a project in mind when you start. It’ll be much easier to pick a language, ask for help, and keep moving when you’re inevitably frustrated.
For Why Choose, I started with some sketches of the interface. Most of the logic of how a user would move through the app was decidable before I had written a line of code, plus once I had the sketches I wanted to make them real.
Kanban boards
With my problem in hand, I started breaking it down into very small todo items.
This step was one of the toughest.
Using a Kanban method, I prioritized those actions into a To Do list, which I re-arranged every day as priorities shifted. I moved one action at a time into a “Doing” board, then moved it into “Done” when it was completed.
With the complexity of any software, even something as simple as this project, I found that keeping focus on a single task was essential to keeping up momentum and working on the highest value tasks first. With very few exceptions, any time that I left this system I would bounce around aimlessly, or work on something easy but unnecessary.
Asking for help
When learning just about anything, it’s valuable to ask for help early and often. With programming specifically, there’s an amazing culture of sharing knowledge (mostly because everyone’s learning, too). If you know anyone who does any kind of programming, they’ll probably be happy to help if you ask (and if you’re already friends, they’ll probably be excited that they can talk about this stuff with you).
For me, once I had my basic problems laid out I would ask for help anytime that I was stuck for more than a few hours. Almost invariably the problem would be that there was a concept that I didn’t know the name for, and once I had that name I could find what I needed with standard searching. But the biggest leaps forward happened when I could meet in person with somebody. Seeing someone type revealed more about coding processes than any blog post or video I found (part of the trouble is that most of those tutorials show someone doing everything right the first time, so you never see someone doing even simple debugging, like using print statements to test where their code is breaking).
Sidebar on asking for help: It’s sometimes hard to admit that you don’t know something basic to an expert. To fight this tendency in myself, I often think back to a clinic I saw by renowned drum instructor Ed Soph, who taught some of the greatest drummers alive at the University of North Texas. He said something to the effect of, “when you see one of the greats doing something inhuman, remind yourself that at some point they didn’t know which end of the sticks to hold”.
Asking for more help
When I’m excited about something, I get hooked on talking to people about it, and it turns out that people who don’t write code don’t love talking about writing code, so I needed to make more friends.
First, I started attending programming events in Portland, especially making time for the Mob Programming workshop through AgilePDX. This also introduced me to the bigger AgilePDX world, including their fantastic Slack.
Then, taking the example of the hosts of The Swift Community Podcast, I wanted to find or start a Learn Swift community in Portland. I reached out to the hosts of PDX Cocoaheads to see about organizing Swift specific events where I could get to know other people who were figuring out how to make apps. Again, folks were eager to help, and these happy hour events have gone better than I could have dreamed. They’ve introduced me to fantastic developers, and given everyone who attends a window into how other people are approaching their own work.
Testing with real people
Version 0. I can’t even begin to tell you how proud of this I was.
As soon as I had anything to show people on this project I did. Friends got (probably way too many) texts of screenshots and short videos of functionality. This step accomplished two big things: I got rapid feedback on things like appearance and user experience while the project was still very malleable and I created some accountability for myself, since I wanted to get to the next thing I could show them as quickly as possible.
Once I had a version of the app that didn’t break as soon as anybody looked at it wrong, I started a public beta with Apple’s TestFlight. This was where development really accelerated, because I got meaningful feedback on how the app felt in people’s hands and what they wanted to use it for. The idea of the “mute” feature came straight out of hearing how people were using the app in their daily life, and seeing their annoyances with my first interface inspired a full redesign that consolidated three screens into one.
Plus, SOFTWARE I HAD WRITTEN WAS RUNNING ON OTHER PEOPLE’S PHONES!!!
Thinking for five minutes
Drawing an icon was my favorite way to procrastinate.
People who have been writing code for years or decades will probably laugh at this understatement, but there are obstacles everywhere in programming. From planning out your approaches, to trying to different methods, to figuring out the mistakes you made that are breaking everything, to fighting bugs in your development environment, you’re just constantly running into walls that you have to figure out how to get over.
Besides asking for help, the most productive habit I developed was noting that I was stuck, then getting out a clock and really thinking about the problem for five full minutes before giving up or moving on to something else. This was my way of fighting substitution bias, or the habit of replacing a difficult question with one that's easier to answer. If you’ve never done a focusing exercise like this, you might be surprised to learn how quickly your mind wants to look away from things that are challenging, or how solvable many seemingly unsolvable problems are when you really think about them for five non-metaphorical minutes.
Paying it forward
This blog is one of the ways I’ve been trying to pay back all the help I’ve received over the last few months in getting my first app published. If you’d like to learn more, or want some help getting started yourself, feel free to reach out!
Up next: How I use Why Choose in my own life