I build software, mostly in the open.
Most of the code I work on is open source, which means I get to collaborate with a pretty diverse group of people: coworkers, contributors I've never met, maintainers of other projects, and sometimes people who just show up with an interesting idea.
This is a little about how I tend to work.

I care a lot about building things well, not just getting them shipped.
I like understanding the why, digging into trade-offs, challenging assumptions, and thinking about what happens down the road. I tend to go deep on technical problems, and I enjoy speculative conversations about where things could go.
If you bring me a half-formed idea, that's totally fine. I enjoy figuring things out together.
I'm also pretty direct. If I think something is a bad idea, I'll probably say so. That's about the idea, not the person and I genuinely expect people to challenge me back.
You don't need to agree with me. You just need to be willing to explain why.

• Good technical reasoning over unquestioned consensus
• Asking questions early
• Challenging assumptions and designs
• Thinking about long-term consequences
• Surfacing problems rather than hiding them
• Being willing to change our minds
• Healthy disagreement
• Leaving things better than we found them

I'm particularly interested in the reasoning behind a decision, not just the decision itself.

Sometimes I've already spent quite a bit of time thinking about a problem, so I may jump ahead in a discussion. If my reasoning isn't clear, just ask me to back up and explain how I got there.
I can also get pretty passionate about technical problems. If something isn't going well, that may be visible. Don't assume that means I'm frustrated with you.
And if I ever come across more strongly than intended, tell me. I'd much rather fix that in the moment than have someone quietly work around me.
Especially if we haven't worked together before: you don't need to have the perfect answer before bringing something to me.

I find written reasoning really useful, especially for architectural or complicated decisions.
A rough structure like this is usually enough:

Problem → Context → Assumptions → Constraints → Options → Trade-offs → Recommendation

It doesn't need to be polished.
I may also occasionally revisit a decision we've already made. If that happens, a useful question is:

"What has changed since we made that decision?"

Sometimes the answer is "nothing" — which is useful to know too.
And when I say something like "I don't care about X", I usually mean "X isn't important enough to optimize for right now." I care quite a lot about the people and the things we're building.

I'll try to:

• Be honest and direct
• Explain my reasoning
• Share what I know
• Help unblock problems
• Give feedback that is useful rather than performative
• Change my mind when the evidence warrants it
• Treat disagreement as a normal and healthy part of engineering
• Give credit where it's due

And in return:
Challenge me. Ask questions. Tell me when I'm wrong. Tell me when something isn't clear. Bring me weird ideas.
That's usually where the interesting stuff starts.

One of the things I enjoy most about open source is that good ideas don't have to come from the people who originally wrote the code.
You might be a longtime contributor, someone opening their first issue, a maintainer of a related project, or someone who happened to notice something I missed.
The bar for participating isn't having the right credentials or already knowing the codebase.
Bring your perspective.
I'll bring mine.
Let's see what we can figure out together.