**Duncan — Senior Support Engineer (Pacific Time)**
This page provides some background on the subject of the page (me) to the reader of the page (you).
## Related pages
[Error Documentation](https://errdoc-18480b.gitlab.io/) · [GitLab API Helper](https://gitlab-api-helper-1aa28e.gitlab.io/)
## About me
I'm a Senior Support Engineer based in Fremont, CA. I build tools that make support work more systematic — the error documentation site and API helper linked above are examples. I like to abstract problems away from the specifics to help conceptualize the underlying failure.
A lot of my focus goes toward improving how Support works, both within the team and across teams. That means authoring RFCs, building tooling that helps others debug faster, and mentoring and coaching other engineers on our technologies and workflows. I want to enable people to action on their own ideas and issues rather than being a bottleneck.
## Coffee chat stuff
If you're reading this, feel free to drop a [Coffee chat](https://calendly.com/drharris-1/30min) on my calendar. Some stuff I'm interested in:
1. Apiculture — I'm a beekeeper and love all those bee things.
2. Zymurgy — I also brew stuff
3. Making things — Cooking, clock-making, telescope building, etc. I always have a project being worked on.
4. Video games, but often funky indie games
5.[Redactle](https://redactle.net/), a daily puzzle game I love a lot
6. Board games
## How you can help me
Put it in writing, ideally. We're an async org and it's a lot easier to work via Slack or comment threads — a short message or comment gives me time to think it through before responding. Be specific about what you need and when. "Can you look at this?" is harder to act on than "Can you review this MR by Thursday? I'm unsure about the error handling in `lib/api.rb`."
## My working style
I'm async-first. My working hours vary a bit, but I'm generally near my computer during CA working hours.
I like thorny problems; in Support, it's not always easy to scope down an issue. I'm happy to take a look at tickets and conceptualize the underlying issue and figure out what we need to look at. I'll try to understand it inside it's system.
I'm always looking for places we can add tools to help with discoverability and debugging. If I see a workflow that could be smoother for the team, I'll usually prototype something and share it rather than just suggesting it.
I'd rather be wrong and learn from it. If I can't find the data I need or I'm not sure, I'll ask.
## What I assume about others
I assume you're acting in good faith, even if we disagree on approach, and that you'll tell me directly if something I'm doing isn't working for you.
If you assign something to me, I'll assume you've thought about whether I'm the right person for it and try to work it. I'm always happy to talk over the approach or scope if needed.
Silence in async means you're busy, not that you're upset or disengaged.
## Communicating with me
Written async is my strong preference for anything that requires thought — feedback, decisions, technical discussions. I give better responses when I can process before replying. For day-to-day work, Slack or @-mentions are the fastest way to reach me.
I'm happy to talk stuff over on a sync call, but I prefer a clear agenda. I'm generally available during CA business hours — just drop me a line and I'll get back to you during my working day.
Short messages from me are just efficient, not terse. If I send a one-liner, it means I didn't have more to add, not that I'm annoyed.
