Preparing for My First Tech Talk

I’m giving my first tech talk tonight, at the NYC on Rails meetup at the Flatiron School. Preparing for this was an exciting and challenging process as a beginner. Some lessons below:

Positioning: As a beginner, there’s a good chance you know less about programming than anyone you’re speaking to. In life, I think it’s always important to find the place where you come at a situation from a position of advantage instead of limitation. The beginner has the unique perspective of… a beginner. No one who is not a beginner can access that process of problem-solving in a totally new and unfamiliar field that the beginner can. So the beginner’s role is to be as expressive as possible about how they build pathways from one concept to another. Presenting this can be helpful for a more experienced audience in several ways. First, it’s a reality check for whether someone listening to the presentation understand the concept well enough to be able to present it to the beginner. Second, when learning a great deal rapidly and working on a range of projects, it is easy to forget some of the initial questions that challenged or drove you at the initial phase. Listening to the beginner might help recall or clarify some early motivation for the audience. In sum, it’s important as a beginner to use this position as effectively as possible, both for oneself and for one’s audience, as a community-building and self-reflective exercise.

Purpose: After going in several directions about what I should present, I realized that the most important thing for me right now would be to establish strong fundamentals of understanding of Rails. It’s key to think what you want to learn from giving your presentation. Not only is this the most productive use of your time (and as a beginner it seems like there’s not enough time to read half the documentation or do half the problems or assignments you want to do), but it also means that you now have a stake in the presentation, which makes it more interesting for your viewers.

Problem-Solving: After several mistaken paths for this presentation’s topic (think: analyzing trends in Ruby gems, trees of New York rails app, interactive Ulysses, etc), I consulted with my father about how to approach this talk. He suggested that I focus on a problem I had and how I worked through it. That’s why tonight I’m going to speak on conceptualizing Rails after Sinatra. Pinning down one’s problem to present is also tough as a beginner. At first, I felt pretty shaky about Rails, and felt a little nervous to present a problem I didn’t feel too resolved about. Now I think I understand it a little bit better, but then I ask myself whether it’s worth it at all to present about this challenge if everyone else in the room understands Rails pretty well. When learning so much so fast, this is bound to come up. Starting out, you might not want to return so fast to that feeling of not understanding. But being able to pin down this process is useful not only for the talk, but for a resource to draw upon when facing more complex challenges in code in the future.