How to mentor programmers

I was reading an entry over at Raganwald where the author talks about managing projects.

He covers a list of things that one should try to do to ensure a project is a success.

One of his main points is that a tech lead should always know exactly what everyone is doing on a daily basis.

Whenever I’ve allowed the details of a project to escape me, I’ve failed. […] And I can tell you, whenever the details of a project have slipped from my grasp, the project has started to drift into trouble.

I’ve been the tech lead on many projects over the last 6 years or so but I’ve always stopped short of asking people what they are doing on a daily basis.

It has always struck me as a form of “micro-managing”, which is something that I’ve hated when I’ve been on the receiving end of it.

I should clarify though; I always know who is working in what area on a day to day basis (Jim is working on the email module for these two weeks), but I don’t necessarily know what specific task they are trying to achieve on a particular day (I don’t know if Jim is writing display code today, or back-end logic).

However, after reflecting on how this has worked on my projects, I have to conclude that my approach was wrong.

I should know what people are doing – I just need to find a balance between knowing what they are doing and getting on their nerves.

Clearly a balance can be found.

I make no apologies for now insisting on knowing exactly who, what, where, when, and why. There’s a big difference between being asked to explain your work in detail and being told how to do your job.

I’m not sure of the best way to handle getting to that level of detail though.

Daily meetings where everyone reports progress?

I find these to be a bit of a waste of time (especially in large teams) where you talk for 2 minutes then sit and listen to everyone else for 20 minutes.

Walking around and sitting down next to each person in turn (sort of like a Doctor doing his rounds)?

This is better for the team as they are only interrupted when I am talking to them.

I’ve done this before but never in a “tell me what code you are writing now” way.

I still think this might annoy me if I was on the receiving end of this.

Another way?

What about other tech lead people reading this, what works for you?

Or, if you’re on the receiving end of this, where exactly does that all-important line sit?

6 thoughts on “How to mentor programmers”

  1. I do the rounds and sit down thing. The developers always know to expect it and actually look forward to it with questions of their own or to seek guidance or explanation of requirements or just a historical reference as to how its beed done before in the company.

    There is no substitute for this, it allows you to know if some one is in trouble immediately, if they need help, if the workload is too high, if the system is too much for the person, etc.

    Not knowing this as you say, will lead to delayed deliverables it the best case scenario, and horrible bugs and problems on the worst case.

  2. I’ve always done the daily rounds too.

    Even if you just sit next to them and ask how their night out was, or how their family is – it might sound like small talk but it builds this thing called leadership and it gives them a chance to ask if they have any problems.

    Also, if they have completed something, they’ll show you. If it’s really cool make plenty of noise about it and get the other developers over to come and have a look (this happened loads when I was working on games – sometimes there would be a crowd of 30 people round one desk!)

    The guy/girl whose work it is might be a tiny bit embarrassed but they will also love the fact that their work is appreciated.

  3. I think talking to each developer informally on a daily basis is a good thing, but it should be as a supplement to general good project communication. The tech lead should sit with the developers and be part of the team, that’s the best way to be aware of what’s really going on.

    It’ll also put you in a better position to know when and how to approach each person through the day. There’s nothing worse than being behind schedule, needing the leave the office on time, having 30 minutes of the day left, and having a tech lead or other manager pull up a chair for a “friendly chat”.

    Of course, getting this right is also dependent on other factors, like team size, working environment and other draws on the tech lead’s time.

  4. Whenever I’ve allowed the details of a project to escape me, I’ve failed. […] And I can tell you, whenever the details of a project have slipped from my grasp, the project has started to drift into trouble.

    This initial driving statement makes me think that the original author has never worked on a really big project, that took longer than a couple of months. Otherwise, he would agree with the fact that “it is impossible to know all details of a project”. Also, one of the most important skills of a manager is to be able to deligate. And yet another one: trust in your team.

    Another thing that bother me a bit is that technical leadership is somehow overlapped over project management (but I agree there are cases where this is happening). As the name says it, a technical leader must lead his team and answer technical questions. And I doubt this means detailing each line of code :-). A good technical leader must be able to provide the necessary details to each team member according to their level and also make everybody in the team feel confortable to ask questions.



    .w( the_mindstorm )p.

  5. I agree with the last statement. A manager can’t know every single detail of a project. I can give an example…I translate the texts for sites for people who want to have them in several languages (like this one, for example). My boss only gives me the task and then I do it and he doesn’t need to know more…

Comments are closed.