Jon Reid
Technical Agile Coach / Coder / Author
I train iOS developers in technical agile practices.
…Because you can only be as agile as your code lets you be.
2 Decades of TDD
I have 21 years of experience doing unit testing and test-driven development (TDD) in Apple environments.
Unit Testing View Controllers
Many say that unit tests should be done on model objects only. But View Controllers lie at the center of iOS programming. Learning to unit test them will greatly expand your safety net.
Refactoring: The Secret Sauce
Refactoring isn’t just moving stuff around with your IDE. Refactoring is changing the design of your code in small, verified steps. The goal: to drive down the cost of change.
“Jon helped us with our actual codebase, impressing me with his skill of making impacting changes on a large codebase he had just seen.”
“Having Jon take us through his training and coaching proved to be eye-opening. His training has given our team the push to really start doing TDD right.”
“Jon Reid fills a huge void in the iOS community when it comes to unit-testing and quality.”
“Anyone who cares about unit testing for iOS would benefit from Jon’s workshop.”
“The entire team came away energized and ready to apply all the learnings to our day-to-day work.”
“Jon made writing tests fun and enjoyable. We’ve significantly increased our test coverage.”
“Jon listened to our goals, learned about how we work, and created a great day of interactive and relevant content that our devs are actively applying.”
Photo courtesy of NSSpain
I’m a trainer and coach with Industrial Logic. You can read my official bio there, or get the juicy details below.
I’ve worked on a few iOS apps. I mention this here to make it clear that when I talk about test-driven development and agility in iOS apps, I do so from actual experience.
I’m the author of iOS Unit Testing By Example: XCTest Tips and Techniques using Swift.
One way to quickly learn about a developer is to peek at books they’ve read, and tools they’ve created.
These days, I post new articles around once a month. Here are a couple of my favorite posts. They both have short videos, and give you a feel for my style and content:
The 3 Laws of TDD: Focus on One Thing at a Time
When I was first learning test-driven development (TDD), I’d try to get to the First Step (a failing test) by writing a fully-formed test. But it often took a lot fiddling to get that test to run and fail. Sometimes this was because the production code took several steps to set up. Sometimes it was
Refactoring Demo: Is It More than Just Changing Stuff?
Refactoring. It’s a word I hear quite a bit. Usually, in the context of conversations with management, it means, “Rewriting that thing. Hopefully without introducing bugs.” Often, among developers, it means, “One of the options in the Refactoring menu in my IDE.” Table of Contents Tools vs. DisciplineRefactoring Demo ScreencastDo You Have the Refactoring Book?
My Story Starts with Being Fired
I worked at a Fortune 100 company. I was a member of a team responsible for maintaining a touchy framework. The code was brittle, and getting worse. Making successful changes became harder, and took longer. The team was afraid to touch the code, never knowing what else would break.
We tried to communicate these problems, but this made us look bad. Eventually, the company fired the entire team.
I Began Learning How to Create Safety
But before I was fired, in the midst of chaotic code, I began carving out areas of safety. This led to a series of happy chances:
- I learned more about Object-Oriented Design. (These days, I think folks call it “Modeling.”)
- This got me studying the Design Patterns book by the “Gang of Four.”
- I eagerly searched for more resources on Design Patterns. This led me to a website where programmers were actively discussing them. (This was a brand-new type of site where anyone could change any page — the very first wiki. I became excited about wikis, and created the first wiki sites within the company.)
- As it happens, the first wiki attracted discussion about three topics… One was exploring communication patterns in a wiki. Another was exploring Design Patterns. And yet another was exploring this thing called Extreme Programming.
Stumbling Across Extreme Programming Changed Me
Extreme Programming (XP) was “agile” before that term became popular. It was a set of values, practices, and feedback loops. extremeprogramming.org became my guide to a way of developing software that looked safe and sane. …It’s kind of nutty, since I wasn’t on a team that practiced XP. But I took what I was learning and applied it as best I could, on my own.
- I learned about unit testing.
- I wrote a unit testing framework. Back then, there was no platform support for unit testing frameworks, so you just used whatever you could find or make. Making my own unit testing framework taught me a lot about how they work. This was my first foray into discovering how tooling could make test code easier to write and manage.
- When I had a chance to work on a greenfield project, I took my first stab at doing it test-first. This was nowhere near the disciplines of Test-Driven Development I’ve since learned. But it was a start!
- I attended SD, the software development conference hosted by Dr. Dobb’s. There, I listened to Martin Fowler introduce his new book Refactoring. The talk was riveting: how to safely change software by following predetermined recipes. I immediately bought a copy on the spot.
- There was a problem with Refactoring: it presumed the existence of unit tests. This helped me with the greenfield project, but what could I do about legacy code? Along came another book: Working Effectively with Legacy Code by Michael Feathers. This book gave me techniques for making existing code testable.
Once I learned how to add unit tests to legacy code, everything opened up. Here’s a peek at my bookshelf, with the programming books that have influenced me the most.
Better Languages, Frameworks, and Platforms
So far, all of this was in C++. I’d carried a long wish to work with Smalltalk. Barring that, my next long wish was to work on NextStep, with Objective-C (which is the language part of Smalltalk, expressed in C). And wouldn’t you know it… Steve Jobs was back at Apple, and he brought NeXT with him.
Studying about mock objects led me to jMock. The matcher library Hamcrest was extracted out of jMock. So I wrote OCHamcrest, an Objective-C port of Hamcrest.
I had one gig working on Mac & Windows. Mac was Cocoa, Windows was .NET. Looking into the unit testing frameworks for .NET, I chose NUnit. (A decade later, I still think of NUnit features that the Apple team has yet to deliver in XCTest.)
Then iOS happened. At the time, there were two competing unit testing frameworks: SenTestingKit and GHUnit, each with their advantages. (Apple eventually adopted SenTestingKit, rebranding it as OCUnit. Eventually, this became XCTest.)
Then I tried different approaches to mock objects. OCMock existed by then, patterned after jMock. But a friend pointed me to an alternative called Mockito. It offered tests that were both more readable and less fragile. So I wrote OCMockito, an Objective-C port of Mockito that used the matchers of OCHamcrest. (Here’s a page collecting the various tools I’ve made.)
Lately, I’ve been working in Swift, of course. I was at another Fortune 100 company before becoming a full-time coach. Everything about coding feels so different from when that first company fired our team.
Blogging, Speaking, Teaching, Coaching
I started the Quality Coding blog. I started giving talks at my workplace. Eventually, I was tapped to teach Test-Driven Development to all new engineering hires at the main eBay campus.
And then, Mobile Central Europe — a new conference in Warsaw — asked me to come and speak. They took a gamble, since I hadn’t done any speaking outside my workplace. I discovered that I loved it. Apparently, in spite all my “ahs” and “ums”, I was pretty good at it, too: the conference voted me as “Best Speaker”.
Since then, I’ve spoken at the following conferences and meetups. (Here’s a page collecting my recorded talks.)
- SoftGeeks (2021)
- CocoaHeads NL (2020)
- Silicon Valley Code Camp 2019
- AltConf 2019
- Swift by Northwest 2018
- Next Door Conf 2018
- Silicon Valley Engineering Leadership Community (2018)
- Swift by Northwest 2017
- Silicon Valley Code Camp 2017
- CocoaConf Chicago 2017
- try! Swift Tokyo 2017
- CocoaConf San Jose 2016
- #Pragma Conference 2016
- MCE^3 (2016)
- CocoaPods Test Jam (2014)
- CocoaConf San Jose 2014
- NSSpain 2014
- iOSDevUK 2014
- eBay Tech Talk Berlin (2014)
- Mobile Central Europe (2014)
Photo courtesy of Natasha Murashev @NatashaTheRobot
I began teaching a workshop to get iOS developers started with Test-Driven Development. It started as a half-day. Then became a full day. Now it’s two days. The workshop is hands-on in a big way, with active involvement from everyone. I think it’s a blast.
Now I’m also offering additional services to individuals and teams. Because what matters is your team, your code, and achieving breakthroughs in the challenges you face.
Jon was voted as the best speaker of the first MCE conference. He is easily one of the best presenters I have seen at technology conferences. I highly recommend Jon as speaker and teacher!
In addition to all the content, experience, teaching skills — Jon also has a great personality that allows him to build relationship with people quickly, making his trainings and presentations more personable and approachable.
Jarek Potiuk — Principal Software Engineer