This question maybe similar with this one. However my condition is different. Moreover I think this question better suited for workplace rather than pm, since I'm not yet in role of manager. This question does not limited specific to programming, while in my condition it is programming activity.

Currently I am assigned as team leader at the new company, or you can say as a supervisor instead. I have one subordinate. I am responsible to manage my subordinate, while at the same time also responsible to develop the system required.

My subordinate is not a star developer. He can do his job and develop a system as required. But the system developed is not that clean (you can say that the code is dirty, some duplicate and hacks). I believe it is caused by his lack of experience and knowledge of maintainable system.

That is why in the last several weeks I only give him the task for UI-level only while myself constructing the foundation for business and data access layer. But even in the end, in spite of time requirement, I take the UI level development in parallel, found some dirty code in his system (which I also had done the same in past few years) and replace some with more cleaner code.

I believe this is not a right thing to do (micromanaging). However given the situation I do not have time to train my subordinate, and trusting him with more challenging work will give higher risk in the future. Is there something that I can do to handle this situation?

  • 1
    Do you have regular one-to-one meetings with this developer? Does your company have any code peer-review practices in place? – Mike Feb 25 '14 at 13:48
  • Is your subordinate mostly just inexperienced, or is he experienced and working on stuff that is just above his capabilities? – Bart van Ingen Schenau Feb 25 '14 at 13:55
  • 1
    This question appears to be off-topic because it is about programming not about navigating the workplace. – IDrinkandIKnowThings Feb 25 '14 at 19:07
  • 1
    @Fendy I agree with Chad, because while your phrased your question to be about the micro management part, what you're really looking for is a way to increase their code quality without micro managing every step. And that is something better suited for a programming related SE, because techniques for doing this would not necessarily translate to a lot of other industries. – CMW Feb 26 '14 at 9:38
  • 1
    Then those questions would belong on the Printshop.SE or CE.SE... this SE is for dealing with general workplace navigation questions not specific job functions like this. – IDrinkandIKnowThings Feb 27 '14 at 17:07

So instead of "managing" him, you need to Mentor him. Show him how it's done rather than review/replace his code.

To do this you need to be working on tasks together (rather than him doing something and you reviewing it and updating which is taking you additional time).

So you start on a piece of work, hand out sub tasks for him to do, he can ask you if he has questions and you are reviewing as you go. He'll learn the correct way, and you'll still be productive (although you'll be working in smaller blocks, at the moment you may seem to managers like you're working on multiple areas at once)

Over time he'll learn the right way to do things and the code standards required, at which point you can start to diverge and let him pick up work on his own.

| improve this answer | |
  • I think this can be done. However since my team is new and there is much things that I must develop (at framework level, for example, or custom publishing tools and guidance). It required a very detailed knowledge with the language and experience for framework-level. Moreover it is abstract. So I don't think it will be suitable to share the work though. However I will try, maybe 10 hours a week, to do what you had described. – Fendy Feb 25 '14 at 14:07

I think you are handling it the wrong way, what's happening right now is: He's doing work, and you're replacing it. So what do you need him for, exactly?

If you would like to have this person in your team you need to understand that this will affect the time it takes to finish the job, then you should:

  1. Mandating code reviews before every code commit (this applies to the both of you), even if it means several reviews a day
  2. Having design review meetings
  3. Highlighting interesting changes in the code (by email, in meetings, etc.)
  4. The most important: Treating your subordinate as an equal and not a mediocre developer
| improve this answer | |
  • 1st is done for not every commit, but once in a while. I already planned the 2nd. I am trying 3rd. It is hard to do the 4th though – Fendy Feb 26 '14 at 1:18
  • @Fendy - It is hard to do the 4th though -That is a flaw in your character not in the other developers. – IDrinkandIKnowThings Feb 27 '14 at 17:09
  • @Chad If you were in my position, would you tried to treat him as an equal? If that so, will you give him the "same" difficulty of task and expect him to do the same? I don't treat him as inferior, he is just different. Moreover for commentator: "Leave constructive criticism that guides the author in improving the post." – Fendy Feb 28 '14 at 1:21
  • This needs to be gradual but doesn't mean it will take 5 years, you (the both of you) can try splitting tasks to smaller sub-tasks, let him do the design to allow to be more involved, give him the extra time to figure things out because this is the way to become more skilled – Sigal Shaharabani Mar 2 '14 at 12:05

I think you need to have a conversation with your boss and find out how to balance this situation. It almost sounds like you could build this application in the time you're given if you had no subordinate at all (Sort of the Mythical Man-Month). Your supervisor may be willing to sacrifice some time and code quality if it means getting the new person up-to-speed quicker and make him more useful in the long-term/next project.

There are several levels of involvement. Maybe you can use one or some combination?

  1. Have him do nothing/code on his own, but not for production.
  2. Have him sit and watch you code (sort of like pair programming, but not really).
  3. Take the time to do a code review of your code, so he can learn more.
  4. Let him write code, but only put into production after you've reviewed it.
  5. Just let him write as much production code as possible and take your changes.
  6. Send him to a training class.

Whatever you decide to do, make sure it is in alignment with what your supervisor expects out of you.

| improve this answer | |
  • Interesting, I'll try it. – Fendy Feb 26 '14 at 1:16

As his supervisor, you owe the company and the employee the time to make him into a better employee. That is one of the reasons why you have been given this responsibility and it is MORE IMPORTANT that redoing his work or doing your own coding. Once you start to manage people, the management tasks are more critical than any remaining coding tasks and once you supervise more than 3 people you probably should only rarely (less than 20% of your time) be coding. If you supervise more than ten, then you should not to be coding at all. Management takes a lot of time to do properly. Remember if he has a continuing skills issue then you, as his supervisor, are as much to blame as he is and maybe more if he has not been told by you that he has a skills issue.

When you see a problem with his work, send it back to him and make him do the fix. Never fix subordinate's work no matter how tight the deadline. They will never improve if you don't send them back the work to fix. If you think he will not understand what to do, then sit with him and explain it but do not (unless he is in the hospital!) make the change yourself. You should be alloting time to mentor and monitor this person's work. Your duties as a manager of someone else should generally take precedence over any programming you yourself are responsible for or you become a roadblock.

When I am a tech lead, generally 50-75% of my time is spent managing the people working for me but usually I have 5-7 not 1. Since you only have one and you are not happy with his current skill level, you need to devote more time to him than you currently are. At least 25% of your time should be spent with this person and you should plan that into your schedule at least until his skills improve. And it is inexcusable that you do not code review every piece of code. You have stated that his work is unacceptable, so you need to check all of it. You have to allow time in the schedule for these reviews and fixes until he gts better.

Also remember that you need to apply business standards not just programming standards to his work. Do not make him fix stuff just because you have a preference, only require fixes for stuff that actually does not work. Make sure to explain why what he did is not acceptable. And point him towards what he needs to learn to make the work acceptable, but don't nit pick things that can be left alone for now, make sure to concentrate your first efforts to fix his skill deficiencies on the stuff that actually doesn't meet the requirements. No one can improve if you hit them with too many things at once, so concentrate on the the critical stuff. As he gets better you can require more things.

| improve this answer | |
  • Your answer makes sense, especially with "you should plan that into your schedule". +1 for that – Fendy Feb 27 '14 at 1:33

Not the answer you're looking for? Browse other questions tagged .