,
27 tweets,
3 min read
Read on Twitter
I saw a talk today use an idea I thought we'd moved past: "write your code like it will maintained by psychopath who knows your address"
It's really, seriously, not funny to folks who've had a violent or potentially violent stalker.
And let's be clear, most of those people are women. Stalking is a gendered experience.
I'm sure the last thing you want to do is remind them of that experience when you're trying to teach them something.
Both because it's a shitty thing to do to people, and because it reduces the effectiveness of your message.
When you remind people of a traumatic experience, associate it with work, & (worst) make light of it, they won't remember your actual point.
Another problematic aspect is that it suggests violence is an appropriate (or expected) response to bad or low-quality code.
Again, due to the gendered nature of most personal violence, this aspect is far more likely to be alienating to women than to men.
This gets extra poisonous in combination with the junior-senior dynamics found on many teams these days.
I see many teams where women are well-represented among the newer developers, but less represented (or completely absent) at higher levels.
In situations like that, if you're not really careful, code criticism can appear to flow in only one direction: from men to women.
That dynamic by itself isn't necessarily poisonous. But it intersects REALLY badly with "violence is the expected response to bad code."
There are many still-colorful but less-gendered ways to communicate the idea that writing good code is a solid for your future maintainers.
Many in my mentions :)
I like @sandimetz's method for evaluating code: could a dev who didn't write it, is on call, & has had a beer understand it?
In other words if they were out with friends & got paged for a prod issue & it pointed at this part of the code, would they know what to do?
This works for me because it takes context into account. Folks on your team need some baseline context to even move around in your codebase.
Some codebases require muuuuch more context than others.
Very concrete code localizes information near where you need it, so you need less outside context to understand something.
More abstract code scatters the information you need across other parts of the codebase. You need more context to figure something out.
People love to talk about abstract/concrete but one is not necessarily better or worse than the other.
If lots of people work on a codebase, the reduced cost of change you get with abstraction can be worth the extra context it requires.
But abstractions aren't free and in my experience are vastly overused on smaller teams, where cost:benefit doesn't work in their favor.
Buuuuut that's a rant for another time.
My point is, thinking about whether your code would be understandable by someone with typical context - rather than a rando - is important.
That's why it helps me to think about a dev who's on call, presumably with appropriate context, but who might be distracted and/or stressed.
That's all for today's episode of "Analyze a Thing: Excruciating Detail Edition™"
