How telling the sex of a chick can help you teach anything.

One of the most common approaches is to let the other person just do the job and every now and then just check in and see how he's doing, give some feedback, and be on your way again.

This way, the Developer that's learning has enough time to dig himself into the problem and try to solve it, while the teaching Developer can also dedicate to other tasks.

I used this method for some time but I'm not entirely satisfied with it. On those times you check in you may find that the Junior Developer may have lost entirely his track, already complicating matters more than necessary, or actually solving the wrong problem.

At this moment, you have to step in, explain and most surely undo some changes and start fresh. This coming and going, forth and back, it's what makes me doubt of this teaching method. You grant a greater confusion if you leave them with a couple of pointers, leave, undo, redo, leave again, come again, recheck, etc.

On the other side of the spectrum, you have a more dedicated approach, that's going to guarantee the Senior Developer he's not going to have enough time for anything else. Just sitting next to the Junior Developer, taking control of the keyboard, and doing the implementation his own way, but explaining every single step of the journey.

I know it may look like I'm actually taking the easy way out, but stay with me. I actually prefer this method when the Junior Developer needs some more structure than the rest, and the first method doesn't help at all.

In this second method, you can actually expose the best practices that you've learned for many years, in a way that they look simple and natural. You just start writing some tests, and commiting some code, run the tests, see them fail. There's value in explaining what's TDD, but there's a beauty in actually showing how easy and straight forward it can be.

Just write some more code and make sure the easier cases pass, explaining that you understand that you're taking an active decision in making the code super specific this time, but that at this stage is more important to get those tests from red to green. You commit again and you've already explained another concept.

Once all your tests go green, it's time to refactor. And you can already explain your developer how this process, generally understood as a way to eliminate bad pieces of code it's actually used to grow an architecture from within.

So, instead of doing something, trying to explain why it's wrong or not that correct, and doing it again, you can actually teach how the code grows alongside the requirements and the changes, that you don't need complex solutions, until you actually need them. You teach while you do, and the Junior developer can actually see your train of thought, making it his own without ever considering. Take this as one example of chick sexing.

If you repeat this process a couple of times, I think you'll get faster results while conveying your past experience, rather than teaching one particular concept.

Obviously this requires also a commitment from the Junior Developer in understanding that this is just a method and that he needs to take it as just that. He will learn others or came up with some of his own, but for the time being, he needs to accept the teachings.

This doesn't mean at all that he should just accept things as they are and never question them. Question EVERYTHING, but understand that a methodology is not just a random piece of knowledge, it's just a way to do things that it's proven to bring results.

And nothing impulses learning forward than seeing results from the bottom up.