I've attended a lot of engineering meetups and demo nights in my 15-year career in tech. But last night was the first time I've ever demoed or spoke live about my process as a builder.
At the AI Engineering Meetup hosted by Tribute Labs and held at Union Square Ventures, I led a 25-minute workshop on my process for building an AI-native business, in an AI-native way.
As a non-classically trained engineer, it still feels like a surprise to me that I've been able to get as far as I have in starting a tech company without coding. So, as an unlikely builder during an unusual time in tech, I leaned into the opportunity to do things a little bit differently.
My talk is affectionately named "Cowgirl Coding" based off a blog post I wrote a few weeks ago with the same title. (It really does feel like shooting from the hip sometimes... it's the Wild West out there.)
In the presentation, I discuss how I built (and more important, how I iterate and improve upon) MuseKat, an interactive learning app that helps parents and kids explore museums through customizable audio stories.
For example, in this slide I share what my current "AI Tech Stack" looks like for various part of my prototyping and building process:
But the other thing I did was share a work-in-progress "learning framework" for a theory I've been developing about how our individual learning styles shape how we learn, apply, and problem solve with AI.
I give a bunch more examples in the talk itself, but to give you a primer, the four learning styles that I cover are:
At one point during the presentation, I thought it'd be fun to show the room in real time how I go through a debugging process as a non-engineer using no-code tools.
Here's a photo of me watching Devin.ai (an AI that helps with engineering and bug fixes) attempt to fix a CSS error on my site. (Spoiler: We didn't land the fix on the first try, but it was still really fun to show my process in real time.)
One of the things I was curious about in an AI-engineering era is what percent of people in the room would be technical vs. non-technical at last night's meetup.
Last night, about 2/3 of the people in the room considered themselves to be "classically trained" engineers; the other 1/3 were not. I'd like to see even more of the latter. And I imagine in the months ahead, we're going to see a lot more of that.
But this does mean we need to shift our behaviors around engineering meetups more broadly to facilitate a growing, more inclusive audience of builders.
Encourage two types of demos at each meetup–one from the non-technical perspective and one from the technical perspective.
What made last night so fun was that there was something for everyone. I presented first about my experience in this no-code, coding world. And then another builder, Brexton Pham, spoke about his process of building Ohara and many provocative and much deeper technological takes about the future of building as a technologist in an AI-native world. This was a great blueprint for future meetups, and I'd like to see this behavior normalized at other tech gatherings.
In messaging, try out different words for "AI Engineer." See how it impacts the profile of who shows up.
Look, I've been going to tech meetups for over a decade. So I'm used to being one of only a handful of women in the room. But if there's any compelling factor to flip this dynamic, it's AI. Given all that, I was surprised to (still) see so few women builders in the room, and I'd really like to see that change. One idea would be to experiment with the messaging: "AI Engineer" is still a new term. I wonder if a more diverse audience would turn out with different phrasing. Some ideas to try: AI Builders, AI Hackers, AI Tinkerers, AI Makers, AI Innovators, AI Architects.
Stop hosting meetups on Friday nights. And stop hosting hackathons only on weekends.
As a parent, this is a major pet peeve of mine. The number of Friday night tech meetups and all-day Saturday hackathons that I'm consistently seeing (and missing) due to my familial obligations as a parent is frustrating. If you're going to invite people to an all-day hackathon, you should also invite them to bring their kids (and have some kid builder time to coincide with that). Or don't host every hackathon on a Saturday. It's a siloed way of ensuring you're only catering to an audience that fits a certain profile. And as everybody has already pointed out, that profile is changing. Fast.
Start showing up.
For everyone else–no matter what stage of the AI builder experience you consider yourself to be in right now, you need to start showing up at these meetups and events. After all, the only way to change the system is to be a part of the change. So I hope to see you at the next one.
By the way - I'd like to host this talk again (either IRL or virtually) for an audience that skews more heavily toward the non-technical AI builder. So if you're looking for a speaker for an upcoming event (or want to team up with me on something), give a shout, and let's make it happen.
Over 500 subscribers
I've attended a lot of engineering meetups and demo nights in my 15-year career in tech. But last night was the first time I've ever demoed or spoke live about my process as a builder. Naturally, I had to write about it: https://hardmodefirst.xyz/live-no-code-debuging-and-the-changing-profile-of-the-new-ai-engineer
In the presentation (affectionately named "Cowgirl Coding," I discuss how I built (and more important, how I iterate and improve upon) MuseKat, an interactive learning app that helps parents and kids explore museums through customizable audio stories.
For example, in this slide I share what my current "AI Tech Stack" looks like for various part of my prototyping and building process:
But the other thing I did was share a work-in-progress "learning framework" for a theory I've been developing about how our individual learning styles shape how we learn, apply, and problem solve with AI. Here's the crux: