How To Work With a DJ

Back in 2020, employees at the company where I worked were encouraged to write "How To" guides for themselves. The goal, as I understand it, is to minimize interpersonal friction when available modes of communication leave substantial room for misunderstanding. I thought it was a useful exercise for myself, and reading others' guides helped me to internalize the wide variation in how people prefer to communicate and work.

Things I'm Very Likely to Do or Say - "It's not you, it's me"

If I can't figure out why an end-user would want something, or how they would make use of it, I will probably keep asking questions until I figure it out. I find it very hard to deliver features when I don't understand the value.
One of my favorite colleagues at Airship, Patrick Woodworth, taught me that code review should follow Postel's Law. "Be conservative in what you send, be liberal in what you accept."
My first instinct when encountering a new idea or proposal is to try to figure out if it is flawed or incomplete. I want to know what's wrong with it, and if we can live with those drawbacks. I'm very likely to talk about the problems with a proposal first, and the strengths second or never. This does not mean I don't like the idea! I recognize that this behavior can be confusing. In no small part for the sake of my marriage, I'm working on it.
When having a technical or product discussion, it is not uncommon for me to abandon my initial position when presented with a strong argument or new information. I do my best to acknowledge when this has happened, but it sometimes throws people for a loop: "Wait a minute, I thought you were advocating for X..."

Team Dynamics

Every engineering team I've worked on has been mostly white men, and I consider that a systemic and personal failure. I work to change that whenever I get an opportunity to do so. This means being thoughtful and deliberate about interviewing in ways that minimize bias and maximize all candidates' chances to shine. It also means nurturing a supportive environment on my team where everyone is comfortable speaking, learning, and taking ownership of their work.
I love giving demos. Technical demos, product demos, sprint demos, bugfix retrospectives - I'm here for it. Showing off great work while tying technical concepts to end-user value is one of the best parts of the job. Because of this, I often wind up demoing work in which I played a relatively small role, simply because others who worked on it are less enthusiastic about presenting. I'm acutely aware that this makes me a more visible team member, and I try to be generous when calling out everyone who contributed on a project. I never want to take credit for someone else's work.
I try very hard to never disparage an existing codebase. Most code was written by human beings who were trying to accomplish some goal, under some constraints, in the best way they knew to do it. I think it shows a lack of empathy to refer to anyone's work product as "trash" or "a dumpster fire." I've worked with a few teammates who find it motivating to talk this way, and had discussions with them about how they can feel empowered to make big changes without making others seem small.

Written Communication Quirks

DMs are lava. Don't touch the lava. If you have a technical or product question for me, there is a vanishingly small chance that you are the only person with that question. There's also a nonzero chance that I'm wrong. Asynchronous communication in chat has drawbacks and benefits, but almost all the benefits are lost if people primarily communicate in private channels and DMs.
I am an unapologetic multi-message chat user. I have been known to, on occasion, split a single sentence over three or more lines in a Slack conversation. If this drives you insane let me know and I will try to reduce the bing-bong rate
I overuse the em dash - and frequently just use the hyphen glyph for it even though I know it's not right.