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?

Questions on Programmers Stack Exchange are expected to relate to software development within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here.
If this question can be reworded to fit the rules in the help center, please edit the question.

12 Answers
12

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...

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)

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.

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.

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

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.

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.

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."

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.

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.

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.

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.