I spend what feels like a majority of my waking hours thinking about risk. Professionally, I’ve worked in computer security for fifteen years (and software engineering more generally for longer).So my work days are filled with questions about risk: how risky is this vulnerability? How dangerous is it to launch this new feature if it hasn’t gotten a proper security review yet? How much risk is left after we do that review? And then after work, all my hobbies take place outdoors in the wilderness: backpacking, trail running, packrafting, mountaineering, canyoneering. So my hobbies are also filled with questions about risk: is it safe to cross this river here? What bear safety precautions do I need to take in this area? Is this a safe rapid to run or should I portage?

Professionals who work with risk for living — security engineers, wilderness guides, insurance adjusters, investors, etc. etc. — develop sophisticated tools and mental frameworks to help them think clearly about risk and make good decisions. But people who don’t live in these worlds can often find risk discussions hard to follow. We often use jargon that seem intuitive — words like “risk”, “exposure”, “threat”, “mitigation”, etc. — but has specific and sometimes subtle valances to in-groups.

And without training, it’s easy to fall into traps — risk does weird things to our brain, making us often not think clearly about risky situations. For example, most people feel less safe on an airplane than they do in a car, despite the fact that commercial air travel is many of orders of magnitude safer than car travel. Or: when I tell people about a trip I’m taking to Alaska, most people will ask me the risk of grizzly bears, despite the fact that hypothermia is a much more significant risk. (Bears are just more exciting than shivvering!)

So this is a series about how to think about risk. This series is a crash course, a high-level introduction to the most important concepts and risk frameworks. It’s intended for people who encounter risk from time to time and need some basic tools, but don’t want to make a deep study of it. My hope is that it’ll help you better analyze risk when it comes up for you, and also make it easier to navigate conversations with risk professionals.

How should engineering organizations make big decisions?

My series of professionalism: the set of workplace behaviors that are generally expected at work. These behaviors are largely unspoken, but they do exist: there are consequences for violating them. In this series, I aim to write down some of these rules and explore their implications.

Why and how to check references, and what to do with the information that comes up.

Work sample tests are an exercise, a simulation, a small slice of real day-to-day work that we ask candidates to perform. They’re practical, hands-on, and very close or even identical to actual tasks the person would perform if hired. They’re also small, constrained, and simplified enough to be fair to include in a job selection process.

Work sample tests are a critical factor in effective hiring. Interviews aren’t enough; hiring without work sample tests risks selection people who excel at interviewing but can’t actually perform the job.

This series builds a framework for effective work sample tests, and gives a bunch of examples of effective tests.

Most managers know that delegation is part of their job, but the vast majority of management texts are incredibly non-specific about what delegation means. This series on delegation tries to fill this gap. I’ll cover the principles and theories that guide how I think about delegation, ending with a concrete example: how to delegate meeting attendance.

A series sharing some of the questions I use when I interview for technical roles. I’ll unpack the question, when to ask it, and how to evaluate answers.

Articles I’ve written for r2c, a security startup I consult for. They’re building semgrep, a code search tool that understands Python syntax (and many other languages).

R2C pays me to write these articles for their blog, and gives me permission to cross-post them here.

Documenting my local Python Development environment.

A series of articles laying out the tools, tips, and techniques I’ve learned over the years I’ve spent helping to write Django’s docs.