Everyone, Including You, Has Something To Teach

Dear new developer,

I am happy and amazed when new developers help out other developers. I’ve seen several new folks go back and mentor at a bootcamp. Or present at a meetup. This is great, because everyone has something to teach.

You may think to yourself: “No! I am learning so much right now. I don’t know anything. There’s no way I could teach anyone something.”

False.

There are at least three ways you can teach something.

I will note that some people are less willing to learn from people they consider “new”, but some people have a hard time learning from anyone, for that matter. Always be aware that the first step in teaching is to teach in a way that the student can learn. That may be socratic, it may be by example, it may be by formal teaching methods. Also, it’s important to realize when you are just starting out that you are unlikely to have the full context for why a system or codebase got to where it is. Never trash code, even if others are doing this, because you just don’t know what constraints that code was written under. When I am new, I always couch my suggestions for improvement in terms of “This is what I think, based on my knowledge of the system. What do you [person who has been working on the system for longer] think?”

That said, here are valuable ways you can teach someone on your new team something.

• Use your lack of experience to ask why things are a certain way. “I don’t understand” is a key phrase here. Questions like: why do you have only one server? Why are you using that language for data processing and this one for webdev? Why are we hosting git internally instead of using github? I always love when a new person starts at a company where I work because they are the antidote to the “fish in water” syndrome. Sometimes you live with systems for so long that you don’t remember why they evolved to where they are, and a new person can come in and cause you to re-think decisions. So by the simple act of asking questions, you are teaching others to re-evaluate the systems they may have become used to. Write down the answers.
• Bring your new technology experience. “What do you think about trying XXX” is the key phrase for this tip. Chances are high that if you are a new developer you are trained up on new, popular technology, either through your schooling or through self study. (If not, this tip doesn’t apply.) New functional javascript frameworks, for example. Look to see where new technology or techniques may be helpful. Again, don’t proclaim “we should do it this way, this is how we did it at school”. That’s not helpful. But bringing your experience with newer ways of doing things is helpful. I met someone at a conference who worked with an old technology (Cold Fusion) but was introducing Test Driven Development for his own code, after discussing it with the team. This is a perfect example of someone bringing their own newer experience. The team may or not may be receptive, but that’s a different kind of problem.
• Niche down. If you have the ability and the time, you can find areas of a codebase that are neglected and study them. You can ask other team members where poorly understood areas of the codebase are; the key phrase is “What parts of the code are scary?”. Try to really work through what is going on. (Bonus points if you write up tests.) Depending on the size and complexity of the code base, you may be able to in short order become an expert, or at least be ahead of anyone else. Then you can write up documentation to help other people understand this area.

Whenever you are new someplace it behooves you to be humble. You don’t know what you don’t know. But that doesn’t mean that you need to always be the student. Be delicate, ask questions, but realize you have something to teach as well as learn.

Sincerely,

Dan