Rob Rix, Black Pixel

Rob Rix sm

Rob develops software at Black Pixel.

  • What do you currently do?

I’m a developer with Black Pixel, generally doing consulting, but occasionally doing some work on our products.

  • How did you get started in Mac and/or iOS programming?

When I was a child, my Dad had a copy of HyperCard, which you could make drawings in. Then I learned you could also add buttons, and text fields, and fill them with whatever information you needed to make a simple database. Then it turned out you could also program the behaviours of these things, animate elements, show icons, and so forth… and, armed with a couple of reference guides, I made all sorts of crazy programs until I hit the limit of what HyperCard could do in and of itself. By this point, it had really sunk in that someone *made* all the stuff that runs on a computer, and I could do that too.

Fast forwarding a few years, Apple released the public beta of Mac OS X. I installed it and Project Builder, pored over the Objective-C language references, and explored all sorts of things you could do with the Cocoa APIs. It was wonderful—anything that could be done, you could do here (it didn’t leave you with your hands tied), but you had the flexibility of a nice dynamic language and Cocoa, and so lots of otherwise very hard things were just within reach.

Then when Apple released the iPhone SDK, I didn’t own an iPhone or an iPod Touch, but I installed the SDK and got started on an app. A lot of it was familiar, but a lot of it was new and strange as well.

  • What was the first app you created and what did it do?

The first app I created and released—shipping is the real milestone, to my mind—was a graph paper drawing app called Litho Graph for the iPhone. It had square and triangular (iso) graph paper, and it snapped your lines to grid.

It was fun, and challenging—both technically (OpenGL, PDF drawing, a web server, some UX/UI challenges, and of course optimization—I ran it on a first gen iPod Touch!) and professionally (shipping is hard work—but it’s such important work).

  • Where did you get the idea for the app?

I often have a pad of graph paper at my desk, and I enjoy whitelines papers and notebooks. It’s a bit of a pain carrying around an A4 pad and a nice pen all the time, though, whereas an iPhone fits in your pocket. I knew I wanted to write an app, and I thought I might actually use this idea, so I bit the bullet and spent a month coding my heart out.

  • What went well? What could have gone better?

Actually writing the app went really well. Shipping it, too, really; even though I made my own icons! (I am not a designer.) But maintaining it went poorly, and I forgot that I would be handling the support load on top of my day job. Spending the time to build it was one thing, but the time to grow it into a business was another. In the end, it didn’t turn a profit… but it was an incredible learning experience.

Ultimately, I wish I could have spent the time it would have taken to make it really shine—especially on the iPad, where it really would have made up for the clumsiness of drawing with your fingertip.

  • What is your favorite among the apps you’ve developed?

If you’re talking about apps which I did (almost) entirely myself, then Grid, a window management app I wrote. It’s open source, now!

It’s my favourite because:

    • I use it every day
    • some of my friends use it
    • I shipped it! 🙂
    • my friend Scott Perry started contributing to my Haxcessibility framework, written for Grid, and released Switch; it’s really inspiring, being able to help someone else bootstrap their idea!
    • a real designer made the icons 🙂
    • and, finally, a few people told me that they would pay $15 for it. I’ve never charged for it, but it’s really great feedback to know that someone else values your hard work to that degree.

If you’re talking about apps I’ve worked on, then Kaleidoscope 2.0. It’s a fantastic tool, and although my contributions were relatively small, I’m proud of the work I did, and cherish the time I spent working on it, and even more so the experience of working with that team—by far the highlight of my career to date.

  • What advice do you have for young people who want to make apps?

Here are some things I wish I had learned when I was young, or which I did learn and which went well for me:

    • Surround yourself with people smarter than you. (Online friendships do count.)
    • Surround yourself with people who ship good work.
    • Never let the perfect be the enemy of the good. Or, otherwise put, make it work, then make it shine.
    • Fear of failure can prevent you from trying, and you need to try—and fail—in order to learn. The best way to combat this fear is to acclimatize yourself to it—so, fail. Try things, and when they don’t work, figure out why.
    • Reason on bugs and problems. Use the scientific method. Come up with a hypothesis as to what could be causing the error; test it, recording the results; re-evaluate the hypothesis in light of the results of the test; repeat. Don’t be afraid to just throw time at it.
    • Talent with effort is worth infinitely more than talent alone.
    • If you feel like you’re a faker, or an impostor, you’re not the only one.
    • Don’t invest ego in your code; do invest pride in it. You’re not the smartest kid in the class, but fortunately you don’t have to be the smartest kid in the class to shine so, so brightly.
    • It’s just the best feeling to work with people who are great at what they do—designers, QA engineers, project managers, other developers, everything. Don’t forget to tell them that from time to time.
    • It’s really hard to make a product, but it’s the kind of really hard that you can do by just chipping away at it bit by bit.
    • Know your tools inside and out.
    • Read the documentation. Write documentation for your own work.
    • Don’t couple your code to your specific use cases, but don’t generalize it too early, either.
    • Paired with that, if you don’t know how to solve a big general problem, solve a small specific instance of it, and work from there.
    • Complex, successful things are made of lots and lots of simple things.
    • Don’t fight the frameworks. You develop an intuition for this, gradually: if something feels like it’s too hard, there’s probably a better way.
    • Do not succumb to Not Invented Here syndrome: don’t be afraid to use other people’s work. But do be cautious about introducing dependencies; if you’re not sure about a third-party framework or service, ask a trusted colleague for their input.
    • Ask experienced, successful, trusted people to review your work. Ask questions about their feedback. Try applying it; does it make your code better? If so, why? If not, why? Did you understand the feedback correctly, or did the reviewer miss something? (This is where not investing ego comes in—it’s a liability when you’re trying to make a better product, rather than just make yourself feel smarter at the expense of your users.)

And most of all, play well with others. Humility and patience go so much further than ego and arrogance.

Follow Rob on Twitter and

Help more girls learn software development. Contribute to the App Camp For Girls Indiegogo fundraiser, get a cool perk, and enjoy the feeling of having helped the next generation of software developers.


One thought on “Rob Rix, Black Pixel

  1. Pingback: Rob Rix Interview | Martin

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s