Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I have read a junior mentoring topic which answered most of my doubts. However this topic gives general (though very good) advice on mentoring, while I am mainly interested in what a mentor's week looks like.

This is my case. I have a junior (1 year of experience) who got a new project and I am mentoring him. While I am sure that he will use google and will not ask me silly questions, I want to make sure he's on the right path and not to create structures which are hard to maintain or slow in execution.

Now, should I:

  1. Check out the code each day and examine it?

    • Pro: detect errors in its root
    • Con: time consuming, may overlook something as there is a work day behind me as well.
  2. When he needs to implement let's say singleton, do I tell him to find it on google and come back to me with a solution? Or I let him implement it and later review it?

    • Pro: he does not wait for me to reply to him.
    • Con: he may implement it wrongly and lose precious time.
  3. Are there any situations when I can just check the result? Just like I am a QA. Or I must always stick to the code review?

  4. At what point should I stop being a mentor? After how many projects or after how much time?

  5. Anything else I have missed?

share|improve this question

closed as too broad by gnat, GlenH7, MichaelT, Kilian Foth, Dynamic Jan 29 '14 at 23:42

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs. If this question can be reworded to fit the rules in the help center, please edit the question.

please no singleton, it is bad, it is evil, do not show it to the next generation... –  Peter Kofler Jan 26 '14 at 21:59
Singletons are occasionally necessary. They are very frequently misused sure but they are sometimes necessary. –  World Engineer Jan 26 '14 at 22:02

1 Answer 1

ad 1) I would do a quick review of all his changes when they are incoming to your local machine. The daily (quick) code review of new changes (of maybe even the whole team) works fine for me and you see things quickly. Sure it takes time but reviewing a single person should not be so bad. Look for a good tool to help you here, e.g. Eclipse Sync View works great for some version control systems. Also you know where to look and do not bother with bean methods or basic stuff. That is quickly scrolled over. If you do not understand sth immediately, go and discuss it. Likely it is bad.

ad 2) For small assignments review is ok, for larger work packages I would check the plan and assumptions and decisions of the Junior before, so not too much work is lost if he chose the wrong things. Also remember, he/she needs to learn, so short discussions and reviews are helpful.

ad 3) think of feedback, we favour feedback like Pairing, TDD, CI. Surely you want feedback on him also asap. So yes, need to review. At least until you stop finding issues and start trusting him/her.

ad 4) as I said, when you stop finding issues and start trusting him/her. Probably you will always find issues, we all make mistakes, but some day the have to live on their own.

share|improve this answer
what does "ad" stand for in "ad 1)" etc? –  gnat Jan 27 '14 at 11:28
@gnat to, as in, "in reply to point 1) {stuff}", "in reply to point 2) {stuff}" etc –  AakashM Jan 27 '14 at 11:43

Not the answer you're looking for? Browse other questions tagged or ask your own question.