My takeaways from a day with Mattt Thompson

My takeaways from a day with Mattt Thompson

October 24th, 2013

In the world of iOS development, there are a few names that everybody knows. Mattt Thompson is one of them. For good reasons too: he writes good open source software and publishes insightful articles on his NSHipster blog.

This month's CocoaheadsNL meeting - a monthly meeting of iOS and Mac developers that we also like to host from time to time - was probably sold out the quickest so far. Mattt was announced to give a talk on AFNetworking 2.0, the new version of his most popular project.

The next day, Christian and I would join a small group of developers to spend the day with Mattt. In this post, I discuss my takeaways.

The Third Wave

We are part of the Third Wave of Object-C development. After the NeXTSTEP days and OS X development, iOS developers are now the driving factor behind the Objective-C ecosystem. An ecosystem that is defined by vigorous use of Open Source (thanks to CocoaPods), better tooling (e.g. Reveal, xctool) and borrowing the good ideas from other programming languages and persuasions.

Two Open Source projects have been published out of Touchwonders, but nothing too recent. We do have an internal CocoaPods repository, which houses a growing number of reusable components. That's also the proper place for your swiss army knife class category pod, according to Mattt, keeping it off the growing list in the main repository.

Company culture

Mattt is Mobile Lead at Heroku, a San Francisco-based cloud application platform provider. He explained how they, a company of 130 employees, get things done and collaborate around the office. Like us, they have a weekly all-hands meeting to keep everyone informed on the company. They also have a meeting-less thursday (known as Maker's day), ensuring a full day of uninterrupted focus on making things, which sounds like a great productivity win. On top of that, they have a strict headphones 'do not disturb' policy in place: if a person is wearing headphones, he or she should not be disturbed.

At Touchwonders, we have an open plan office and love it for the barrier-less collaboration, lively discussions and continuous interaction between developers and designers as we work toward the next great app we're building together. There is however a trade-off between that and individual productivity. I guess it is healthy to revisit the set balance from time to time and see if something else, e.g. the headphone rule, makes more sense.

Worst practices

A good way to learn how to code better, is to look at bad, or even worst, practices. Mattt talked us through a bunch of them: magic numbers, literal strings, shibboleths, typedef-ing block parameters and the like. We've been avoiding most of them, but I can't say that I'm completely innocent. Until now, of course!

Whether some practices are good or bad (or worst) comes down to taste. But forget about taste and let us agree with Mattt that, above all, consistency is what matters most. Choose a style and stick with it. Since we're the Third Wave and all, we might as well lend a great idea from Go and use a tool as the definitive ruling on code formatting. I would use that.

Pragmatic testing

Objective-C developers are not of the unit testing kind by nature. However, recently there has been an increasing amount of nurture going on in this area. Probably inspired by other programming languages, a great number of relatively new frameworks now help us mature in our testing practices. At Touchwonders, we use Apple's XCTest unit testing framework and Nocilla to stub network requests. Mattt uses Expecta in the AFNetworking unit tests, to test requests and Travis to run them on, as part of continuous integration.

I've been working to up our game in automated unit testing. However, writing and maintaining unit tests is a big investment. One that, I believe, is worth it, but a big investment nonetheless. Mattt suggested a mix between automated and manual testing. The automated tests should complement the manual testing and cover the parts that are harder or less likely to be tested manually.

I am definitely going to try a tool by Jonathan Penn that Matt suggested. UI AutoMonkey performs the activity of monkey testing for you. Instead of tapping on your iDevice like a maniac, and rotating and shaking it, run UI AutoMonkey with the UI Automation instrument and watch your app break. Then fix it!

Testing my NSHipsterness

From time to time, and city to city, Mattt hosts his notorious NSHipster pub quiz, challenging the contestants on their knowledge of obscure facts related to Objective-C, Cocoa, Mac and iOS development. He prepared a special NSHipster pop quiz (that's pub quiz without the beer) for us to despair over. It painfully showed my dependance on Google, Stack Overflow and Apple documentation.

"What is the name of that method on class such and such that does so and so?" Normally, the answer is just a button press away, but with only pen and paper at my disposal, the answer was often nowhere to be found. In the end, everybody did equally bad and that makes for a comforting closing remark.

Thanks to Mattt Thompson for an inspiring day!