Punchline, or Gut-Punch?  ## Metadata - Author: [[Leon]] - Full Title: Punchline, or Gut-Punch? - Category: #articles - Document Note: --- tags: - #public-speaking - #developer-advocacy - #community-care Author: Leon Source: Article Reference: https://adatosystems.com/2025/09/18/punchline-or-gut-punch/ date created: 2025-09-18 00:00 --- # Title: Punchline, or Gut-Punch? ## Table of Contents: - [🎯 Context & Setup](#-context--setup) - [🎭 The Joke and Its Impact](#-the-joke-and-its-impact) - [🧭 Feedback via Code of Conduct](#-feedback-via-code-of-conduct) - [🧑‍⚖️ Reflection and Accountability](#-reflection-and-accountability) - [🔧 Options for Change](#-options-for-change) - [📌 Takeaways](#-takeaways) - [📚 References](#-references) ### References: Include a list of sources consulted and cited in the article. - PyOhio talk video (referenced by the author as “here”) - PyOhio Code of Conduct grievance process (organizational reference) ## 📝 Summary: Leon reflects on a recurring conference joke—“Using Oracle for literally anything, ever”—that reliably lands but unintentionally targets professionals who work with Oracle. After a PyOhio attendee filed a Code of Conduct complaint expressing discomfort, Leon recognizes the harm caused, praises the bravery of the feedback, and commits to changing the talk. Options include reframing the joke to target the corporation rather than practitioners, choosing a different target, or removing the bit entirely. ## 📖 Main Content: Leon recounts delivering a closing keynote at PyOhio where a long-running joke about Oracle served as a laugh line. Post-talk, an attendee used the Code of Conduct process to share how the line put them in an uncomfortable, isolating spotlight. Leon acknowledges the defensiveness that often accompanies “it’s just a joke,” rejects normalizing cruelty, and commits to changing the talk, considering several alternatives from retargeting to removal. The core learning: humor in technical talks should avoid punching down on peers’ legitimate career choices. ### 🗒️ Notes - Context - Closing keynote at PyOhio; talk includes a recurring gag. - Setup: “There really aren’t any poor technical choices,” then lists obviously bad choices, culminating in the Oracle punchline. - The Joke - Line used twice for ironic effect: “Using Oracle for literally anything, ever.” - Works because large, complex tech and Oracle’s reputation are easy targets. - Impact on Audience - Professionals choose Oracle for valid reasons: scope, funding, promotion, stability. - The joke unintentionally spotlights and devalues practitioners’ work. - Unlike other examples, no “out” or nuance was offered for Oracle users. - Feedback Mechanism - A PyOhio attendee files a Code of Conduct grievance. - They felt conflicted about reacting and later about sharing their work with others. - Reflection - Dismissing concerns as “can’t take a joke” is defensive and condescending. - Normalizing cruelty via humor is not acceptable. - The complainant’s action is framed as courageous. - Options for Change - Rephrase to “Oracle corporation,” separating people from the company. - Pick an older or universally panned tech (Perl/XML/Windows 8) to reduce harm. - Remove the punchline; talks need not emulate standup. - Commitment - The talk will change; ignoring specific, personal, urgent feedback would be a poor human choice. ## 📖 References: - Leon. “Punchline, or Gut-Punch?” https://adatosystems.com/2025/09/18/punchline-or-gut-punch/ - PyOhio (Code of Conduct grievance process referenced in-article) ## 🗣️ Paraphrase: - Original idea: The joke lands because Oracle is an easy target, but I didn’t account for practitioners doing thoughtful work with it, sometimes for career stability. The joke left them exposed without an “out.” - Paraphrase: The gag consistently works, partly due to Oracle’s reputation, but I overlooked the many skilled professionals who use Oracle for practical, career-minded reasons. My framing offered them no nuance, effectively putting them on the spot. - Original idea: It’s easy to dismiss complaints as oversensitivity, but that response dodges responsibility. The complainant showed courage, and I’m committed to changing the talk. - Paraphrase: Brushing off criticism as people being humorless is a defensive reflex that avoids accountability. The person who spoke up showed real bravery, and I will modify the talk accordingly. ## 📰 Newsletter: This week in the WordPress world: Learning paths, community wins, and shiny new toys! If you’re leveling up your web dev skills, start with modern PHP patterns, the latest in block theme tooling, and performance profiling with Query Monitor. Community highlights: mentorship cohorts are open—perfect for first-time contributors—and there’s a push for sustainable funding models for maintainers. Plugin radar: a11y toolbar updates, image optimization with AVIF support, and a lightweight blocks UI enhancer you’ll actually keep enabled. Speaking of community care, we’re spotlighting talk design: humor can unite, but not at the expense of practitioners—build jokes that punch up, not at your peers. Dive deeper with the contributor handbook and the Performance Team’s updates to keep your sites speedy. Keep building, keep sharing, and remember: version control your jokes, too. Links: - WordPress Contributor Handbook: https://make.wordpress.org/ - Query Monitor: https://wordpress.org/plugins/query-monitor/ - WordPress Performance Team: https://make.wordpress.org/performance/ ## ✅ Action Items: Prompt for aligning articles with your Developer Advocacy/OSPO trajectory: “Analyze how this article informs open-source advocacy, contributor engagement, and education within WordPress and beyond: - Advocacy: What norms about community care, talk design, and psychological safety does the article reinforce? How can these inform our contributor guidelines and event CoCs? - Contributor Engagement: Which practices reduce unintentional exclusion (e.g., avoiding humor that targets practitioner choices)? Propose onboarding scripts and speaker briefs that operationalize this. - Education: Translate the reflection into training assets (speaker workshops, inclusive examples, feedback loops). Define learning objectives and assessment. - OSPO Readiness: Map lessons to policy—speaker codes, incident response, and feedback governance. Identify metrics (incident rates, sentiment, retention) for continuous improvement. - Transparency & Inclusivity: Outline communication plans when content changes due to feedback. Document decision logs and public postmortems. - Sustainability: Show how respectful culture improves contributor retention and cross-team collaboration. Propose a budget line for training and moderation.” ## 🧪 Hypotheses: - H1: Talks that avoid practitioner-targeted humor increase attendee psychological safety and post-event engagement. - H2: Providing “outs” or nuance in examples reduces perceived stigma among niche-technology practitioners. - H3: Clear CoC feedback channels increase reporting and accelerate speaker behavior improvements. - H4: Speaker training on inclusive humor correlates with higher satisfaction scores and repeat attendance. ### 📊 Methodology: - Data sources: Post-event surveys, CoC reports, session ratings, hallway-convo sentiment sampling, speaker rehearsal audits. - Designs: A/B test talks with/without targeted humor; pre/post policy interventions; mixed-methods (quant + interviews). - Analysis: Likert comparisons, thematic coding of feedback, regression on retention vs. inclusivity scores, survival analysis of contributor longevity. ### ❓ Questions: - How do we balance levity with inclusivity in technical talks? - What frameworks help separate critique of companies from critique of practitioners? - Which feedback mechanisms feel safest and most effective to attendees? ### 🔮 Future Research: - Model a rubric for “punch up, not down” in tech talks. - Study long-term community retention after inclusive-speaking interventions. - Compare incident rates across communities with different speaker guidelines. ### 💡 Implications: - Stronger CoC processes and speaker training can measurably improve psychological safety, contributor retention, and event quality. - Policies that distinguis - Summary: In that moment, anyone in the audience who'd made that choice found themselves in an unintentional spotlight. Without my meaning to, I'd made them and their work the butt of a joke. - URL: https://adatosystems.com/2025/09/18/punchline-or-gut-punch/ I was excited and also humbled to be given the chance to deliver the closing keynote talk at [PyOhio](https://www.pyohio.org/) this year. You can see the [video of that talk here](https://www.youtube.com/watch?v=wB5JIT7rF0g). But a conversation afterward offered me a chance to reconsider and – hopefully – improve both myself and that talk for the future. I set up a particular joke early in the talk: After establishing that “there really aren’t any poor technical choices”, I go on to qualify that statement with examples of demonstrably bad technical choices – things like not having backups, testing in production, etc. In that list I include the punchline: > Using Oracle for literally anything, ever. > > Near the end of the talk I offer another list, this time technical decisions that sometimes leave us paralyzed with indecision. Near the end I ironically include the same line – “using Oracle for literally anything, ever”. Both lines never fail to get a laugh from the audience. First, because any sufficiently large, complex, storied, and difficult to manage technology would fit the bill. I could have chosen from a range of programming languages, platforms, or solutions and gotten almost the same type of laugh. But second, because Oracle – the company, and certainly it’s CEO – have made itself an easy target. And look, it’s a good joke, ok? What I failed to consider is that plenty of thoughtful, dedicated, committed IT folks work with Oracle every day. Some might have had taken jobs that covered a wide range of solutions, Oracle included. And some might have seen where the money was – that internally the big projects and big funding was going to an Oracle-based project – and decided to go in that direction because of the potential for promotion, bonuses, and stability. And in that moment, anyone in the audience who’d made that choice found themselves in an unintentional spotlight. Because, without my meaning to, I’d made them and their work the butt of a joke. At best, they now had to deal with folks winking at them and saying “using Oracle for literally anything, amirite?!?”. At worst, they had to explain why they had made a “poor technical choice”. Moreover, unlike any of the other technologies I mention in that talk, I hadn’t offered an “out”. Every other poor technical choice is presented in a “That’s bad! No that’s good!” type of framing. I wasn’t aware of any of this, although I’d given the talk several times, until someone at PyOhio stepped forward. Through the Code of Conduct grievance process (and massive props to the PyOhio team for having this process, and taking it seriously), they registered their discomfort, both in the moment and afterward. They related that, having built a career around their expertise with Oracle, they found themselves uncomfortable and conflicted about how to react during my talk. And after the talk was over they were uncertain about how (or whether) to mention their work to other attendees. They asked the organizers to ask me to consider my talk in from their perspective, and reconsider how willing I was to put other people in the same situation, all for the sake of a momentary laugh. It’s easy – too easy – to write off this one person as being overly sensitive, unable to take a joke, too self-absorbed or self-important to laugh at themselves. Upon even a moment’s reflection, it should be obvious that this would be both defensive and condescending. Who are we to normalize cruelty just or judge someone else’s response? “Nobody can take a joke any more.” Is (and, let’s be honest, always has been) the response of those who don’t want to bear responsibility for their words. The truth is the person who filed the complaint is the epitome of bravery. It takes strength of character and conviction to stand up and tell someone that what they’re doing is wrong. I applaud anyone who takes that kind of risk. I’m deeply grateful to the person who did so in this case, even though I’ll never know their name. SO… where does that leave me and my punchline? To be honest, I’m still not 100% sure. On the one hand, I could just modify the line to say “Oracle corporation”, separating the solution from the Law-firm-with-a-small-software-division that is the Oracle business. I could go searching from a different target that’s so old nobody would be offended – like Perl or XML. Or something that’s likely to be universally reviled – like Windows 8. Or I could cut the punchline out entirely. A conference talk doesn’t need to be a thinly veiled standup routine. So I’m not sure of HOW it will change, but I’m absolutely certain that it WILL change. I was given feedback that was specific, personal, and urgent. To ignore it would be more than just a poor technical choice. It would be a poor choice as a human being. [](https://adatosystems.com/2021/07/12/change-is-hard/) [](https://adatosystems.com/2022/02/14/sysadmin-day-2021-you-are-enough/), Punchline, or Gut-Punch?, Leon, 01k5fe6qkcb4nrf3tsw0pr7hz3.