> Mentoring should just be pointing people in a direction and occasional code review. Go do this (for a few days). Let's see what you did. That's one (totally

> Mentoring should just be pointing people in a direction and occasional code review. Go do this (for a few days). Let's see what you did. That's one (totally fine) way of mentoring, but it's by no means the only one. A lot depends on the work environment and the relationship. I work with a couple junior engineers that are also friends, and in addition to "pointing people in a direction", code reviews, etc.: * We frequently tackle harder issues together, pair-programming style (using a shared tmux session) * In addition to code-reviewing their work, I have them code-review mine, and I walk them through my code and thought process * Talks/meetings once a week or more about architecture/up-front design for projects, in which the junior devs are often included or free to attend * We have a non-work-related Hackerspace that we attend every 2 weeks where we work on side projects / fun creative projects Certainly this situation is not possible on many development teams, but I just wanted to point out that mentoring is a wide-open thing that has many approaches and options.