Mentoring Junior Developers
Starting out as a software engineer back in 2000, there was so much I didn’t know. I was paired up with a much more experienced developer who became the manager of the team and there were a few things that I learned that I still use to this day. But, there are a few more things I picked up over the years that I wish I had known when I started… and we’re not talking about documenting code.
I’ve mentored junior developers and each one has specific knowledge gaps that I help them fill, but in general, there are a handful of things that are the average among them.
Get It In Writing
First, the biggest thing that still helps to this day is getting any request or changes to a request in writing. I would work on whatever changes came my way based on brief talks and then when I would implement them, there would be pushback saying that’s not what they wanted.
When I started asking for these requests in an email because I had other things on my plate, I found that I had proof of what the person wanted if they pushed back. If they did push back, I would refer to their email and say; ‘Okay, let’s take a step back, set up a meeting to go over everything we need to do, and document it so that everyone is on the same page.”
Even now, as I’m leading a team at work; I have to interface with the CEO, VP, QA, product owner/business analyst, etc. As new information comes in about a project, I provide a bunch of questions that the developers need and ask that it all get documented in the stories so that the developer knows what to do and QA knows how to test.
Don’t Be Afraid to Ask
A ton of developers feel like they have imposter syndrome and asking for help is a sign of incompetence. Here’s the thing, by asking for help it means that you have probably exhausted everything you could think of, researched other solutions, are willing to learn, and won’t quit.
We’ve all been there and I still ask for help, even after 20+ years, when I don’t know something… even from junior developers that may have specialized in something I haven’t.
Not asking for help will cause anxiety and may even lead to burnout. You get stuck on a problem and are starting to run out of time from the estimate you gave. You’re asked by team leads and managers how your work is going and you don’t let them know that you haven’t made any headway. You eventually get assigned to another feature and someone else completes the work you couldn’t finish.
All of this could come up during reviews and you will be paired with a senior developer who will work closely with you for the next few features. You’ll feel like you’re being micro-managed and will get frustrated, but this is so that you can freely ask questions and get shit done.
You should also not be afraid to ask questions about a project or feature that you be assigned to work on. Review any documentation and if something doesn’t make sense, ask for clarification. Sometimes the people that come up with the project or feature don’t think of every little detail.
Refactoring Is Not Rework
You’ll commit code that you feel is your best work and you spent a lot of time on it. You’re proud of it; but then the code review happens and you’re asked to fix a few lines of code or rewrite a big block of code and make it simpler or more efficient. This is not to discourage you, it’s to help you get better at writing code.
Refactoring can take time, but it’s designed to simplify and make the code more scalable. Over time you will start to see patterns for how certain things should be written and what’s the best practice for dealing with specific features.
As a senior developer, you will review a junior developer’s code. Provide as much feedback as necessary so that the developer can start to figure out what he or she needs to do and to developer their own style.
If You Don’t Know, You Don’t Know
Most developers will be looked at as geniuses that can do anything… not just fix their grandma’s printer. There’s a saying I’ve been saying lately:
Anything can be done, it just takes time.
Here’s the thing though, if you don’t know how to do something, then you don’t know and that’s fine. Yes, you can learn a new language or library to help you get a project done, but it’ll take you more time to get it done than it would someone else who specialized in that language or has used that library for multiple projects.
It’s perfectly fine to say you don’t know. Management will just find someone who can and put you on another project that you can work on. They may even put that project on hold until you learn what you need.
What are some things that you wish you had known when you first started writing code?
If you’re a junior developer, what are some things you have trouble with?