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.

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?

share|improve this question

closed as off topic by bigown Dec 29 '10 at 17:27

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.

    
Point them in the direction of great online resources like this and joelonsoftware. –  Morgan Herlocker Oct 13 '10 at 0:03
    
Please follow this proposal for that kind of question: Organization aspects –  bigown Dec 10 '10 at 19:14
add comment

12 Answers

up vote 22 down vote accepted

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

share|improve this answer
    
+1 for the level-headed perspective. –  George Marian Oct 12 '10 at 21:32
add comment

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:

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

share|improve this answer
add comment
  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.

share|improve this answer
add comment

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.

share|improve this answer
    
Come to you eh? Can I have your email address ;-) –  Toby Oct 12 '10 at 21:42
2  
@toby As long as you come with a check or, preferably, cash. ;) –  George Marian Oct 12 '10 at 21:53
add comment

I would do pair programming with him for a while.

share|improve this answer
add comment

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

share|improve this answer
1  
The thing is as well, most of the time it is going to be true –  Toby Oct 12 '10 at 23:00
    
+1 because it can be difficult to mentor without being patronising –  Gary Rowe Nov 24 '10 at 16:11
add comment

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.

share|improve this answer
    
+1 for unit testing and code review –  Belun Oct 12 '10 at 21:38
add comment

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

share|improve this answer
    
humility is overrated. (or not) –  WalterJ89 Oct 12 '10 at 22:03
add comment

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.

share|improve this answer
add comment

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.
share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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