Plenty of people keep a short "how to work with me" manual — a user guide to themselves. This is mine. It's a shortcut for teammates, mentees, candidates, and anyone collaborating with me on a project, written in my personal capacity and reflecting how I like to work rather than the position of any organisation I'm associated with.

Don't treat this as a rulebook. It's a shortcut to getting on the same page faster. Ignore anything that doesn't fit the situation.

• Lead with the ask. Tell me what you need and by when, up front. If there's an action for me, make it unmissable — put it in the subject line or the first sentence, not buried three paragraphs down.
• State your uncertainties and assumptions. I'd much rather you flag "I think X but I'm not sure" than present a guess as a fact. It tells me where to look.
• Bring a goal, not just a problem. "I want to achieve X, I've tried Y, I'm stuck on Z" gets a far better response from me than "this is broken."
• Unpolished and timely beats polished and late. Send me the rough draft, the half-formed idea, the early warning. I'd rather course-correct on day one than admire a finished thing going the wrong way.
• Prefer async by default. A clear message (Slack, email, a doc, a PR comment) is usually better than an unplanned call — it gives me time to think and gives us both a written record. Exception: if you're blocked and I'm the blocker, interrupt me.
• For anything substantial, write it down. A short doc or ticket beats a long thread. It's easier to review, comment on, and find again later.
• Default to communicating in the open (channels, not DMs) so others can learn from it later — unless it's personal or sensitive.

• I'll ask a few clarifying questions, then get moving. I won't interrogate you, but I'll usually check the goal and the constraints before diving in. Vague requirements are where projects quietly go wrong.
• I work in small iterations. Expect me to ship something rough early and refine it with you, rather than disappear and return with a finished artifact. If I'm heading the wrong way, the sooner you tell me the cheaper it is to fix.
• I optimise for the code that's still readable in two years. I'll favour maintainability and clarity over cleverness, and I'll push back (kindly) on shortcuts that we'll pay for later.
• I write tests first where it makes sense. If you see me building the test before the feature, that's deliberate — it keeps the design honest and the scope tight.
• Assume misunderstanding, not malice. If something I said landed badly, it's almost certainly clumsy wording, not intent. Tell me and I'll fix it.
• I don't always send acknowledgement messages. No reply for a bit usually means I'm heads-down or overloaded, not that I'm ignoring you. Nudge me if it's time-sensitive.
• I'll give you honest, direct feedback — and I want the same back. Feedback is a gift, even the uncomfortable kind.

• Goals first, then sprints. I like a clear objective and short, visible cycles of progress against it. Momentum compounds.
• Maintainable above all. Readable, well-tested, boring-in-a-good-way code beats a clever one-liner nobody can touch.
• Tight feedback loops. The faster we learn we're wrong, the better everything gets.

• Discord: izman48 — best for a quick message or to start a conversation.