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.
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.
Scaling Sparta: Military Lessons for Growing a Dev Team
Scaling systems is hard, but we’re developers — that’s kind of our thing. Scaling people? Well, that’s significantly harder. Humans are complicated.
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.
But companies aren’t living, breathing organisms. They’re collections of people — families, tribes and civilizations.
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.
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.
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.
We’re going about it all wrong. Putting ourselves — our egos — above our code. No judgement. I do it too. We’re human. It’s okay.
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.
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.
We’re all different. And I think that’s pretty awesome. But sometimes — often — our differences divide us.
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.