Brandon Passley had a problem. As CTO of VOKAL Interactive, a mobile app dev firm in Chicago, he was responsible for finding qualified developers to build his clients' apps. There weren't enough to meet the demand of his firm, much less dev firms in tech sectors around the world.

Sure, there were plenty of new college grads with computer science degrees, but they had never taken an app from concept through to submission to the App Store, and they didn't have practical experience working on an app dev team using Agile Development.

So he started looking for people who had a passion to learn coding but didn't know much about it, then he hired them and trained them on the job. That was the spark for creating Mobile Makers Academy: to help people get started in a career in tech, and to ease the dearth of coders in the marketplace.

True to his start-up mindset and his personal philosophy about the value of teamwork, Brandon formed a team of experts and within three months launched the pilot class. We sat down with Brandon to talk about the philosophy behind Mobile Makers Academy.

Q: Why is the Academy called Mobile Makers?

Brandon: We approach learning with the mentality that we're making things. Our general philosophy is not, “Go read this book; Go listen to this lecture,” it’s "Let’s work together to make this,” and, “We’re going to learn together through making stuff." That carries over to everything we do—even the tables in our space are made by hand.

The duck reminds Makers to talk through their challenges

The duck reminds Makers to talk through their challenges

Why is that important?

When I was in design school, we had to memorize a lot of details about different artists, and now I don't remember much about them, because there was never a time when I needed to apply what I studied. When you learn by making something, you use your hands and your brain; you're not just listening and memorizing, you're thinking about every step. The minute someone tells you to memorize a fact, it goes into rote memory and pretty soon it gets cleared out by the next thing.

The trick is actually to do the work, to have all these triggers going off, and to learn from experimentation and failure.


Yes, definitely! Learning from your failures as much as from your successes is vital. Every time you fail you realize what not to do. That frustration and the time you spent, you realize how to do it better; to make your time more efficient. For example, if I’m coding and I use a delegate the wrong way and it crashes, it hurts a little bit, but then I realize that I shouldn't do it that way again. If you touch a pot and it's hot, you'll find a different way to grab it next time. Not that you want to learn just from pain, but it builds on all the techniques you're learning.

Mobile Makers creates a safe place to experiment, to fail, and to succeed. And when our Makers succeed, when they figure out a tough challenge, sometimes they'll jump out of their seat, they're so pumped! That's what we look for in Makers—you have to enjoy problem-solving, to feed on frustration in order to get that feeling of excitement. Because coding is really challenging, and there are lots of ways to complete a problem.

How can you teach people how to do something where there are so many possible solutions?

Well, what you can't do is say there's just one right way. That's a real advantage of our iOS bootcamp-style program—you work intensely with a partner to solve a problem, then the teams come together and present their different solutions and talk about why they made the decisions they did. You can't get that in a class lecture, and you don't get that from watching videos or reading a book.

So when our Makers graduate, they may not know how to solve every problem that gets handed to them—even seasoned pros can't do that—but they know where to look for ideas, and they know how to think about what makes sense for that particular challenge.

Why do you have students pair up on challenges?

On Day One we tell them, "Talk to the duck. Expose your ignorance." That comes from a book by Andrew Hunt and David Thomas, The Pragmatic Programmer. They said when you get stuck on a problem, explain it in detail to a rubber duck, and in the process, you'll often answer your own question. We do have a symbolic rubber ducky in the studio, but we encourage Makers to talk through their challenges with each other. If one Maker is more advanced, then she can help her partner figure it out and at the same time, the explanation reinforces her knowledge as well.

It’s scary exposing your ignorance! We give you a safe place to try it out, so you’ll be confident asking questions on the job. Sure, with years of experience you’ll learn to write efficient code, but learning from others who have found a good solution will get you there a lot sooner.

In fact, we find the ability to talk about your ideas is just as important as knowing how to code. When you work on a team, as you will in a real app dev environment, you'll do some independent reading and research, but you’ll also need to talk about what you're doing so that everyone's part of the code syncs up. Pair programming gives you that skill.

A lot of your language sounds like it's from a dev shop

That's right. It's our expertise. We run Mobile Makers like a dev shop, not like a school where we just want students to get the work done. Colleges don't prepare people to communicate and collaborate, so we teach even CS students how to bridge the gap, or they won't have an advantage in the market.

This practice came out of the apprenticeship team we started at VOKAL. Apprentices built their portfolio, worked on a team, and it was understood that they were learning. So even as employees they could make mistakes and it was okay. We wanted Mobile Makers Academy to be your place to experiment and learn, so you have the confidence and the knowledge to go out and do it professionally.