Twelve weeks ago I agreed to run a Saturday morning robotics course at the YMCA three blocks from my apartment. I said yes for reasons that were a little vague even to me at the time. Something about giving back, something about kids and STEM, something about the fact that nobody had ever done anything like this for me when I was ten and I thought maybe that mattered.
What I got was twelve of the strangest and most satisfying Saturday mornings I can remember. This is an account of what actually happened, what I learned, and what I think about the question of giving back in technology careers now that I have done it in a concrete way.
How it started
I have lived in the same neighborhood in Boston for four years. The YMCA on my street runs programs for kids and teens throughout the year: swimming, basketball, after-school tutoring, summer camps. I had walked past it hundreds of times.
Last fall they put up a notice looking for volunteers to lead STEM workshops. I emailed them mostly on impulse, mentioned that I was a systems engineer, and said I was interested in running something around robotics or technology. The program coordinator called me back two days later. She was warm and direct and clearly experienced at converting vague volunteer interest into actual commitment. Within a week I had agreed to a twelve-week Saturday morning course, ten kids, ages ten to fourteen, beginner level, no assumptions about prior experience.
I then spent about three weeks wondering what I had agreed to.
Building the curriculum
I have explained technical concepts to non-technical people for most of my career. I have sat through enough painful all-hands presentations to know what does not work. But explaining Kubernetes to a CFO is different from teaching robotics to a ten-year-old, and I had to think carefully about what the actual goal was before I could design toward it.
The goal I settled on was not teaching robotics in any comprehensive sense. It was giving kids a concrete experience of building something that responds to the real world. A program they wrote that made a physical thing move or stop or change based on input. The gap between "I wrote code" and "that thing over there moved because of what I wrote" is, I think, one of the most formative moments in a young person's technical education. I wanted to create that moment for as many of them as possible.
We used LEGO Mindstorms EV3 kits, which the YMCA already had from a previous program, and Scratch-based visual programming to start before moving to some basic Python in the later weeks. The kits are well-designed for this purpose: you can build something physically solid in 30 minutes that is then ready to be programmed, the sensors work reliably, and when something goes wrong it is usually obvious why.
My curriculum broke down roughly like this:
Weeks 1 and 2: what a computer actually is. Not in an abstract sense. We talked about input, processing, and output as concrete things. A keyboard is input. A screen is output. The processor is the thing in between. Then we built the simplest possible robot: a wheeled platform that moved forward for three seconds and stopped. The programming took about ten minutes. The reaction when it moved was worth the three weeks I had spent planning.
Weeks 3 through 5: sensors and decision-making. We added an ultrasonic distance sensor and programmed the robot to stop when it got within a certain distance of an obstacle. Then we added a color sensor and made it respond differently to different colors on the floor. The concept I was trying to introduce was conditional logic: if this, then that. I did not use those words at first. We called it "giving the robot rules," which is functionally the same thing.
Weeks 6 through 8: loops and repetition. We built a simple line-following robot, which requires the program to continuously read a sensor and continuously adjust the motors based on what it reads. This introduced the idea of a loop, the idea of variables, and the idea of a program that runs continuously rather than doing one thing and stopping. Several of the kids had trouble with this conceptually and we spent extra time here, which was the right call.
Weeks 9 through 10: introducing Python. I moved the older kids (12 and up) to a simple Python environment while keeping the younger ones in the visual programming tool. The older kids wrote a Python script that controlled the robot's motors directly. The transition was harder than I expected, not because of Python itself but because the visual tool had abstracted away a lot of the detail that Python requires you to be explicit about.
Weeks 11 and 12: the build challenge. Teams of two or three designed and built a robot to solve a specific task: navigate from one end of a marked track to the other, avoid three obstacles, and stop in a designated zone. They had two weeks to design, build, program, and test. Week 12 was the demonstration.
What actually happened in the room
My plan was solid and I deviated from it constantly, which is probably the right way to know a plan is solid.
The kids were not a homogeneous group. Two of them had done some programming before, one in Scratch and one in an online course. Three of them had no prior experience with anything resembling programming and approached the first session with visible skepticism about whether this was going to be interesting. Several were primarily interested in the physical building and had to be nudged back toward the programming. One kid was the opposite: he wanted to write the program first and build the physical robot around it, which is a genuinely interesting instinct that I tried to encourage rather than redirect.
The most useful thing I did in the first two weeks was not explain anything. I put the kits in front of them and said: build something that can roll. No instructions. Just the pieces and the manuals if they wanted them.
The result was chaos that was also productive. Kids who had never worked together before were immediately arguing about which piece should connect where. They were making mistakes, correcting them, making different mistakes. By the end of the session every group had a rolling platform of some kind, none of them identical, all of them functional enough to proceed.
What I learned from this: the instinct to lead with explanation is usually wrong when the audience is kids. They learn faster from building the wrong thing and understanding why it is wrong than from being told the right approach before they have any context for why it matters.
The hardest sessions were the ones where something did not work and I did not know immediately why. There was a session in week seven where the line-following programs were behaving inconsistently and I spent twenty minutes debugging before realizing that the lighting in the room had changed from the previous week and the color sensor was reading different values. This was genuinely educational for me as much as for them. Debugging a sensor calibration problem is not conceptually different from debugging a network configuration problem. The method is the same: isolate the variable, change one thing, observe the result, form a hypothesis, test it.
I walked through that debugging process out loud, narrating what I was thinking and why. I think this was more valuable than any planned lesson I delivered.
The build challenge
Week 12 was the one I had been both looking forward to and slightly dreading.
Four teams, four robots, one track. I had set up the course in the YMCA's gym with colored tape on the floor and three cardboard obstacles. A few parents had come to watch, which I had not fully anticipated and which added stakes I had not planned for.
Every robot completed the course. This was not guaranteed. Two of the four had significant problems in the final practice run the previous week and both teams had done visible troubleshooting between sessions. When the second robot completed the course on its second attempt, with a kid walking alongside it and audibly counting down the distance to the stop zone, the room made a noise that I was not prepared for.
The kid who had wanted to write the program before building the robot -- his team's robot ran the course cleanly on the first attempt. He spent the rest of the afternoon telling everyone exactly what each line of his Python script was doing.
What I actually think about giving back in tech careers
I went into this thinking I was doing something charitable. I was providing access to a resource that would otherwise cost money. I was sharing expertise with people who would not otherwise have access to it. These things are true and I do not want to minimize them.
But the experience of teaching is not primarily an experience of giving. It is primarily an experience of being forced to understand things clearly enough to explain them, being confronted with perspectives and questions you had not anticipated, and watching people build mental models in real time.
I understand certain things better now than I did twelve weeks ago. I understand what the actual cognitive barrier to conditional logic is for someone encountering it for the first time, which has changed how I think about explaining technical concepts to non-technical colleagues at work. I understand the debugging instinct more clearly from having had to make it legible to kids who had not developed it yet.
The question of access is also real and worth saying plainly. The neighborhood the YMCA serves is economically mixed but skews working-class. The kids in my class came from households where enrolling in a paid robotics program would have been a real budget decision. The ones who showed the most aptitude and curiosity in the room were not the ones from the most resourced backgrounds. Talent and interest are not concentrated where money is, which is obvious when you say it and easy to forget when you spend most of your time in professional environments where they appear to be.
I do not think one twelve-week course changes much structurally. But I watched a kid who had never touched programming run a working Python script, debug it himself when it misbehaved, and explain to his parent exactly what it was doing. That is not nothing.
Practical notes if you are thinking about doing something similar
I am running the course again in the fall and I have thought about what I would do differently.
Start with something that produces visible output within the first fifteen minutes of the first session. The moment where something moves or lights up or makes a sound because of what the student wrote or built is the moment that hooks people. Everything you plan to teach should be downstream of that moment, not upstream of it.
Design your sessions to go over time and have a hard stop anyway. Every session I planned for 90 minutes and ran 95 to 100. Having a clear stopping point that you enforce regardless of where you are forces you to prioritize and it respects the kids' schedules.
Find out what each kid actually wants to build on the first day and try to connect it to the curriculum at some point. Three kids in my group were primarily interested in robots that could navigate mazes. One wanted to build something that could detect and avoid people. One wanted to build a robot arm. I could not accommodate all of these within the curriculum, but acknowledging them and connecting the actual content to those interests wherever possible kept engagement higher than it would have been otherwise.
Do not explain more than necessary before letting them try something. This is difficult if you are a person who understands something well, because the impulse is to give people all the context they need before they start. Kids do not need all the context before they start. They need enough to take a first step, and then they need to be allowed to take it.
What comes next
The fall course starts in September. I have talked to the program coordinator about potentially running two parallel tracks, one for the 10 to 12 age group and one for 12 to 14, so the older kids can spend more time with Python without slowing down the younger ones who are not ready for it.
I have also been talking to a colleague who teaches data visualization at a community college about whether there is a version of this for adults re-entering the workforce, specifically around automation and what it actually means for the kinds of jobs it is replacing. That is a bigger and more complicated project and I do not know yet whether it will happen. But the experience of teaching the YMCA course has made me more confident that I have something useful to contribute in that direction, which was not something I was confident about before.
If you are an engineer with domain expertise and a few free Saturday mornings, I would encourage you to look for something like this. The returns are not the kind you plan for when you sign up.
