For the past five months, I’ve worked at three of Flatiron School’s new campuses. Starting in March I spent three months in Washington, DC at our first new campus. From there I ventured to Dumbo where I worked at Access Labs, a tuition-deferred program in Brooklyn powered by Flatiron School. After three weeks at our London campus, I am now back at Access Labs. Being part of so many new campuses was exhilarating and exhausting. Every day we were making decisions that would impact the way these campuses would grow and run in the future. Fortunately we had Flatiron School’s values as our North Star, guiding all the work we did.
Scrappiness factored into everything we did at the new campuses. As we built out staff and space, we had to flexibly modify plans to meet the limitations of each campus. For the first six weeks in DC, we used an open area as a lecture space while the actual classrooms were being built out. We regularly worked around AV issues and had to find ways to engage our students using the advantages we had (like a high teacher-to-student ratio).
Since we didn’t have every role filled immediately at new campuses, it wasn’t always clear who was responsible for what duties. As an organization grows, it is common for roles to become blurred as things shift and change. This was also complicated by the fact that Flatiron is now owned by WeWork, so operations were split between the two. Since we were setting up campuses inside existing WeWork locations, WeWork was be responsible for building out the space but Flatiron handled the day-to-day campus operations. Figuring out these boundaries took time, but the next campuses now have a better framework to operate within.
Throughout all this change, the most important thing we learned was to keep communication open. At these new campuses we would have meetings with team members based out of Flatiron HQ several times a week. This was easier in some locations (DC) than others (London). Pairing consistent communication with a good attitude and a willingness to do whatever was needed made our new campus openings a success.
Our students are at a very vulnerable point in their lives. They’ve entrusted us with their careers (and their tuition) and sometimes they just need to be reminded that we are taking care of them. At an established campus, students interact with more advanced students and even alumni which reinforces their faith in the process. In fact many of our New York students know someone who went through the program, so they already know that Flatiron works before they apply.
In new locations our challenge was to create that same reputation through events at Flatiron and in the community. Some of these events were workshops, some were coding sessions and many just ended up as informal information sessions. At the core of every question an applicant asked at these events was the real question: is this the right path for me? In these new locations, applicants didn’t have the benefit of hearing about a friend’s Flatiron experience, so the instructors and students would share stories about what led them to Flatiron.
When prospective students ask what I like best about Flatiron, I always say the community. I came to Flatiron to change my career, but I was surprised by how much I’ve enjoyed the connections I’ve made here. However, it is better to let applicants experience this for themselves by interacting with students and staff.
A big part of what we teach at Flatiron is how to be a developer. Our job isn’t just to teach students how to code, but to teach students how to learn. One means to that end is by modeling good developer behaviors for our students. We demonstrate for them how to approach errors, debug and when to ask for help on the job. By watching our troubleshooting processes, we are giving them something to emulate.
As someone who has only been coding for a few years, I regularly get stumped. When this happens I admit it, make an educated guess and follow-up afterwards. While I might feel guilty for not having all the answers, students thank me for sending out helpful resources to them after the fact.
Another good behavior I model is blogging. Flatiron’s technical blog requirement is the least popular part of the program, but I have had students get jobs from their blogs. When I learn something new, I frequently will blog about it. It helps me work through concepts and it serves as a reference for me (or my students) in the future. If the topic is complex or obscure enough, I will undoubtedly need a refresher at some point.
The journey of becoming a programmer doesn’t end with Flatiron. We will all encounter new languages, libraries or dependencies at every job. However, if we follow good patterns, the learning process will continue to get easier and easier at every step along the way.
In addition to blogging, pair programming is one of the techniques we frequently employ to help students learn. We discuss the benefits of pairing with them in the first few weeks of Flatiron. I can’t tell you how many times students have come to me with questions and realized the answer while they were explaining the problem.
Rubber Duck debugging is just one of the benefits of pair programming. When reading your code to another person, you tend to notice things that you missed previously. Pairing also means students get immediate feedback on their code and can avoid inefficient patterns or ‘code smells’.
As a corollary to this value, we also tend to quote an African proverb when talking to our students about working together:
If you want to go fast, go alone. If you want to go far, go together. Pairing may not feel like the quickest method, but students will get more out of it in the long run.
I have become a better programmer and communicator from all my experiences while teaching. I’ve gotten used to different student populations and become more conscious of my examples and language. If I work with a student who sees code differently than I do, I can learn from that experience and apply it to my future work in teams.
Make No Little Plans
I’ve been part of establishing three new Flatiron campuses, but we have plans to open many more. How do we scale this success? By building a lot of new infrastructure and documentation.
Part of opening new campuses included documenting the things that worked and the things that didn’t. Prior to our expansion, we didn’t have to think in the same way about managing operations. Now that we are expanding, getting new instructors up to speed is one of the biggest hurdles we face. As experienced developers they can all easily learn the languages we teach, but they also have to learn how we teach them and what parts of the curriculum students struggle with the most.
For the instructors this means documenting our lectures and our processes. We teach something, then we make notes about how we did it. If there is any divergence among us, we try to reach a consensus. (And we can spend a lot of time debating how and what we teach.)
Our curriculum isn’t set in stone, though. As someone who went through Flatiron a few years ago, I can tell you we have built iteratively on our education and students exit the program now with much greater competency than they did a few years ago. Being at a smaller campus gives us the opportunity to test different project guidelines, lecture schedules or lecture content. The opportunity to test things and get quicker feedback means that our program will improve at an even faster rate now.
I’ve enjoyed defining the processes our education team uses going forward. I’ve had the privilege to see Flatiron from multiple perspectives (as a student, a junior instructor, an engineer and a senior instructor). Flatiron has changed my career and I’m happy to pay that back with my knowledge and experience.