I have been writing code professionally for 10 years now, and in that 10 years I have forgotten what it’s like to be a new developer.

There are a lot of things that have changed in those 10 years. The first half of my career, 2004 to 2009, was in a different culture than where I am now: Microsoft .NET-land. I dipped my toes into Ruby and the OSS community in 2008, jumped in wholeheartedly in 2009, but by then I had years of experience. Not a ton, but enough to where I felt comfortable in my skills.

Over the next 5 years, I worked with numerous clients, from start-ups to Fortune 500 behemoths. I was a co-founder at Watsi (go donate!) and have contributed to a lot of OSS projects in different ways. All the while, I’ve tried to help foster the next group of new developers through code reviews, pairing sessions, Q&A at different local events, etc. Needless to say, I’ve tried to help where I can, and believe myself to be relatively good as a helper and mentor.

But back in November, I was reminded of what I don’t know, and that even with all my experience I still need to be constantly improving myself.

In November I experienced a failure as a mentor, one that I am happy to talk about. Take a few minutes to read through the comments on this pull-request for Calagator.

Notice my Ah ha moment? It was real. I was not backpedaling, nor was I trying to “save face” or “play nice.” I had not spent the time to look at things from Natalie’s point of view. This oversight was my mistake, not hers. This oversight meant that I caused the person I had intended to help to have a negative experience and to feel unnecessary anxiety.

What I’ve been mulling over since then is the notion that “experts” need to not just help educate, guide and foster, but must respect the path and nuances of that path new developers wish to take. It’s easy for the established developer to say “Well, you should just do it this way,” especially when it comes to code, our domain of expertise. What we forget is that “this way” is really “my way”.

It’s their journey to take as they wish. There are many things to take into account: health of the code base, history, practice, and best practices. But OSS is not just about the text in a file, it’s about the people. Understanding that people have different backgrounds and motivations is key to successful interactions.

I want to be a guide, not a conductor. But I’ve realized with this incident that these things are very social, they can be emotional and they deserve patience and thoughtfulness on my end. When I say emotional, I mean it. I inadvertently caused someone to feel anxiety, which was not my intention! I must be careful what and how I communicate. It’s part of my responsibility to understand her point-of-view, not just advocate for mine.

This pull-request was a learning experience for me in a social sense, just as much as it was a learning experience for Natalie in a technical sense.

Consider these aspects in your next interaction with a new developer and see if you learn something about yourself and how to be a better developer.

Thanks to Davy Stevenson, Brian Shirai, Jacob Rothstein, Hadiyah Mujhid, Ravi Gadad, and Pat Maddox for reviewing drafts of this post.

Speaking of Pat, he’s been working very hard for the last 6 months to create the best way to learn Ruby: RubySteps. Check it out and recommend it to a friend.

- Jesse