General Assembly

"I can't keep doing this anymore."

An exhausted instructor confided this during the first global meetup I organized. Around the room, heads nodded. I had gathered instructors from across General Assembly's 14 global markets, and everyone felt it. Each was teaching the same flagship Web Development Immersive course, but in drastically different ways, with different technologies, entirely self-built materials.

New York was teaching Ruby on Rails. London was teaching PHP. Singapore was teaching outdated JavaScript. Sydney had modern React but no backend curriculum. Berlin was teaching something else entirely.

The lack of a unified curriculum wasn't just burning out teachers—it was failing thousands of students paying $15,000 for what was supposed to be the same program.

I loved teaching at General Assembly. The students, the energy, the transformation of watching someone who couldn't code learn to build actual working software in 12 weeks. But I was frustrated by the inefficiency and disorganization.

Every time I taught, I started with a rough outline of what needed to be covered and had to fill in the blanks myself. Write the lessons, create the examples, build the starter code, write the solutions, figure out how to teach concepts I'd never taught before. Everyone was doing this, independently, reinventing the same wheels in 14 cities simultaneously.

It was exhausting. And it felt wrong.

I have this internal drive to build great systems. When I see inefficiency—when I see people working harder than they need to because the system itself is broken—I want to fix it. And I knew I could.

When the opportunity came to redesign the entire curriculum, I saw it as a chance to build something that would actually support instructors and serve students well. Obviously I'd never written a curriculum before. My only experience in writing lessons was the past few months of having to create them for myself. But I'm constantly taking on challenges I don't know how to do. That's part of being a designer or developer or creative at all.

I knew I was capable. And I knew this needed to exist.

The first phase was research. Two to three months of daily meetings with instructors around the world. I organized conferences bringing people together who'd never met their counterparts in other cities. I talked to teachers in New York and London and Singapore and Sydney and Berlin, learning how each approached the same material.

Everyone had developed innovations in isolation. Some brilliant, some less so. I was looking for patterns—what worked, what didn't, what students struggled with consistently, what employers actually needed from graduates.

I wasn't just learning how they taught. I was learning why their individual approaches existed. The instructor in London teaching PHP had valid reasons—the local job market. The instructor in Singapore teaching outdated JavaScript was working with legacy curriculum no one had updated. The instructor in Sydney teaching React without backend hadn't been given resources to develop the full stack.

The research revealed something important: the problem wasn't incompetent instructors. It was lack of infrastructure. Every teacher was doing their best with what they had, which was essentially nothing.

The breakthrough came after all this research, all these conversations, all this deep thoughtful contemplation about the best way to approach such a massive amount of potential material.

It revealed itself almost like a sculptor working with marble—the idea was in there, I just had to find it.

I'd been learning about instructional design concepts. Scaffolding—building complexity progressively. "I do, you do, we do"—demonstration followed by practice. Learning by doing, not just consuming information.

And I'd been thinking about my own journey learning to code, learning typography, learning anything. The best learning happens when you feel the pain that a tool solves. You don't appreciate React until you've tried to build a complex UI with vanilla JavaScript and felt it become unmaintainable. You don't understand why frameworks exist until you've hardcoded the same navigation across 20 HTML files and needed to change it.

What if the curriculum mirrored the evolution of web development itself?

Students would build static sites in HTML/CSS and experience firsthand the pain of updating multiple pages. That frustration would make them receptive to learning frameworks. They'd struggle with authentication and data sharing, which would make the value of APIs immediately clear. They'd hit the limitations of vanilla JavaScript, creating genuine appreciation for React.

This wasn't just teaching technologies. It was helping students feel the real-world problems these tools were created to solve.

The framework felt inevitable once I saw it. Of course this is how you'd teach web development—by letting people discover why each tool exists through the friction of working without it.

With the framework clear, the work became: build it.

110,000 words of educational content. 365,000 lines of starter and solution code. Complete curriculum for 12 weeks of intensive learning.

I spent several months on this, mostly solo. I'd broken the concept down into modules and overarching themes, then into specific lessons, weaving in all the technologies I'd promised: HTML, CSS, JavaScript, React, Node.js, Express, PostgreSQL, MongoDB, authentication, deployment.

For each lesson, I wrote the explanation, created the examples, built starter code that students would begin with, wrote complete solution code showing best practices. I wanted every lesson to feel conversational—like I was teaching it in person—but also technically precise. Bugs in student starter code are devastating. Students blame themselves when code doesn't work.

I contracted out maybe 25% of the lessons to other instructors, but I was still leading those—reviewing, giving notes, ensuring consistency. The curriculum needed to feel like it came from one coherent vision, not a committee.

Some lessons required creative problem-solving. Like SQL.

How do you make database queries interesting to beginners? I turned it into a Carmen Sandiego game. Students had to query through a database to find Carmen around the world using clues: "So I'm off to add one to the population I find / In a city of ninety-one thousand and now, eighty five." They had to figure out which city had a population of 91,084—because Carmen just arrived, making it 91,085.

It made what could have been dry technical content into an experience people actually enjoyed.

The bigger challenge was teaching design.

The higher-ups wanted me to teach these future developers about design—typography, grids, visual hierarchy, all of it. This is a difficult ask. I don't necessarily know how great design works in a way I can articulate systematically. I just know some tools and principles.

I struggled with this for a bit. Then I realized: maybe the way to teach design isn't to lecture about it. Maybe it's to get them to do it and, more importantly, learn the art of critique.

I created this exercise where students spent a short time designing something in the browser with the tools they already knew—HTML, CSS, nothing new to learn. Then I had them set up their work on their desks and break into small groups.

The walls were painted with whiteboard paint. Groups went from station to station, writing on the walls around each desk: Why do you think the designer made this choice? What's working about this design and why? What could be stronger and why?

Heavy emphasis on the why. Not "I don't like this color" but "This color creates low contrast with the background, making the text harder to read, which might make users miss important information."

Then we reconvened as one group. I led everyone station by station, discussing what people had assumed about the design choices and the psychology behind visual decisions.

The feedback was overwhelmingly positive. People said it gave design new light—that it wasn't just about making something pretty, but about the psychology behind the visual choices you're making.

This is the kind of innovation that was happening in isolation before. Now it could be shared globally.

Launching the curriculum across 14 markets wasn't a simple rollout.

A lot of the biggest markets had instructors who'd spent years developing their own materials. They had pride in what they'd built. And now here I was, coming back from months of development with polished materials and—from their perspective—handing it down from above.

There was resistance. I understood it. These were talented teachers who'd been fending for themselves, and suddenly I was telling them to teach from my curriculum.

I took a grassroots approach. Instead of mandating adoption, I reconnected individually with instructors I'd met during the research phase. I talked through the materials with them, got their buy-in, incorporated their feedback, made them feel like collaborators rather than recipients.

This took time. But it worked. The curriculum launched in phases—pilot markets first, then regional expansion, then global implementation. Each phase revealed what needed adjustment. And instructors started contributing back—submitting improvements, sharing teaching innovations, building the collaboration culture I'd hoped for.

The curriculum became a living system. Not just something I built and handed off, but something that continued evolving with contributions from teachers worldwide.

Six months before starting, I'd been one instructor in Philadelphia, struggling with the same broken system. Eighteen months later, eighty-five instructors across fourteen markets were teaching from the same coherent curriculum, contributing improvements back, sharing innovations globally.

The infrastructure continued beyond me. When I left, instructors kept improving it. The Slack channels stayed active. The monthly calls kept happening. New innovations got documented and shared. It became what I'd hoped: a living system that served everyone better than anyone could individually.

That pattern—seeing broken infrastructure, understanding deeply how it affects people, designing coherent systems that serve thousands while maintaining quality—shows up across everything I've built since. Whether it's education platforms serving students changing careers, emergency response systems protecting millions, or font platforms serving designers worldwide.

The context changes. The approach doesn't. When you see people working harder than they should because the infrastructure is broken, you build the systems that let them focus on what actually matters.