As a result, I decided back in October that I would spend some of my time putting together a series of iOS workshops for the office. This came after a few colleagues expressed dissatisfaction with their understanding of coding and started asking, like I and so many others who have wandered down the garden path before, what language was best to learn.

While the language you learn doesn't really matter so long as it's interesting and useful to you*, I decided to hold a series of iOS workshops—four, in fact, since October—since that is with what I am familiar; and in the spirit of sharing, I've decided to share materials from these classes with you here under a Creative Commons license.

* I'd also recommend learning a programming language that's Turing Complete, like Python, Ruby, or Lisp, rather than a markup language like HTML or CSS, since they utilize important programming concepts that will help you learn and understand programmatic logic better.

That's right! Actually, I'm a Product Manager, and before that I was a UX researcher, and before that I was studying brain and cognitive sciences...but only after having switched from architecture :S Most importantly though, I was a physics TA in college and absolutely love teaching. So while I'm only an intermediate coder at best, I hope that I can at the minimum convey my enthusiasm for the art and the interesting concepts that make it work so that others who are interested will hopefully feel less hesitant to learn than I had felt.

For me, it wasn't until I started using MATLAB and helping classmates my Junior year that I finally began to build up the confidence that this might be something I could actually do. At Google I used Python to script tasks but struggled to build user interfaces so that others who didn't code could use my scripts themselves, and I spent far too many hours writing buggy code in JavaScript for a particularly tricky user research study. It wasn't until I decided, post-Google, that I would teach myself iOS development that it all finally started to make sense to me.

I decided that Objective-C and iOS were a good place to start because Objective-C is a full-featured and popular programming language and because iOS has lots of support communities and fantastic, if not still a little intimidating, documentation. Plus you can show off your creations to friends and family if you have an i-Device on hand :-)

The best way to learn is to have an attainable objective in mind. I recommend starting by building a simple game.

Class #1: Diving Head-first Into iOS Development

For my first class I wanted something we could all build within the hour and then refine in subsequent classes. As such, I had no PowerPoint or Keynote preso (thank goodness!) but instead a well-planned project that required a minimal amount of coding: Tic Tac Doge, a version of tic tac toe inspired by our office doges Klein and Tilly.

Above: Made by Many NYC's first Intro to iOS class! During this first session we built Tic Tac Doge, a version of tic tac toe inspired by our office doges. Tapping on a square alternates between placing an image of our New York office doge Klein and our London office doge Tilly, while tapping on "Clear" resets the board.

The class went very well. All but one participant was able to compile their code (and it turned out that Xcode just needed to be restarted for whatever reason). If you have Xcode installed on your computer, you can download and run the code for Tic Tac Doge yourself by clicking here.

Class #2: Intro to Objective-C

Our second class was an overview of Objective-C for iOS development that did have a PowerPoint (or rather, a Google Presentation). While I'm very much a critic of PowerPoints as a presentation tool, I felt is was necessary so that we could all have some documentation to refer back to if there were questions or confusions about a particular topic.

As for the content, I tried to cover the core concepts in Objective-C, from MVC architecture to delegates and protocols, and ended the class by returning to Xcode to point out where all of these concepts appeared in the code we wrote the previous week for TicTacDoge.

Above: Our code for class ViewController.h within our project TicTacDoge.xcode. You can download the code for yourself by clicking here.

Class #3: Adding Logic to TicTacDoge

Our third class was supposed to be a full-on workshop where we added features to TicTacDoge, but it turned out that participants were more interested in reviewing the material from the previous week, so I just did class 2 again.

Class #4: Intro to UIKit

For our most recent and fourth class, I assembled a deck outlining many of the key user interface classes provided within Apple's UIKit framework. Again, I made a Google Presentation so that we would have documentation to which to refer if we had any questions:

However, the deck worked fairly poorly, and the class became long and tedious. Instead of discussing each UI element individually, I think it would have been better to print out the deck and pair up everyone to practice identifying and hypothesizing what UI elements were used in existing apps and start utilizing them in TicTacDoge.

For me, learning to code was about communication, credibility, and curiosity. As a UX researcher back at Google, I had the fantastic opportunity to work directly with members of the research, design, business development, and engineering teams, but when it came to understanding and communicating the day-to-day needs and frustrations of my colleagues, I found that I lacked a lot of technical vocabulary. Simultaneously, I also found that there was a definite "hierarchy" in terms of engineering vs. everyone else (one that, thankfully, has received lots of attention and valid criticism since 2011 and is hopefully something we can all work to mitigate towards creating a more respectful and equal playing field). But most importantly, I learned to code because I was curious—and not to become a "10x engineer."

At Made by Many, I've had the incredible privilege and opportunity to work even more directly than I did at Google with a diverse and talented set of colleagues and friends. While I've found learning to code to be invaluable towards becoming a better Product Manager, I've also found it insufficient and am currently working to learn more about strategy, business, estimation, and how to be a better colleague. So while "becoming technical" probably shouldn't be a be-all and end-all, here are nevertheless a few reasons why you benefit from playing around in programming:

And as for myself? By holding these workshops, I myself have been forced to become better at coding, and I've also received valuable practice in structuring lessons, articulating value, and demonstrating proficiency in one of my core competencies.

There are a near-infinite number of topics I could talk about in future Intro to iOS classes, but I think a few topics are more interesting and useful than others for those who are merely interested in programming rather than looking to become expert programmers: