My Individual Contributor README

Hello! I’m David, and I’m excited to work with you. This document is meant to help you get up to speed with how I work as an Individual Contributor. This document is not a binding contract; it’s self-reported guidelines to my working life. It is updated periodically. The structure of the document is inspired by Amy Nguyen’s “Working with me” and the other READMEs I read internally while at Zapier.

About Me

• I’ve been working at tech companies since I graduated from the University of Michigan in 2014.
• I live in the Bay Area with my wife, Vicky.
• I make friends quickly and rarely hold grudges.
• I go by David, never Dave, Davy, etc. “Brownman” is ok if we’re like, on a sports team.
• I’m not on many sports teams.

What Drives Me

This section is the “why”. Jump to How I Work for some of the “how”.

Helping

My biggest motivation comes from knowing I have helped someone.

In a product org, this typically means talking with the beneficiaries of whatever it is I help make. That could be our company’s end-users, internal stakeholders, or strangers who rely on my open source packages. This isn’t a strict requirement for my job, but I’m most gratified (and as a result, motivated) when I know how others have benefited from my work. At Zapier, I made a point to hear from our developers via help tickets, GitHub issues, and StackOverflow.

For managers, pointing me towards examples where I’ve had direct, beneficial impact on coworkers can help energize me out of a slump. For coworkers, an occasional DM letting me know that I helped you never fails to make my day.

Learning

I am the very definition of a “lifelong learner”; I love to learn about the world just for the sake of it. Sometimes, this is even useful for work purposes!

I learn best by doing. Being able to try it out for myself will yield much better results than attending a lecture or watching a video. When I read technical books, I’ll catalogue new info in Obsidian, the app that most closely mirrors how my brain works.

Teaching

I am energized by teaching, especially if I help someone understand something new.

Sometimes, this is direct action (like answering StackOverflow questions, pairing, or mentoring; see below). Other times, it’s educational documents/guides that I throw into the ether, like my Advent of Code tutorials (which I’m very proud of). Answering questions in Slack is basically tiny teaching, so that’s why I enjoy it so much.

Exploring Technical Interests

I don’t usually get to work on projects relating to the topics in this list. When I do, it’s a fun bonus! In no particular order:

• Dynamically generating/transforming code
• Creating CLI tools
• Learning a new technology or programming language
• Type systems
• Organizing and cataloguing data (especially with Airtable)

Demotivating Factors

• My work doesn’t seem to matter to the company
• My work or isn’t recognized by our users or my peers
• Meetings are the only way our team can effectively communicate

How I Work

This section is the “how”. Jump to What Drives Me for the “why”.

Task Management

• I do my most effective project work when I have a long backlog of tasks I can work through at my own pace.
• If I don’t have something assigned, I’ll find something to do.
  • This will likely be a minor bug that I’ve been meaning to fix.
  • My doing this could be considered a “feature”; I can fix a lot of things this way.
  • If you’d rather I not do this, help me make sure I always have a “next thing” to work on.
  • To that end, having clear short- and long-term team priorities is helpful for me.
• I’m great at setting task and follow-up reminders in Slack and Things 3, my todo app of choice. If I don’t write it down, I will probably forget about it.
• I’m decent at breaking down complex tasks into Jira tickets. I’m improving on giving each sub-ticket enough info to stand on its own.

Slack

• My Slack status is almost always descriptive and up-to-date. Reading it will help you know when I’ll reply to your message, be it: soon, later, tomorrow, next week, or eventually.
• Slack is almost always open on my computer and I check it frequently during my work hours.
• I’m a Slack completionist: I read 100% of the new messages in each channel I’m in. You can @ mention if I should see a message now, but don’t need to if it’s not time-sensitive and in a channel I’m already in.
• Stripes: I have a work phone, but only carry it when I’m on-call or at an onsite. Personal email / phone is the only way to reach out of work hours (and only in emergencies, please).

Hours

• I usually work in US Pacific time.
• I’ll be awake by 9:30am and online by 10am. I’ll start lunch between noon and 1pm (depending on my meeting schedule).
• Try as I might, I’m just not a morning person.
• My best focus time is pre-lunch or late at night.
• My best time for meetings is in the early afternoon.
• My energy flags around 4pm and I’ll try to take an exercise / sun break.
• Depending on my workout schedule, I’ll wrap up my work for the day either pre-dinner or in the late evening (~10pm).

Meetings

• I try to schedule all my meetings in a single block (aka the Clockwise method).
• I try to keep all my meetings on a single day (or two). At Zapier, I tried to only take meetings on Wed & Thurs.
• I’m willing to take meetings any time during my working hours. When possible, I prefer meetings in the afternoon (see hours).
• I’m also happy to sit and synchronously Slack with you about a topic - that can sometimes be preferred if we’re trading a lot of links
• I can take meetings up to 1 hour before my normal start time (typically 9am) if it’s an important meeting. I have trouble getting up earlier than that and my energy level will be shot the rest of the day.

Strengths

• I know a little bit about a lot of topics.
• Because of how I use Slack, I have a lot of context of the state of the company.
• A lot of my daily energy goes towards making the people and teams around me more effective.
• I’m good at writing code interfaces and understanding how consumers will want to use our code.
• I enjoy documenting code and processes.
• I’m good at breaking down problems.
• Pub trivia. Mostly because of the aforementioned breadth of knowledge.

Weaknesses

• I tend to program “by feel”. If a test reports an off-by-one error, I’ll tweak a line and re-run the tests. If that works, great! If it doesn’t… I’ll try, try again. If that doesn’t clear it up, I’ll actually read the code and make the correct fix.
• I’m quick to suggest re-writing existing code, especially if I don’t understand it well or think I can modernize it. As my manager/PM, you’ll probably need to talk me down from this occasionally.
• Because I spend so much time on Slack helping others, my raw code output is often less than that of my peers. This is usually a net win for the team, but is something to take into consideration if we need a lot of code written quickly.
• I’m optimistic - this serves me well in life, but poorly when estimating how long projects will take.
• I’m a horrible speller. These days, computers usually cover for me, but they can only get you so far.
• I sometimes get compulsively distracted by Reddit/Masto/Slack and get stuck in a loop. Taking a computer break usually fixes it.

Outside of Work

• You can find me on most sites as @xavdid.
• I’m mostly a homebody, although I have traveled a lot. I road-tripped cross-country in a van for six months with my then-fiancée; ask me about #vanlife!
• At home, my major hobbies are:
  • video games (favorite genres: puzzle, adventure, narrative, co-op)
  • tinkering/programming (either on something novel or something useful, but rarely both)
  • board games, especially with friends
  • blogging, occasionally
• I’ve always had an interest in alternative computer input methods. To wit:
  • I use an Ergodox-EZ as my main keyboard for programming and PC gaming. I love how customizable it is. You can see my full layout (including an interactive tour) here.
  • I’ve got a Steam controller for similar reasons.

Anyway, enough about me. What’s next?