One More Item off the Bucket List: My First Conference Talk in English

English Talk, Tick ✅

The venue that day started off a bit chaotic. Our reserved room had been double booked.

Another talk had actually been moved to the next day, but the website hadn't been updated. The host was also a volunteer, and it took a while to sort out that we were indeed the main event for today. After re-testing the projector, a few minutes later, the title finally lit up on the screen: Cognitive Load is the New Downtime.

This was my first time giving a talk in English at a conference. One item on my bucket list, tick.

The opportunity came when a colleague from our events team approached me. She asked if I'd be interested in preparing a talk together with a staff engineer from DevOps. I agreed without much thought. "This is actually something I've always wanted to do—give a talk in English at a conference," I told her. She smiled and said, "Then let's do it." I didn't expect the wish to come true so quickly.

My partner was an experienced speaker. From day one, I was learning from him. Because time was tight, he pulled out content from a talk he'd given two months earlier to see what could be reused.

Based on our roles, we quickly reached a consensus: We weren't just going to talk about DevEx, but also about the "invisible line" between developers and DevOps.

So we dumped all our ideas into the PPT. Cognitive load, tool debt, documentation, testing, context switching... At that point, the PPT was like a big whiteboard with every thought spread out on it.

The title was generated by AI. After feeding in the direction and keywords, it produced ten options. Some were too academic, some too much like ads, but one caught our eye: Cognitive Load is the New Downtime.

It was plain yet precisely hit the core of what we wanted to express. That sentence set the tone for the entire talk and made organizing the subsequent ideas much smoother.

Developers build, DevOps guards. Both sides say they serve the other, yet often unintentionally create load for each other. System downtime can be monitored, but the brain's downtime is often ignored. We wanted to use this talk to show that system stability ultimately depends on human stability.

With the title set, the structure became clear. The opening covered the struggles of developer experience, the middle was about the role of DevOps, and the final slide was a call for action— urging everyone to start paying attention to "developer runtime", not just system runtime.

My partner even drew a flowchart, placing each PPT slide in order and clarifying who would present which part 😄.

The preparation process was more meticulous than I had imagined. I wrote a verbatim script, marked key sentences for each slide, and revised the script several times. We were on different teams, working on different products, and those weeks were especially busy.

During the first rehearsal, I read from the script almost the entire time, mainly to straighten out the logic. He helped me adjust the PPT structure, merging and adding slides, and also helped polish my tone and pacing.

By the second rehearsal, the PPT was basically finalized, and my verbatim script was nearly complete. I still had to read from it, but my mouth had become much smoother.

To say my favorite Leonardo da Vinci quote, I went to ask my daughter Pineapple (🍍 is my daughter): "How exactly do you pronounce Leonardo da Vinci?" That pronunciation was too hard for me. Pineapple seriously taught me several times, and I repeated after her, until she got annoyed.

During that period, I chatted with another colleague and felt that external talks were actually easier than internal demos. Because conference attendees don't know what you're going to say, even if you make a small mistake, no one notices. Internal tech sharing, on the other hand, has an audience that knows the subject well, and one wrong sentence can lead to follow-up questions. External talks are about rhythm, internal talks are about precision. It was then that I truly realized: the difficulty of expression lies not in language, but in context.

But for me, the most nerve-wracking part of an English talk was still: what if I don't understand a question? That worry had nothing to do with content; it was more about fearing a loss of control on stage. My partner gave me two small tips: first, repeat the question to confirm you understood it; second, if the question is vague, ask back: "Do you mean this, or that?" I told him directly: if there are questions, you handle them 😄. Luckily, our session was the last one, and he simply said at the end: "We're running out of time, so we'll skip the Q&A." A perfect finish. I'm truly grateful to my partner.

On the day of the talk, we arrived at the venue early. We tested the lighting, adjusted the projector, and sat in the audience for a few other talks. I began to notice the speakers' rhythm, breathing, pauses, posture, and their eye contact with the audience. At that moment, I felt more like a student.

Because of the earlier double booking, we started a few minutes later than planned. As a result, I didn't even have time to be nervous. I followed the structure from memory, and my partner picked up from the other side. A few slides in, there were a few laughs from the audience; a few more slides, and some people started taking photos. I wanted to sneak a peek at the speaker notes on my laptop, but my partner had made the window extremely small, so I couldn't read a single word and had to keep going from memory.

When I got to the part about improving flaky tests, my eyes happened to meet two colleagues from our team, and my heart skipped a beat—they knew that improvement wasn't finished yet! The host suddenly held up a "5 mins left" sign, which startled me and made me freeze for a moment, but luckily the audience didn't notice. When I finished, the timing was just right.

After the talk, a few attendees chatted with us at the exit for over ten minutes. That kind of "resonance among tech people" felt very natural, no applause, but recognition in their eyes.

Looking back, what impressed me most about this talk wasn't the few dozen minutes on stage, but the weeks of preparation. From the initial chaos, to the content gradually taking shape, to rehearsing side by side with an experienced speaker— the whole process felt like a joint construction, and also like a long debugging session.

A talk is not a performance, but a debugging. You debug your own rhythm, and you debug others' understanding of your ideas. It's no different from writing code.

What I wanted to do wasn't just to deliver a good talk, but to make more people realize: when the system hasn't crashed, the pipeline runs smoothly, and no alert has gone off, people also need uptime.

This talk made me rethink what "influence" means. It's not about standing on stage and being heard by everyone, but about someone starting to think after you finish: "Maybe I can go back and make a change."

And for me, I checked off an item on my bucket list, and it also made me start to wonder: Can I do more, and influence more people?