The title question is certainly too broad for an answer here: books have been written on effective mentorship. Instead, I'll focus on your comments about micromanaging.
I was told by my boss that he is into gaming and that I have to push him so that he delivers.
Set frequent goals. Let's do X by tomorrow and Y by the end of the week. If they meet these goals (or have convincing reasons for what they tried, where they got stuck, and how they tried to get unstuck), then there is no issue. As they come up to speed, they will start setting these goals for themselves and you can step back.
If they are frequently turning up with minimal progress, then you might consider some set working hours (e.g., 1-5 on MWF). This is not meant to be punitive, but helpful -- if they are just down the hall from you, you can check on them often and probably greatly speed things up. If there are other peers they can sit with, so much the better. Once the project starts moving, it becomes fun, and they will likely stay engaged on their own.
However, when I let the student figure things out on his own, he will get stuck for days on something trivial. When I find out what he has been trying to do, I think "Why did not you ask me before, you wasted days on this and we could have solved it in a few minutes"
Beginning students do not know what is trivial, what is tractable, and what is hard. They similarly do not know what already exists versus what they need to do from scratch; so, they may spend far too long reinventing the wheel. Some inefficiency due to this is inevitable.
The solution is frequent, brief check-ins and/or asynchronous chats. Impress upon the student that if they're spending more than a few hours doing something, you should know what it is. That doesn't mean you need to micromanage their time -- if they are reading a paper and implementing it, that could take a week, and all is well and good; schedule a follow-up for a week later. But if in the course of this, they spend more than a couple of hours trying to understand a particular equation, they should ask you about it and get your concurrence before spending additional days trying to figure it out on their own. They'll eventually get a better sense of when to come to you versus when to dig in on their own.
Also when I go through his code I find stuff that I do not like, that is not well done. So I want to change every little thing he does, this is again micromanaging. On the other hand I do want things to get done properly and if I am going to change everything he does, then I might do everything myself, because it pretty much takes me the same amount of time.
Code is tricky for the reasons you mention. I have found a few guidelines.
Never debug your student's code.
- If the code doesn't work at all, they should figure it out on their own or with their peers. At most, you can have them explain it to you; this may reveal conceptual problems that you can explain on the whiteboard.
- If the code does work but the results are not reasonable, you can ask for cross-checks. Explain why you are skeptical and suggest some tests that will either make the error apparent or will allay your suspicions.
Never edit your student's code.
- In most fields, most code is "private": everyone writes their own. This holds also for your student -- they should be giving you only qualitative outputs like charts, figures, or tables. The code they use to generate these is entirely their own; you never edit it, download it, or (in most cases) even look at it.
- In other fields, some/most code is "shared": the lab has a complex codebase that everyone contributes to. In this case, your student's code will have to meet the group's quality standards -- but again, you should limit yourself to explaining what the problems are. You should be able to articulate the problem, even if it's just stylistic, and they can fix it from there.
Give lots of feedback
- Similar to your comments above, students can spend hours writing a simple script that you could have written in minutes. Part of this is experience, but much of this is workflow. Students won't even know what a good workflow is until someone shows them.
- "Research code" has its place, but it would be good if students had at least a vague awareness of higher concepts such as data structures, memory management, scalability, profiling, version control, IDEs, Linux and its native tools, advantages of different languages, etc. It is a real shame when students spend thousands of hours coding but never really get beyond functions and loops.
