On Being Helpful

July 18th, 2018

I spent a lot of time helping others at Sentry. Helping them with their dev environments, product specs, code changes, internal politics, analytics. Just about everything. Here are three-ish lessons I’ve learned along the way.

1. Document everything

Slack doesn’t count. Email doesn’t count. Documentation isn’t just good for the organization, but good for you. So much company. You only find the bugs when a user tests them, and in this case, it’s your new hires.

The first time someone asks, answer them. The second¹ time, tell him or her, “give me a few minutes.” Document it and then send it back to them for feedback. Good docs require iteration anyways and there’s no better way to train the next person to also document their progress than by showing them.

It often feels weird to do this: it’s unnecessarily formal, I don’t accrue this social gratitude capital of having helped future people. Nope. The best thing you can do in your career is to make yourself redundant and then go do something else more interesting.

2. Never do the work

Like I said, it’s always good to answer questions the first time. If you’re anything like me, it’s intensely tempting to reach over and start typing. Especially when someone comes to you with a broken dev environment, where the answer is often immensely complex and beyond a junior engineer. Try to ask leading questions. Write down a process and then lead them through it. “Did you rm -rf nod_modules?” is one of my favorite. If you can’t figure out what to say to help them solve their own problem, go find a mentor on how to be a mentor. Your manager is usually a good place to start.

As a mentee, never come with the assumption your mentor can/should help you. Treat them like high school math teachers. They usually suck at math (most, after all, got a degree in teaching), but they are good at teaching math. You shouldn’t be learning math from them, but how to teach yourself math.

3. Mentoring is a culture, not a department

My biggest mistake is thinking that mentoring can be resolved in an official capacity. My greatest mentors were reluctant to think of themselves as mentors. Just “friends who have seen this problem before.” Being a mentor has no upside, aside from the satisfaction of helping someone out and no one ever gets fired for being a mentor, so long as they are doing their job. That’s why it must be a culture of mentorship.

That onus isn’t just on the senior people: it’s even more so on the junior people. Cultivating mentors is a skill that, as a mentee, you absolutely must develop. Being able to ask for help is step one. Being able to bring others along in your journey is step two.

Never assume a mentorship program will solve the problem. Like all “official” things, they ultimately rely on short-term metrics, but the best mentors are long-term relationships. They are forums for discourse, not schools.

I’ve benefitted tremendously from the help of others, so when I think of mentorship, I often think “If only I’d had someone to help me, I wouldn’t have spent hours and hours googling to fix a stupid config error.” I’m forgetting that one of my greatest assets today is my ability to self-diagnose and problem-solve, both in code and career. These lessons are the same: me self-diagnosing and solving against my own bad mentorship habits. I feel confident in these, but I am similarly confident these will be the first of many lessons.