Talk Topics

This IS NOT Fine: Putting Out (Code) Fires

So the dumpster is on fire. Again. The site’s down. Your boss’s face is an ever-deepening purple. And you begin debating whether you should join the #incident channel or call an ambulance to deal with his impending stroke.

Yes, we know this is a developer’s fault. There’s plenty of time for blame later. Postmortems have a macabre name because they were once intended to be Viking-like funerals for someone’s job. But we’re civilized now. Sort of. So we call them post-incident reviews.

Fires are never going to stop. We’re human. We miss bugs. Or we fat finger a command — deleting dozens of servers and bringing down S3 in US-EAST-1 for hours — effectively halting the internet. These things happen.

But we can fundamentally change the way we approach fires.And that requires adopting the techniques of industries much older than ours.

Firefighting (the kind with flames) was created as a lucrative scheme by Marcus Licinius Crassus in Ancient Rome. Only we wouldn’t have considered his brigade heroes. They would arrive to the fire and do nothing while one “firefighter” negotiated the price of their services. If an agreement could not be reached, they would let the property burn to the ground and then offer to buy it for a fraction of the original value.

Firefighters have clear procedures and a strong hierarchy. The first truck at a scene immediately begins assessing the situation. They evaluate building construction, visible smoke, fire and flow paths. The Incident Commander gives orders to his or her personnel regarding fire attack as well as calling for additional resources, communicating with those not yet at at the scene and preparing an action plan.

Which sounds a lot like the tight, orderly process of a deploy rollback or hotfix. Just kidding.

This talk will focus on how firefighters approach a fire — before, during and after an incident — and how we can apply those strategies to our own (admittedly much less dangerous) fires.

The Intelligence of Instinct

Last year I got on a hotel elevator in Toronto with three men: a staff member and two others. I hesitated before getting on but thought better of it. There was a staff member. It was a nice hotel. But I did something that should have clued me in. I hit the button for the wrong floor.

The staff member got off on the fifth floor. I had 14 more to go. The doors closed. I felt the large man behind me grab my backpack. “Why are you wearing this cockblock?”

I did what every woman does in that situation. I made myself small. I tried to ignore him. 8 more floors. He persisted. “What’s in there?” The doors opened. His friend dragged him off. I went to the wrong floor, walked down the stairs to my room and cried. I got lucky. But the clues were there. I hesitated. I had a “feeling.” I pushed the button for the wrong floor. Why?

Fear is not a gut feeling. Fear is your brain delivering critical information derived from countless cues that have added up to one conclusion. Stop. Get out. Run.

But sometimes fear isn’t life or death. Often, it’s code smell. It’s a bad feeling before a deploy. There are endless dark alleys in our codebases. This talk will explore fear, instinct and denial. We’ll focus on our two brains — what Daniel Kahneman describes as System 1 and System 2. And we’ll look at how we can start to view “feelings” as pre-incident indicators.

Scaling Sparta: Military Lessons for Growing a Dev Team

Broadly speaking, companies have three stages of development: infancy, those awkward teenage years and — if they survive the trials of adolescence — adulthood. An infant startup is so drastically different from its adult incarnation that they can be considered different companies. Each will have a unique mission and culture.

Scaling isn’t just about making what you have bigger. An ant can’t be scaled to the size of an elephant. Because the internal structure is fundamentally different. Instead, companies have to evolve.

So how do you scale a team of two to twenty? The answer starts over 2,000 years ago in Sparta.

This talk will focus on three distinct military organizations: Spartans, Mongols and Romans. Sparta’s standing army numbered 10,000 whereas Rome’s peaked at half a million. We’ll look at the structure of each military and apply the lessons learned to our development teams and organizations.

GDP... Wat?

If you haven’t heard of GDPR yet, you will soon. It’s the latest of Europe’s data and privacy protections. And this one’s big.

GDPR is short for General Data Protection Regulation. Yes, the name is a snooze fest. Bureaucrats aren’t exactly known for catchy acronyms. But here’s what’s important. It replaces the Data Protection Directive of 1995 (!) — the year JavaScript was developed at Netscape by Brendan Eich. The year we received Playstations from Santa. And the year Java 1.0 was released by Sun Microsystems.

And if you’re thinking this doesn’t affect you because it’s European, think again. This applies to any company — from Pied Piper to Oracle — that collects any data on any European anywhere in the world. Yes, that’s probably you. If you don’t know for certain, without a shadow of a doubt, that you don’t collect data on Europeans, this is definitely you.

This talk will focus on what the heck GDPR is, the consequences of making Angela Merkel angry and how we architect our systems — everything from data storage to data transfer — needs to adapt to the standards of privacy by design.

We’ve all met that one dev who’s absolutely obsessed with “pure functions” and throws around the word “lambda” like anyone knows what the heck he’s talking about.

If you don’t have a degree in applied mathematics, FP is intimidating. No, terrifying. But here’s the thing — once you get past the fancy words, it’s really quite simple. And, after you recover from your mind being blown, you’ll find yourself with an entirely new set of technical tools.

This workshop is advanced programming for beginners. We’ll make FP approachable and walk you through how to build a functional program in JS.

Dr. Seuss Guide to Code Craftsmanship

I have a two-year-old daughter who adores Dr. Seuss. And as I was reading Cat in the Hat for the 214th time, I realized Dr. Seuss had it all figured out.

His words are odd. The cadence confusing. But there’s a gem hidden in all his children’s rhymes.

You see, Dr. Seuss would have made an excellent engineer.Because great code isn’t about choosing the perfect method name or building out 95% test coverage. All that is great, but it doesn’t make great code.

YOU DO.

It likely never feels that way. There’s a rhythm to software development that goes something like this:

“Easy. I’ve got this.”

“Uhhh, maybe not.”

“HALP! I have no idea what the f*ck I’m doing.”

“How did I not think of that before?!”

“I AM A GOD.”

This process is okay if you’re comfortable having a mild psychotic break every sprint. I’m not.

But I think we can bypass our egos and the emotional ups and downs it produces. This talk will focus on common pitfalls along the development lifecycle and distill Dr. Seuss’s excellent advice into concise steps developers can take before they write a single line of code.

In the words of Dr. Seuss: "You have brains in your head. You have feet in your shoes. You can steer yourself any direction you choose. You’re on your own. And you know what you know. And YOU are the guy who’ll decide where to go.

Humpty Dumpty: A Story of DevOps Gone Wrong

I’m convinced Humpty Dumpty is a story of DevOps gone wrong.

Humpty Dumpty sat on a wall,

Humpty Dumpty had a great fall.

All the king's horses and all the king's men

Couldn't put Humpty back together again.

First, who asks a horse to do surgery? Hoofs can’t hold scalpels. Second, either the king’s men are inept or they’re not communicating. Two kindergarteners with some Elmer’s could have done the job.

You see, Humpty is a deploy. He was fine in staging but shit the bed in production. Now the site’s down and your boss is threatening everyone’s jobs.

IT is saying the code is broken. The developers are saying it’s a server issue. Meanwhile, Humpty is bleeding out. And your customers are complaining on Twitter. Which means a customer service rep has entered the #incident channel to tell you the site’s down. Yea, no shit, Tom.

Sound familiar?

DevOps is the new Agile. Everyone “does it” but few fully embrace it. This talk will focus on common pitfalls and how to ensure your entire team — ops, IT, sysadmins, SREs and developers — stop blaming each other and work together.

Pythons + Vipers: Empathy in Tech

Pythons and vipers are far from friendly. They’re scaly, try to kill you and are kinda associated with Satan.

But they have a lot to teach us about empathy.

We all know there’s a diversity problem in tech. It’s literally been beaten into our heads. What we haven’t heard is a solution. And I’m not talking about hiring pipelines.

Some of you are the oldest engineer on your team. Or the youngest. Maybe you’re the only woman or person of color. Perhaps you have depression or anxiety. You’re married. Single. Have kids. Care for an ailing parent. Gay. Straight. Transgender.

This talk will focus on empathy. And how we can use it to make our jobs, and each other, more awesome.

We’ll cover the evolutionary forces that make our brains desire conformity, look at Solomon Asch’s study on social pressure and discover how one simple change can open our eyes and help us start solving diversity in tech.