Naomi Carrigan

I worked somewhere once where it felt like a male-dominated team. More specifically it felt like ideas from the women and enby folk on the team, including mine, were dismissed at a higher rate than my male colleagues.

When I was asked for feedback on my way out, I raised this directly, as one of several points. I care about it because I want to take barriers down for the people who come after me.

I worked somewhere once where it felt like a male-dominated team. More specifically it felt like ideas from the women and enby folk on the team, including mine, were dismissed at a higher rate than my male colleagues.

Ask for input in writing before the meeting, so every idea is on the record before anyone can talk over it. Name credit out loud. When an idea is adopted, say whose it was. Credit is cheap to give and expensive to lose.

I worked somewhere once where it felt like a male-dominated team. More specifically it felt like ideas from the women and enby folk on the team, including mine, were dismissed at a higher rate than my male colleagues.

A feeling is not proof. It is a reason to look. If people on your team say that their ideas are not being heard, treat it as a signal to measure, not as a complaint to manage. Here is a simple way to check.

I worked somewhere once where it felt like a male-dominated team. More specifically it felt like ideas from the women and enby folk on the team, including mine, were dismissed at a higher rate than my male colleagues.

I want to be careful with that sentence. I did not have data. I had an anecdotal pattern I noticed over time, and I was not the only person whose ideas it affected.

When someone asks how to find the sum of an array, the fast answer is one line of code. I think the fast answer is usually the wrong one. Handing over the code does the reasoning for them. It removes the moment where they work out the answer themselves, and that moment is the point.

There are two long-term benefits. The learner can ask themselves the same questions on the next bug. And in a public community, other people reading the conversation learn from it too. I used a courtroom scene from a film to make that point: the questions are for the jury as much as for the witness.

When someone asks how to find the sum of an array, the fast answer is one line of code. I think the fast answer is usually the wrong one. Handing over the code does the reasoning for them. It removes the moment where they work out the answer themselves, and that moment is the point.

What is an array? How would you step through it? What does the loop need to do each time? Where does the running total live? By the end, they have described the code themselves.

When someone asks how to find the sum of an array, the fast answer is one line of code. I think the fast answer is usually the wrong one. Handing over the code does the reasoning for them. It removes the moment where they work out the answer themselves, and that moment is the point.

The most striking problem statement I heard at a hackathon came from a veteran who served on a landing ship. He built a real-time, voice-powered incident response system called crisisroom.

Three constraints: a place where nobody can type, a voice that software cannot hear and a call where the danger is spoken aloud. In each case, the product was built around voice. Voice was not added afterwards.

The most striking problem statement I heard at a hackathon came from a veteran who served on a landing ship. He built a real-time, voice-powered incident response system called crisisroom.

The team fine-tuned a model on a dysarthric speech dataset, then used a language model to reconstruct the meaning and a text-to-speech voice to respond. A full speech-to-speech system, built at a hackathon.

The most striking problem statement I heard at a hackathon came from a veteran who served on a landing ship. He built a real-time, voice-powered incident response system called crisisroom.

He built the system because he had lived with the cost of not having one. It was not the only project at that event that started from a real constraint.

The most striking problem statement I heard at a hackathon came from a veteran who served on a landing ship. He built a real-time, voice-powered incident response system called crisisroom.

He described damage control at sea. A steel passageway. Strobing lights. Smoke filling the space. Water rising past your boots. A general alarm so loud that you cannot hear the person next to you.

I do not judge a sponsor track by its submission count. At the AI Hackathon at Berkeley, ours received 141 submissions, third-most of any sponsor. The count alone hides most of what happened.

The prize was four games consoles. Other sponsors offered cash, credits or an office hour. A track that asks for more has to give more help, so I ran a workshop and shared starter repositories for it.

I do not judge a sponsor track by its submission count. At the AI Hackathon at Berkeley, ours received 141 submissions, third-most of any sponsor. The count alone hides most of what happened.

Ours sat at the high end. A team had to capture a microphone stream, connect speech-to-text or a voice agent, and handle real-time audio. That is a whole new modality.

I do not judge a sponsor track by its submission count. At the AI Hackathon at Berkeley, ours received 141 submissions, third-most of any sponsor. The count alone hides most of what happened.

So I compare tracks by adoption rate against integration effort. I rate effort on four levels: none, low, medium and high. Then I read each track's adoption against its level.

I do not judge a sponsor track by its submission count. At the AI Hackathon at Berkeley, ours received 141 submissions, third-most of any sponsor. The count alone hides most of what happened.

Before I run a workshop, I give every resource its own short link: signup, the guide, the docs, each repository, the deck and the Discord invite. Then I can see what people do after the session.

I look for what people did next. There were 56 documentation visits and 65 repository clicks, so people built after the session. About 74 percent of the repository clicks were for Python.

Before I run a workshop, I give every resource its own short link: signup, the guide, the docs, each repository, the deck and the Discord invite. Then I can see what people do after the session.

I report tracked numbers as floors. Some tables also had generic QR codes that I could not measure, so real engagement was higher. Every untracked code is engagement I cannot count.

Before I run a workshop, I give every resource its own short link: signup, the guide, the docs, each repository, the deck and the Discord invite. Then I can see what people do after the session.

The guide was the second most-used link, with 209 clicks, ahead of the documentation. I write it to work without me in the room, and the numbers suggest people used it that way.

Before I run a workshop, I give every resource its own short link: signup, the guide, the docs, each repository, the deck and the Discord invite. Then I can see what people do after the session.