Today I am one week into the running/instructing of a 4 week introductory course on iOS and Swift. It’s been such an awesome experience so far planning and executing this course, I wanted to capture the highlights and discuss some of the interesting things I’ve encountered.
It is meeting for 3 hours on Tuesday nights between 6:30-9:30 for the month of March.
So, full disclosure. I’m a woman. I’m a software engineer. There aren’t that many of us.. proportionally speaking! It’s long been a goal of mine to get more women into this field. I have many opinions on how this can be done. Convincing young girls that it is indeed a career option that makes sense for them is one of these. This, however, is a long game… Hugely important and we will continue to spread this message. But I won’t be coding alongside these individuals for ~10 years. How can I make a quicker impact?
I’ve been trying to find a way over the last 6 months. Early this year I had a discussion with a female colleague of mine who was telling me how she’s really like get into engineering.. specifically iOS app development. I said, that is awesome.. you should totally do it! She mentioned how it’s pretty hard to get off the ground with learning and that she’d really like a course-based setting. We started discussing sources for such courses Girl Develop It, Girls Who Code, etc… But she said they don’t frequently have iOS courses. I thought and said to her ‘I should teach one!’
I contacted Aurelia Moser of Girl Develop It the following week and was on my way to organizing their next iOS Intro course. (The last had been in early 2015.)
As this is a course dedicated to women learning iOS and programming… it should be organized and taught by women right? I found two awesome engineers to help out.
In organizing likely any introductory course, it’s difficult to draw a line with the amount of programming experience attendees should have. Also, the way Girl Develop It works is attendees sign-up like they would for any meet-up. I had thought if we could screen attendees, we could perhaps offer two courses. One for somewhat experienced coders trying to get into iOS and another for total programming newbies, looking to get into programming via iOS.
As it stands, we decided to just open it up and tell attendees that they should have some (if minimal) programming experience and should understand basic concepts like classes, functions, booleans, etc..
After the course filled up, we sent out a questionnaire to try to get a feeling for who the attendees were and what background they had. It turns out, not surprisingly, that we had gotten a pretty wide range of experience levels. From virtually totally new to programming.. to coming to iOS from a C++ development career.
My conclusion with prerequisites is that if you can’t enforce them, they’re just more of recommendations and you can’t count on everyone to match-up to them. We decided to acknowledge this disparate range in background and to perform frequent check-ins with attendees to make sure they’re getting what they came to get.
Lecture vs. Lab
Lectures are boring right? We decided to try to minimize these. With 1 introductory lecture in the first session overviewing the iOS framework as a whole and how it’s really just like any operating system… connecting apps to system resources. Beyond this, we wanted to focus mostly on labs.
Labs are more fluid and dynamic, but can also get bogged down in complexity if you’re not careful. We are trying an approach of doing mini labs.. so we do a little coding (5 min) over projected screen share, then hand it off to the attendees to try the same, with perhaps a slight elaboration.
Project vs. Focused Examples
We were initially playing around with the idea of have a course project where attendees would pick the problem/solution and design and build an app to address it over the course of the project.
We felt this would be powerful because attendees would leave with a real iOS app that they build on their phones at the end of the course. It would also demonstrate the process on a end-to-end.
So, after getting into session planning, we identified that it would be harder and harder to tie the material into everyones different projects. We decided to adjust our approach.
Attendees are being encouraged to still work on an individual project (if they choose) with our support should they need it. In class, we’re going to be doing focused mini projects that will tie together the content being covered in that particular class. This will hopefully ensure that everyone is taking away exactly what we planned.
The smaller the better! I had initially thought that the more attendees we can fit the better. Advice I received from other GDI instructors said keep it small.. especially since this is the first course I’m running. In a lab-based class, you apparently should target 4-5 attendees per lab instructor or assistant. This is the number we went with as we’ll have 5 instructors/lab assistants in total.
In our first session, our coding was fairly limited. We achieved a ‘Hello World’ example and then built a two screen application that would use a few UI elements like labels/buttons to show information and move the user between screens.
For session 2, we had to decide between going further into screen building and UI elements or diving into the Swift language. We’ve decided to go into Swift as using it and understanding it’s strengths will really propel a new iOS developer forward and accelerate overall learning (we believe). We shall see. The intention is to get as much feedback from the course attendees as possible to both frame sessions 3 & 4 but to also hopefully improve this course and offer it again!