My intention behind this post
My idea behind this post is to perhaps give you a push to think about this topic. Besides that, I can give you some thoughts as a junior developer and how I perceive this case. So if you are a senior developer and you need to guide your youngster through your projects or code, this may help you a bit to separate the good from the bad. You can even read this post if you are not that experienced.
You join a new team and get a bunch of code from your colleagues
Back in the days, this headline would have given me the first panic attack. But now you are here... in front of your monitor and you read all the code and try to understand what's happening there. After some time you've spent with the code, you still got no clue. I guess this situation would look familiar to everyone who has been in this specific situation. And that's not wrong at all.
What you can do as a junior to have a better start
Don't wait until you are down the rabbit hole before you start asking for some help. Part of not asking your questions when you really need to, through fear of appearing like an idiot to your colleagues, is how you end up building the wrong things and write bad code. Asking questions is one of the most important things that you need to learn in your career.
Don't be afraid to say something in meetings, reviews etc.
This may sound like a normal thing to you. But have you never had the feeling that you wanted to say something, but you don't because you are afraid that you say something wrong? Next time... go for it! The worst thing that can happen to you is that you are wrong.
Document your code!
That's right! Your code is not self-documenting. Good comments will help you to spot errors or help other colleagues to understand your code snippets.
Seek constructive criticism.
Praise is important too, don't get me wrong. But constructive criticism is also essential to help you to improve as a developer. The criticism can help you to identify your problems and to improve your code, documentation, behavior in some cases. A good way for this is a team meeting or even the comments in your merge requests.
Pair program with more experienced colleagues.
Pair programming or reviewing your code at all can be frustrating. They're most likely faster at writing code, faster at solving problems and faster at identifying the cause of bugs. It can be painful if you still working out all the shortcuts in your IDE while a more experienced developer already fixed the problem. Sometimes it will feel more rewarding to solve problems on your own, but you may not learn as much.
Great ideas for junior developers but how can I help them out as a more experienced developer?
Well, this one depends a bit on your own personal favors in my opinion, at least for the explanation part. Maybe you have a good time with your student while you explain him something with practical examples in your already written code, or you feel better if you explain him something oral. In any case keep one simple thing in mind: "Guide those who want to be guided."
Keep your willingness to reiterate and explain the same thing differently without getting annoyed.
This is a serious thing. Like explaining something for 2 or 3 times and the opposite part won't catch up your thoughts? I bet you've felt that way before. And then you felt a bit annoyed or you just don't know how to explain it to your student in any other way. And that's okay. But please don't rage on your junior and please don't call him dumb, or something similar to that.
Don't touch their keyboard!
To give you a short summary: Just tell your junior <b>how</b> to accomplish what they are trying to do, but do not do it for them.
Make Room for Mistakes on both sides.
To err is a human thing. You and your junior will eventually make mistakes so it is best to resolve the issue and communicate precisely that this is not a big deal. Mistakes are a crucial part of the learning process.
Adapt the good practices from your team right from the start.
I mean what's the point to practice your good practices in your core team without your new colleague? It's better to take extra time to teach them the right way then to try and change their methods later on.
Be open to keep learning from them.
Maybe because they're at the beginning of their "process" they probably spend more time than you learning, and it's possible that they learn something that you didn't know. And even if you don't learn the newest tech-related things from your trainee you will learn a lot about your profession, about your junior as a person and about your teaching methods. So don't think of yourself as a complete developer because you can always learn something new.
If you want a skilled colleague on your site - invest your time!
Easy to say and hard to master. Often this is the point why your junior dev's start to build up things the wrong way or they spend too much valuable time finding the problems themselves either because they are too afraid to ask you or they are just too proud. So make sure that you prioritize your student above your tasks and keep enough time for their questions.
Are these rules the 10 Commandments on "How to be a good teacher?"
Well, certainly not. These points are just some food for your thoughts. But if you take a few points to heart you can improve yourself as a teacher!