Remote Mentoring For Fun And Profit

I've done paid and semi-paid programmer mentoring for a while, and I'm going to tell you what it's like.

In 2010 I ran a coaching service, basically mentoring other programmers for an hourly rate. It made good money, but I shut it down for two fairly capricious reasons. First, I had several people who never showed up for their sessions, but continued paying me, and I didn't have any policy in place to manage things if these folks suddenly said, "OK, I've paid you for ten hours, you have to deliver now." I think the odds of that happening were actually very, very low, but I hate overlooking things like that. (My projects are never quite as haphazard as they seem.)

More importantly, I had planned to do a new mini-business every month in 2010, and the success of the coaching service was distracting me from that exploratory goal. This was actually part of a larger system. In 2009, I set out to create a new site every month, the goal being to a) get better at deploying stuff, b) get better at finishing stuff, c) explore a bunch of random languages and frameworks, and d) get some skill at product design.

That last part definitely worked out; I'm glad to say that one of my 2009 mini-sites got a mention on Mashable, as well as receiving what might be the ultimate hacker compliment, a copycat in the iOS App Store. Anyway, my goal in 2010 wasn't actually to make a living off my entrepreneurial experiments, although this side effect was certainly very nice, but rather to explore a large space of possible options, and learn about them. The coaching program made things too easy, so I killed it.

More recently, I've taken on two students. One of them was an Internet friend who successfully pestered me to re-open the coaching program, just for them; the other was a friend from actual physical space with at least 15 years of experience as a drummer (including a spot on Conan). I offered him Rails lessons in exchange for drum lessons, and he took me up on it. This actually started out as an in-person thing, but switched to remote when I moved to New Mexico.

Marketing

I did virtually zero marketing to launch or perpetuate this business. I blogged about it when I launched it in 2010. I'm blogging about it now. I think that's it.

Logistics

In terms of money, I have people pay ahead of time with PayPal. With my drum teacher/Rails student, we do a drum lesson and then a code lesson. I tried doing the same thing with a machine learning expert — machine learning lessons in exchange for electronic music production lessons — but it didn't really take off.

When I had a whole group of students, I had a virtual assistant set up the scheduling. I didn't go with some company in India or whatever, as Tim Ferriss and others might recommend. I knew a smart operations person from a previous employer, I knew they were smart and capable, and so I had them handle it for an hourly rate. They did great, and it was very simple and painless. These days, since I only have two students, I just set up scheduling myself.

I don't use tmux or screen, which may surprise people. I'm interested in doing that, but in practice, they never seem worth the effort. I used to use Skype; although there's no doubt Skype sucks in some ways, virtually everybody has it, and it got the job done just fine. These days, I still use Skype for video chat, but I use ScreenHero for screen sharing. It's not perfect, but it's a lot less imperfect than Skype, and as a bonus, the NSA probably isn't listening in quite as much. I also use GitHub a lot, for obvious reasons.

Sessions

In 2010 I'd mostly just have the student show me whatever they wanted to show me, and/or ask me whatever questions they had. These days, since I have a much smaller group of students, I prepare material ahead of time more often. In practice, I'm either pairing on code, or giving advice about career moves and/or product design. (A couple of my students in 2010 had startups and wanted feedback on usability and features.)

Hearing people say "pairing" when they mean "mentoring" or "explaining" is one of my Silicon Valley pet peeves — I've found that people in the Valley are often reluctant to learn new ideas, but eager to use the names of those new ideas as synonyms for things that they already do — so I want to point out that it's usually more lopsided than pairing's meant to be in the traditional sense. Also, to be fair to my students, the degree of lopsidedness varies from case to case. And one of the most enjoyable things about doing this is that if you have a student for a long period of time, you get to see the pairing become less lopsided as time goes on. In some cases, I've seen it become much less lopsided, and that's been great.

Anyway, I've also just demo-ed the process of writing Clojure, for a person with a C background who'd done extensive reading in modern web dev, but had no actual experience with it. And for my drum teacher/Rails student, I had him start by writing unit tests for essential pieces of the Ruby language like Array and String.

Recommendations

I'd say any programmer who can teach something, should. I think that's actually a large number of programmers. My guess is that most programmers reading this will underestimate the degree to which they know things that they can teach. I'm not saying that teaching is a universal skill, but rather that the culture of open source tends to over-valorize a small community of "experts."

The minute you get beyond rank newbie status, you have something you can teach. You may have to learn the skill of teaching, but giving talks at conferences and user groups is a great way to build that ability, and it's actually very important to do that anyway. It's no good if you can write great code but you can't explain it to anyone.

Anyway, I say it's worth doing because typically our work is somewhat dry and impersonal, but teaching generates a lot of warm fuzzies. It's fantastic when you see a student succeed (especially when they succeed by following your advice). Also, the more you help somebody when they get started, the more logical it is to assume that they're going to help other people too, once they get a bit more senior.

Any time I see a bit of open source drama or similar group dysfunction — which, let's face it, is whenever I open Twitter — I feel glad that I've done a little bit to make the world of hacking a bit more helpful and a bit less bickery. After all, I only know a few ways to deal with open source drama: ignore it, make fun of it, or find some way to make it at least a little less commonplace. The last method seems the best.

Go And Do Likewise

I think most people who read this will have the ability to do the same thing, and I definitely think you should. Do it for money, do it for free, do it for the warm fuzzies or for political reasons, but one way or another, you should take time to mentor other programmers. It's good shit.