Speaking

Reading Time: 14 minutes
speaking
Photo Credit: COUNTRYDevOps Keynote, 11 October 2018

Looking for a speaker?

My talks and workshops are:

  1. Didactic: I teach a topic. I draw examples from my career, but the talk does not center me or my personal experience. For example, I talk about leveling up, but not my journey into software development.
  2. Technical: I focus on things I think engineers should know (though I make sure to include something for designers and product folks, too). The examples come from application or machine learning development projects. The slides may have code samples. For example, I talk about refactoring, but not “being a woman.”
  3. Language and version agnostic: I stick to principles and approaches that remain valuable across languages, frameworks, and versions. For example, I talk about debugging strategies, but not what’s new in the latest Android SDK release.

Conference “Rider”

I love speaking and facilitating workshops at conferences, and nothing brightens my day like an invitation to speak at yours!

That said, I’ve been doing this long enough to see that a) conference organizing is hard and therefore b) it’s not unusual for conferences run by well-meaning people to negatively impact the community by accident. When I’m deciding whether to speak at a conference, I consider:

  • The organizing committee: Conference organizing is hard. One person trying to organize a conference is risky. Success in this realm usually takes a team. At least some of the organizers on that committee ought to have conference organizing experience.
  • The Code of Conduct: Is it complete? Is it specific? Is it a good code of conduct from knowledgable CoC people, or is it hand-rolled? Does it have an enforcement measure that I believe in?
  • The equity plan: What is the plan for ensuring a diverse list of speakers and attendees, and how is the conference planning to proactively meet the inclusion needs of a diverse group?
  • The compensation plan: It helps a lot if an in-person conference conference covers travel, lodging, and the ticket price. It’s not that I can’t or won’t pay: it’s the effect that the policy has on the speaker list. See, a conference that expects speakers to cover themselves is only accessible to speakers who have the cash to foot the bill, and it’s only really attractive to speakers working at a company that will pay it for them. I’m tired of hearing talks from people at the same six companies, which are inevitably also somehow about those companies.

    Also, don’t be Lesbians Who Tech and pay your hetero keynote speaker while expecting all your actually queer speakers to not only cover travel and lodging, but also pay for a ticket. I’m pretty sure if I pitched the LWT speaker strategy to Portlandia, they’d say it’s an unrealistically uncharitable depiction of tech.

On Panels

I think panels are an excellent way to juxtapose varied perspectives on a topic. To that end, I’m thrilled to consider moderating and speaking on panels that are germane to software engineering or software leadership.

I’ll also consider inclusion-related topics, but the audience must be private and the event must not be recorded or distributed. These engagements also have a separate fee structure from technical topics.

For all panel appearances, please ensure the following (adapted from Mary Robinette Kowal’s inclusion rider): I’m not the only woman on the panel, and the panel is not homogenous by gender (which includes trans & cis), sexuality, ability, or race. If you need help balancing a panel, I’m happy to help find voices from underrepresented groups.

Talks I Currently Give:

The Technology and Psychology of Refactoring

Length: 45-60 Minutes

Places Given:

  • PearConf 2019, Center on Halsted, Chicago, 2019
  • PearConf Distributed Lecture Series, 2019
  •  

Brochure Pitch:

When the requirements change out from under your tech team, your code has to change. So it’s worthwhile to build your skills in assessing code maintainability, deciding whether to refactor, and doing the refactor.

In this talk, we’ll answer questions like:

  • What does it mean for code to be maintainable, and how do we make code more maintainable?
  • How do we know when to refactor—and how do we know when to stop refactoring?
  • How do we sell stakeholders on giving us space to make a large refactor?

This talk includes both code samples and architecture samples from apps in use today.

Full Transcript and Slides Available Here:

https://chelseatroy.com/2019/03/25/pearconf-talk-the-technology-and-psychology-of-refactoring/

Here’s a Condensed (23 Minute) version of the talk that I recorded for JuneteenthConf’s Supporting Speaker Track:

How to Level Up as a Technologist

Length: 35-45 Minutes

Places Given:

  • COUNTRY Financial Internal DevOps Conference, 2018
  • PearConf Meetup, 8th Light, Chicago, 2019

Brochure Pitch:

To thrive as a technologist, you need to constantly level up your skill set.

That sounds daunting: after all, there’s so much to learn. You might have even experienced some false starts in the past where you tried to learn a new skill and it didn’t work out.

It’s not because you can’t. In fact, I’m confident that you already have the innate ability to add breadth and depth to your skill sets.

I know that because I know that you use that ability every day to stay current as a technologist.

Leveling up is itself a skill that you can sharpen. Today we’ll talk about some techniques that you can use to get better at leveling up. These techniques will help you translate your innate ability to learn so you can broaden and deepen your skill set more effectively, and even enjoy doing it!

Full Transcript and Slides Available Here:

https://chelseatroy.com/2019/04/18/transcript-from-keynote-leveling-up/

Here’s an abridged (22 minute) version of the talk that I gave at a meetup as a favor to a friend:

Debugging: Techniques for Uncertain Times

Length: 20 Minutes

Places Given:

  • RailsConf 2020

Brochure Pitch:

When we learn to code, we focus on writing features while we understand what the code is doingWhen we debug, we don’t understand what our code is doing. The less we understand, the less likely it is that our usual programming mindset—the one we use for feature development—can solve the problem.

It turns out, the skills that make us calmer, more effective debuggers also equip us to deal with rapid, substantial changes to our lives.
 

Whether you’re uncertain about what’s going on in your code, your life, or both, in this talk you’ll learn debugging techniques to get you moving forward safely.

Full Transcript and Slides Available Here:

https://chelseatroy.com/2020/05/05/transcript-debugging-techniques-for-uncertain-times/

Here’s the video recording for RailsConf Couch Edition:

Giving and Receiving Feedback

Length: 35-45 Minutes

Places Given:

  • University of Chicago Intro to Software Development, 2019
  • Pivotal Labs Employee Professional Development Series, 2019
  • Chicago CTO Summit, 2019
  • Nest With Fedora, 2021

Brochure Pitch:

Our team skills affect our career trajectory more and more as our technical contribution capacity increases.

But we don’t explicitly teach team skills most of the time: we instead send people into the workforce and let them struggle until they figure it out.

This talk covers the things I wish someone had told me about giving and receiving feedback in teams…so you don’t have to struggle.

We’ll cover:

  • When and how to give feedback to others
  • How to attract relevant, specific, useful feedback for yourself
  • How to cope when feedback hurts
  • Strategies to respond to feedback and translate it into useful action steps

Full Transcript and Slides Available Here:

https://chelseatroy.com/2019/05/15/giving-and-receiving-feedback/

Here’s an abridged (22 minute) version of the talk that I gave at a lunch and learn, again, as a favor to a friend:

What Counts as a Programming Language?

Length: 20-30 Minutes

Places Given:

  • Code Mesh V, 2020

Brochure Pitch:

When we think of programming languages, we think of Java, Kotlin, JavaScript, or Python. We don’t think of CSS, SQL, or HTML. And we don’t think of Alloy, Modelica, or SNOBOL—in fact, maybe we haven’t even heard of all those. But what’s the distinction? And maybe most importantly, what can we learn as programmers from “not programming languages”?

We’ll cover:

  • What we can learn from questioning how we categorize things
  • How to identify “assumed context,” and why it matters
  • Lessons learned from “domain specific” programming languages

Debrief Available Here:

https://chelseatroy.com/2020/11/07/what-counts-as-a-programming-language/

Here’s the Code Mesh V version of the talk, plus a little Q&A 😉:

Parrot Emergency! Analyzing Risk in Software Systems

Length: 2 Hours

Places Given:

  • RubyConf Couch Edition, 2020

Brochure Pitch:

How do you prevent an app from breaking?

Do you do it with automated tests? Does that work? When doesn’t it work? What do you do when automated tests don’t work?

How about cases where automated tests might work, but you don’t have them? Suppose you inherit a system with 8% test coverage. What do you test first?

The goal of this workshop: communicate a strategy for determining when and how apps will break. Here’s the key though: the strategy needs to be both accurate enough to be useful, and simple enough to be used.

Here’s how it goes: we put you on a team with 4-6 other software engineers. Then, we show you the class diagram for a complex and critical software system: an emergency triage system for parrots. That’s right: every poorly parrot gets a little parrot harness that monitors their vital signs and helps vets determine who needs attention first.

Your job, with your team: make sure the system works. You won’t be writing actual code, but you will be:

  • Identifying all the risks in the system where stuff could go wrong
  • Assessing which of those risks you should prioritize for mitigation
  • Matching the right mitigation tactics to each of the risks, in priority order

And of course, just like a real software project, time is of the essence. Both because the workshop is only two hours long, and also because fictional parrot lives are on the line!

Debrief Available Here:

https://chelseatroy.com/2020/11/30/rubyconf-workshop-analyzing-risk-in-a-software-system/a>

Here’s the RubyConf version of the workshop (recording paused during group activities):

Tackling Technical Debt: An Analytical Approach

Length: 2 Hours

Places Given:

  • RubyConf, 2021

Brochure Pitch:

Getting out of tech debt can feel like a Sisyphean task. After weeks of work, the success case is for the app to work the same as it used to. Organizations often declare code bankruptcy and rewrite working systems from scratch. How do we end up here? And how do we alleviate, or even better, prevent such a situation?

In this workshop, you will learn how to measure tech debt and address the areas of highest need first. You’ll learn to identify high leverage code changes and separate those from renovations. You’ll also learn about the skills tech teams can use to prevent and reduce tech debt.

Debrief and Video Available Here:

https://chelseatroy.com/2021/11/10/rubyconf-2021-workshop-tackling-technical-debt-an-analytical-approach/

Under special circumstances, I can build and deliver a custom talk. Please feel free to reach out to talk deets 😉

Current Proposals:

These are proposals I have submitted to a conference in the past year. If it sounds like a talk you’d like to see at your conference, feel free to reach out. If it sounds like a talk you’d like to see submitted to your conference, by all means, copy the whole abstract and paste it into your CFP. Just email me to let me know you did it, please 🙂

Advanced Debugging: Strategies and Tactics

Length: 90 Minutes

Brochure Pitch:

Debugging: we spend most of our programming time doing it.

But we neglect it as a skill. We say it’s important, but we don’t deliberately practice it. Instead, we focus on shiny new languages, frameworks, and features. Our debugging skills lag behind the development of our other skills. And since we still spend so much time debugging, programming stays more frustrating for us than it needs to be.

Here’s how we make debugging hard for ourselves: we try to apply our assumptions from feature development to debugging, where they’re not true.

Case in point: we work on features with the starting assumption that we understand our code. But when we’re trying to track down a bug, that’s not accurate. We’re drawn to practices that align with our inaccurate assumption (like trying to fix it on the fly) but end up adding frustration to the debugging process. As we gain experience, we learn to ignore these temptations and do something else (like slow down and print out some variables), even if we don’t fully understand why.

But if we instead approach debugging from the starting perspective that we do not understand our code, we’re drawn to practices that *work* for debugging, rather than forcing ourselves to learn from experience to do the opposite of what we want to do based on an inaccurate assumption.

In this workshop, you will learn:

  • Strategies to systematically track down a bug (and why our usual approach so often fails)
  • Tactics to gather information about your systems, so you can narrow down the causes of bugs faster
  • Practices that you can use to sharpen your debugging skills over time

You can expect some lecturing, complete with illustrations and anecdotes to help summarize the concepts and bring them to life. We will also practice our new skills by working through debugging exercises.

This session is targeted at engineers who work as individual contributors on code. I am confident that everyone from the junior level to the principal engineer can learn something from this workshop. If you don’t believe me, come see me beforehand and we’ll make a bet.

Talks I Have Retired:

Allyship in Times of Crisis

Length: 20 Minutes

Places Given:

  • Pivotal Labs Employee Professional Development Series, 2016

Brochure Pitch:

This talk is for allies who want to take care of marginalized communities affected by traumatic events. I gave it shortly after the Pulse shooting in Orlando, but the principles apply in many crisis situations.

In the event of a tragedy like this, we need allies to step up. It can be difficult to know what to say or do if you are not a part of the affected community. That’s what this talk is for: it’s a starting point for allies.

We start with some terminology and talk about what we mean by terms like target, ally, bystander, and crisis. Then we discuss the grief and fear that prevail within a target community after a crisis, and where allies can start to help with that.

Finally, we relate the discussion back to what an ally can do on a daily basis to help fight for equality—and how social change happens.

Full Video Available At:

Chelsea, come give this talk at my meetup!

I’m so glad you appreciate the talk! But lovingly, no.

I only have, and only will, give this talk once. I didn’t even rehearse it.

That’s why I asked Elliot, the best videographer I know, to record it: I knew, if the video or audio recording failed, the talk would be lost forever.

As you can see, Elliot pulled through and got a full recording. So if you want this talk at your meetup, you’re welcome to play the video.

Speaker Bio and Headshot:

Chelsea is a Staff SE on Machine Learning & Backend Systems at Mozilla. She also maintains the Zooniverse Citizen Science Mobile App, the NASA Landsat Data Processing Pipeline, and a few other open source client projects. She is a maintainer for the Roc programming language and mentors formerly incarcerated technologists through Emergent Works. She teaches Python & Mobile Development at the University of Chicago Master’s Program in CS, hosts workshops for O’Reilly, and writes at chelseatroy.com.

Chelsea flings barbells around for fun. She drives an electric cafe cruiser named Gigi.

headshot