I like to give my partner Aaron a bit of shit about his Objective-C code.
It’s the work of someone who’s only been wrapping his head around Objective-C for a year and a half – not someone who’s been using it full-time for four years. It’s copy-pasta, it’s poorly architected, it’s sometimes taking 400 steps to do something that could be done in two.
But here’s the thing: He’s building stuff. He’s making a UI that works.
Especially when working like a total pixel-perfectionist like him, for him to get a UI control looking exactly the way he wants to look saves us ages of time.
Because he’s taught himself enough Objective-C to be dangerous, he’s able to get something looking the way he wants it to look before I build something too clever to account for bits and pieces he wants to include but hadn’t realized he needed to mention.
We skip the part of design iteration where he sends me what he thinks he wants something to look like, then sends me endless tweaks.
Particularly since both of us now have full-time jobs and are currently working on Hum as a passion project, it’s hard for both of us to be available at the same time.
And when I’m stuck doing something like, to pick a 100% random example, taking ten months to get Dropbox sync working, he’s able to move forward on new UI features without me.
It does force us to set aside time to refactor. But his ability to actually get things reasonably working has somewhat broken me of the professional developer’s habit of wanting everything to be working as elegantly under the hood as it does on the surface before it goes out in to the world.
Users ultimately give a shit about whether something works. Does it allow them the control we intend in the design process? Is it elegant to interact with? Does it allow them to be more flexible than perhaps even we had intended? Does it give them the opportunity create with our app?
If a UI control is well architected, it’s obviously easier to maintain. But too often, I will allow the perfect to be the enemy of the good, and only release something when it is infinitely reusable and composable – and often too clever by half.
Working with Aaron has cemented my opinion that the best way to make apps is to bring together great design and solid development.
But it’s also taught me the importance of prototyping, and what a tremendous advantage any designer who has the temerity to learn how to code can bring to a project. It drives me batty from time to time (“OMG, why?! WHY DID YOU DO IT THIS WAY?!”), but his determination on stuff like this is why I put up with him.
Aaron, I’ll continue to give you shit about your code as long as we’re working on Hum. But I’m glad that despite that, you keep challenging both of us with your wackadoo ideas.
Some of which actually turn out to be pretty damn good.