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.”


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.



Learn To Explain Concepts To Non-Technical Users

Dear new developer,

I taught technology courses for about a year and a half, but have been teaching folks almost my entire career in one way or another (everyone has something to teach), primarily through my blog.

One thing I’ve learned over time is that if you can’t explain a technology choice in a way that a non technical user can understand, you don’t understand it. It can be very easy to get caught up in jargon. Jargon in and of itself is not a bad thing. It’s a shortcut. If I say RDBMS to another developer, they know that this is a third party piece of software which provides safe, durable, transactional data storage. (See how jargon builds on itself? “transactional” is jargon as well.) But just like if you take one shortcut after another you’re likely to get lost, too much jargon can blind you. (Or at least put you in a fog.) AWS In Plain English is a great example of how the names of AWS services are confusing and could be improved.

So, learn how to think about technical topics in a non technical way. Then you can bundle it up in jargon later, when you have a clear understanding of it.

One great way to do this is to learn to explain things to non technical users. You can do this via writing (a blog), speaking (at a meetup), or just talking to someone in your life (parents, friends) about what you do for a living. Lots of people are mystified by software and are happy to learn more about it. You can start as small as you like (“what’s a directory?”). Go slowly and try to explain exactly what you do. An example for a site I worked on is “we pull information from a couple of different sources and publish it.” (I confess, I had to write slowly and rewrite that sentence because I used jargon.)

Other benefit of learning to do this is that as you continue your career as a developer, you’ll typically spend more and more time around non technical people. These folks make decisions that affect business and software, but they won’t always understand the latter. If you are well versed in explaining technical concepts, you’ll be valued and be able to be at the table when decisions are made.

So, if you can explain something non technical, you gain:

  • clarity for yourself
  • the ability to teach others
  • influence in your organization

What’s not to like?