Code gets written for lots of reasons, but all code has one thing in common: it’s all ultimately written for humans.
But a lot of the time we only code for computers.
Hello! My name is Tanya and I’m a principal software engineer in Squarespace, which is based in lovely New York City. We’re hiring by the way. I'm whereistanya on twitter and github and I blog at http://noidea.dog which is of course a Squarespace site. And I think mean owls are really funny. That’s the only reason this talk is so full of owls. There’s no really deep meaning behind it. Sorry.
I’ve been in tech a fairly long time — I graduated in 1999 — and something I like is how the image of a programmer has slowly shifted over time. It used to be extremely this guy: omg hacker sitting alone in the dark (with inexplicable sunglasses).
And it’s still often about someone sitting and thinking real hard, but, like, with the lights on and a nice plant. We turned the lights on in a lot of ways.
Programming is considered a human-centric activity more than it used to be. If you’re ever working in an older language, like C, and you look at help forums, you’ll see that sharply illustrated. It used to be rough.
You would ask a question and someone would tell you your question was stupid and answer the question they thought you should have asked, using six words you didn't know, three pieces of implied information that you also didn't know, and a condescending tone. And you'd feel terrible and not ask again.
The recurse center has this concept of "antisocial behaviours" in tech, and two of them turned up a lot in help forum answers.
One is feigned surprise. “You really don’t know that?” It's horrible. Don't ever do it. Even if you are genuinely surprised -- hold it in. It's making the other person feel bad for no reason. Be excited for the opportunity to introduce someone to something cool instead. And if someone does feigned surprise at you, just notice it and don't let it get to you, and (if you feel comfortable) even call it out. "Hey, you just did feigned surprise at me!”
The other is well-actuallying: correcting stuff that is not relevant to the question and doesn't need to be corrected. Nitpicking on details is just intentionally wasting someone else's time. And it's being a jerk to the other person who just doesn't have enough context to understand what you're telling them and how much they need to care.
I think these behaviours were so prevalent because programming wasn't really considered a human activity and the industry wasn't yet seeking out people who were pleasant humans. I'm glad that's changing.
These days, good programmers think a lot about the humans we're coding for. The most important humans are, of course, the users, but there are a bunch of others too.
I'm going to talk about six sets of humans who you should think about as you code. These are overlapping groups and sometimes all six of them will be you. But you are also a human! Future you is a human you don't know yet, with different context and state than current-you. Be kind to that human too!