Being a good mentor [closed]

Question

If you had a student or junior developer who was competent but just had no real world experience how do you think it would be best to mentor them or what information could you give them that would ease their transition from newbieness into leetness?

Answer 1

Hm, there are many things to mention, but I think the most important would be:

Try not to sound like a giant arse.

In other words, don't be pretentious. Understand that you are as "lame" as he is, only on a different level. He will make mistakes, and you need to explain why are they mistakes, not simply shout at him for making them. I guess you have to keep in mind that you make mistakes too. Make him realize that mistakes happen and that he should not blame himself, instead, he should learn from his mistakes to avoid repeating them.

Also, try to learn from him. Be modest in your teaching. He may lack experience and technical proficiency you have, but he may have insights you don't. As with any teaching, listen, then talk. It is very important to figure out what's troubling him and what are his strong points.

I'd probably start by giving him a smaller project and review the code with him, then gradually introduce complexity when I feel he's ready. Even if it fails at first, he'd gain something from it.

But try to instill some values of course, things like discipline, consistency, communication etc. Let him know he can ask any question, no matter how stupid it seems, without feeling like an idiot. If he's afraid to ask, he may never learn...

Answer 2

i would teach him design... and the rules behind the design (see the book Head First Design Patterns) and SOLID principles (see wikipedia) and basics like encapsulation, information hiding. and also some clean code (see Clean Code the book)

i would basically give him 4 articles, 2 books and 1 site:

• Encapsulation is not information hiding
• Tell, don't ask (article)
• More on getters and setters
• Why getter and setter methods are evil
• Head First Design Patterns (book)
• Clean Code (book)
• PrinciplesOfOod

this list refers to object oriented programming languages, but most languages out there are object-oriented.

if, on the other hand, you're teaching him functional programming, you'll have to search for some materials yourself

anyway, the idea remains the same: mentor him to write clean code that adheres the core principles of the language; you will make his life easy

Answer 3

1. Think about all the stuff that, once you discovered them, changed completely the way you work as a programmer, and which you wish somebody had shown to you earlier. Tell him or her about it. For me such thing was Test Driven Development. If I had met somebody who was good at it a couple of years earlier, I would be a much better programmer today.

2. Show him or her the right tools. Share your .emacs file, help him with the source control system, show screen and some of those neat shell tricks.

3. Don't micromanage. Don't be afraid that he won't be able to cope with the problem. His approach may be different than yours (and in a lot of cases: plain worse), but he'll learn a lot in the process, and it will be yet another thing you won't have to do (which is always good). Also, let's face it: almost everyone has his overengineering period in life, andby ruining all the fun you won't make it go away more quickly :P

4. Give feedback, and give it often. Review his or her code and talk about all the strong and weak points. When you are criticizing, make sure you are criticizing the code, not the person.

5. Try to learn something from him or her. Knowledge acquisition is much more difficult when you get older, and dealing with younger people may help you not to lose touch with the cool new stuff.

Answer 4

I'd point them to a list of books and tell them to come to me with questions.

The Mythical Man Month
Code Complete
Design Patterns - Elements of Reusable Object-Oriented Software
A decent book on computer architecture.

This question on SO can give you some other ideas for good books.

Beside that, I would spend time with them discussing various topics as they warranted, asking them questions and reviewing their code.

Answer 5

I would do pair programming with him for a while.

Answer 6

One thing I let people know when I mentor them is that I learned some of these things by making the same mistakes they are making. I think this makes my level of expertise seem more attainable and makes it seem less as if I'm saying, "Ha, I'm smarter that you."

Answer 7

Have them write unit and integration tests for one of the projects. This will improve their coding abilities and greatly advance their understanding of your system. Most importantly, have review sessions with them, where the first several times you review each line of code. This will hopefully identify some areas where they could improve. Also, never judge, but politely point out best practices of doing things as you review their code.

Answer 8

The first step to becoming smarter is realizing how dumb you are.

Answer 9

The best person to answer that would really be the student. Show him the project you're working on, give him some minor bug to fix, and turn him loose.

Any competent developer should be able to use basic debugging tools to locate the part of the code for the user interface section where the bug is reproduced. Once he hits that point, he'll probably have a few questions. Answer them as they come up, and try to answer in a way that not only answers his question, but helps him to develop a way to figure out the answer to related questions the next time they come up.

Answer 10

In this order:

• Point out what they are doing right.
• Point out what they can do better.
• Point out why what they did wasn't a good idea.

Answer 11

I'd focus first on creating the right "posture of mind". Once one has that, the rest is much, much easier.

• Make sure the student is getting a steady diet of hacker culture. Our lingo and our humor might seem trivial to the outside observer, but they are merely tools for nudging one into a certain way of thinking.

• Helping the student grow in whatever programming language he/she already knows is fine and dandy, but there comes a point when one needs to go beyond that by:

  • Learning many languages, even some one may never use in production, because this is how one gets a feel for language design.
  • Reading great works like The Art of Computer Programming that are about the big picture, not just a language or use case.
  • Listening in on or taking part in the "big picture" decision-making process: Why are we using OO for this project and not for that? Do we want to focus on backwards compatibility, or the cleanest, best implementation of every release, at the risk of making the migration between major releases non-trivial?
  • Spending time around more experienced coders, seeing how they approach problems, and watching them duke it out when they don't agree.
    .

• Encouraging him/her to experiment with different tools and find his/her own perfect toolbox.

• Sending him/her links to whatever you are reading that might be of interest (even if some of it is currently over his/her head).

• Making sure he/she is well-supplied with problems of increasing difficulty, and good feedback on same.

Answer 12

I'd likely ask them how well do they know the tools and process that are used where they are. I'd probably want to warn them of a baptism by fire coming though I'm not sure what use that serves.

While some ideas like pair programming are good, there can be limited use to this in some cases. In some places I've worked new developers tend to get the support tickets rather than the sexy projects, unless they are consultants of course.

That would be my starting point, aside from the usual getting the backstory like I would with anyone new in my team.