Five new junior developers and lots of complex tasks. What's now?

Question

Our company has hired five new junior developers to help me to developer our product. Unfortunately the new features and incoming bug fixes usually require deeper knowledge than a recently graduated developer usually has (threading/concurrency, debugging performance bottlenecks in a complex system, etc.)

Delegating (and planning) tasks which they (probably) can solve, answering their questions, mentoring/managing them, reviewing their code use up all of my time and I often feel that I could solve the issues less time than the whole delegating process takes (counting only my time). In addition I don't have time to solve the tasks which require deeper system knowledge/more advanced skills and it does not seem that it will change in the near future.

So, what's now? What should I do to use their and my time effectively?

Answer 1

Yes you can solve things faster than they can, that's why you are senior and they are not. However, a good senior wants to take his juniors to the senior level as well and the only way you can do this is by letting them learn how to do things.

Mentoring is the most effective use of your time right now, not coding.

Look at it this way, if you spend the next six months mentoring effectively and the juniors learn enough to become intermediate developers - then you have 5 intermnediate develoeprs and one senior. If you do all the hard work yourself because it is faster, in six months you wil stil lhave 5 juniors twiddling their thumbs (well the best of them will have moved on to other jobs by then if you give them no challenging work, so you may have fewer or newer junior devlopers) and one overworked and cranky senior.

You know what complex interactions are typically found in the bugs, so develop some training specifically on those types if things, how to troublshoot and find the actual problem and then the types of methods typically needed to fix them. Then give them those problems as they come up. Yes they will take longer to fix them and you should allow for that in your time estimates.

The pair programming idea is great. Pair with a different one for each problem that is truly advanced. Even if they don't know enough to solve the problem yet, having the junior at the keyboard while you tell them what to try in terms of looking for the cause will help teach them the process of troubleshooting. Of course, don't just expect them to take dictaion. explain what you want them to look for and why. Ask for their ideas and listen to them. Explain why their idea is not a good choice if it is not. Use the Socratic method of teaching by asking leading questions. They will remember better the solution they came up with themselves through your leading questions than the one you dictated to them without explanation. They will aslo remember better if they actaully typed the solution rather than just watched you type it. One of the main priciples of learning is that people retain more if they do rather than just listen.

Once the junior has helped you solve a particular class of problems as part of a pair with you, you can pair him up with someone else the next time that class of problem comes up and only be available for consulting, not standing over their shoulders while they try different things.

You have five new people which is really hard. You need to be fair to all of them and rotate who you pair with or give the guidance to. Don't play favorites. BUt you wil also need to be a person who provides "Tough love" if someone is not succeeding and making progress. YOu may need to call one or more of them aside and tell them that they need to improve and why you feel they are not succeeding. SOme peopel will let you do all teh work if you pair and you can;t allow this just becasue it is easier. If teh person can't do the work, it is kinder to them and much better for your team if you don't carry them once it is obvious that they cannot or will not learn to be more independent.

Remember, you get what you expect. If you don't expect much, you won't get much. Expect them to shine and most of them will come up to your standard.

Answer 2

Pair Programming sounds like a great possibility here.

• Give four of them two of the simpler of these bugs, let them pair up and have each pair tackle one of them.
  • Phrase this request as, "Can you figure out what's causing this?". Don't get them to start thinking about how to fix it yet.
  • Once they do have some level of an explanation, then ask them how it might be fixed. This way they won't get as overwhelmed with a huge task all at once. Let them go and experiment with the code if they haven't already, and once they have a plan - even a vague one - you can guide them towards a good solution.
• The other one, you can pair with and start working on one of the harder ones with him. This may be more difficult given his inexperience with the code, but he'll also have the benefit of someone with experience going through it with him.
  • I think a new feature might be a good way to do this, given your experience. You can show him the existing API as the new feature gets developed.

For an anecdote/example of this suggestion working: This was how I was introduced to the hairiest part of the codebase I work on - with the other relatively new developer I was paired with, we ended up doing something like this:

• We were given a bug, and after about a 10 minute introduction, were told to try and figure out what was going on.
• About an hour in, we split up and dug into two different trains of thought.
• About two hours after that, I figured out in general how the code worked, but didn't know exactly where the bad output was being generated. He figured out how it was being generated, by digging into the raw and the denormalized data, but couldn't figure out the code.
• We paired back up and followed the code paths together, and got an exact answer. From this, we brainstormed with our manager some possible solutions, and ended up implementing it later on.

I've since inherited maintenance of that entire part of the codebase, since I'm really the only one who understands how it works anymore (the original developers who are still around don't even fully recall).

Answer 3

Teach them. Assign them tasks which they can easily solve.

Simply put, the issue is that the said workforce is not skilled enough to be very productive with the task they have. As such, you can either 1) ease the task 2) try to increase the skill of the workforce.

Similar problem almost always happens(to some extent) whenever a new person joins a team and starts working on a codebase he/she has no experience of. This becomes more of a problem if the tools and methodologies are unknown. By training the person to become more familiar with the tools and methodologies the problem can be easened faster.

However, solving such a problem takes time - one can't just expect others to know everything or learn everything in a single moment. Perhaps introducing some books about concurrency, software optimization and general methodologies needed would be a good start.

Answer 4

It sounds that you were not part of the hiring decision. Make a fair assessment to their abilities to handle current tasks. Write down a report with a recommendation (external training and such tasks as long as it does not affect your delivery time), send the report to your manager whom may start talking to whomever hired those guys. One new person may be absorbed in a team but 5 new people at once, does not sound good unless you have a relaxed shop. Whatever you do don't try to teach them on your project time unless this is accounted for in the plan.

Edit: It may be appropriate to mention Brook's Law in this situation.

Answer 5

Maybe you can spend some time creating a sandbox environment where you can throw them in to tackle some of the tough problems without doing harm. Have them test their solutions as thoroughly as they can. Put more than 1 on the same problem.

All of these things give them the possibility of getting skilled enough to be useful, plus they require less of your time. Of course if you have them (mostly) sink or swim and they pretty much sink then you have to rethink things.

In the programming profession people who can't learn mostly on their own probably aren't really worth the effort it would take to teach them. But I think they will probably mostly surprise you with how well they get on when you cut back on the help.