Code Patterns Talk, Video Now Available

We’ve been trying to a better job of capturing our main talks at Philly CocoaHeads. You can find and subscribe to our small but growing collection of videos on Vimeo: https://vimeo.com/phillycocoa.

I did a talk last month reviewing a some iOS code patterns. The runtime is about 27 minutes. Feedback very welcome.

Some Code Patterns, Mike Zornek from Philly CocoaHeads on Vimeo.

This talk covers a handful of code patterns that were successful on my recent projects. Some of these patterns include Block Safety, "Tell, Don't Ask", Using DataSources for your network-based *Service objects.

Apologies the audience participation isn't well captured.

Farewell Edge Cases

Cue the Journey song, Edge Cases is ending.

Edge Cases was a podcast hosted by long time Apple developers Andrew Pontious and Wolf Rentzsch. Surprising unlike many other podcasts hosted by Apple developers, Edge Cases actually embraced the code, doing weekly non-topical coverage of coding concepts, practices and history. The show ends after 128 episodes and will be missed.

I’ve been following Wolf since the MacHack days and Andrew since the blogging boom of the early 2000s. Both are incredibly insightful and genuine. I want to thank them for putting on such a great show. The dedication it takes to run a regularly published podcast is no small feat and it was appreciated. I wish them well with their future projects.

If you haven’t listened to the Edge Cases show before I encourage you to browse the archives and give it a try. The content is timeless.

Know Your Role: Contractor or Consultant

I guess I could have use a more sophisticated reference in the title like Know Thyself but I can’t help quoting the most electrifying man in sports entertainment, The Rock.

The Rock

Know Your Role!

When trying to breakdown the relationship with your clients and to help define expectations you need to define your role. One high level way to do this is to decide if you are a contractor or a consultant.

A contractor is someone who comes on to a job site to execute. They are given all the specifications they need. They act in a professional manner. They produce.

A consultant may produce as well but their primary responsibility is help design the solution. They work with the client to understand, identify and document the problems and the pains. Then through their lens of their experience in the industry propose a solution. Usually they stick around to help build that solution.

If the client looks to you for help to build the product right, you are probably a contractor. If the client looks to you for help to build the right product, you are probably a consultant.


Personally, I consider myself a consultant. I love designing the solutions and while I can code, and continually strive to improve my craft, coding by itself is not truly fulfilling.

It’s been challenging over the last few years since leaving independent life and working for larger companies. These days I don’t have a lot of involvement in the sales process so by the time I’m working a project expectations are already set and a fair amount of time it feels like we are hired as contractors, which I have nothing against, but if I’m going to be a code mercenary you need to be really good about those specifications and more times than not, they fall short. They explain only the happy paths or they misuse platform norms at the cost of more engineering and two steps back in user experience.

I suspect this phenomena is not an isolated problem but discussion about that will have to wait for a future post.

Think of the Smallest Possible Code Change, and Then Make It Smaller

I’m working on a client project right now. We do peer review of the code via pull requests. It works great, but the quality of the reviews you get are very dependent on the size of the pull request you make.

Take for example, one of my recent pull requests, which had the following git characteristics:

1,780 additions 
1,618 subtractions
24 files changed

Not my largest pull request ever but still way larger than what I’d prefer. I got zero feedback. It was merged on first pass. Now take one I did the next day:

80 additions
1 subtraction
7 files changed

We had 10 conversation posts on this pull request, discussing three distinct recommendations and/or questions. Questions on things I was already doing for a few pull requests already but I guess slipped by.

I don’t blame the reviewer, I blame myself. It’s really hard to be detail focused when there is so much to review.

So keep those pull requests small and focused. You’ll get better feedback and you’ll probably get integrated faster too!