We are a team of 3 developers (2 experienced devs and a junior).

We just started a brand new project. We've designed the application, concentrated efforts on choosing the right architecture and now we are laying the first lines of code. We are writing the core of it, what will be the foundation of the entire application.

This ain't no easy application either. Hard performance requirements, massively distributed, complex entity model etc.

We are all out of our comfort zone, especially the junior. He doesn't have the experience to create a good design upfront. That's not a problem though because me and the other dev are there to help and we both believe in mentoring and in building teams, but... we don't know exactly what would be the best way to do it, so that he gets an enjoyable experience and learns the maximum amount of skills.

We both realized that we didn't have a junior on new projects, only on existing ones where it was easier on the junior because he had an entire code base from which to learn and inspire. But for this app we have almost no code. We just started.

We were thinking at a few approaches:

  • have him try on his own for a couple of days then intervene and refactor the code together with him, steer him in the right direction then repeat => Might not be a fun experience for him since we will be pointing out his mistakes on every refactor;
  • have him pair programming with one of us => he might become just a "bystander" and agree with everything we do, without actually learning a lot or digesting much of the information;
  • have us build the skeleton of each module, with a solid design and then giving the module to him to add the missing pieces => might not be fun to pick up after us and there is the risk that he only pays attention to filling the gaps and not to the entire design.

How can we involve him in the design so that he doesn't feel left somehow outside of it and so that he learns a lot from the experience and gaining enough confidence to try it on his own?

closed as primarily opinion-based by jwenting, user40980, gnat, GlenH7, ratchet freak Sep 9 '14 at 8:33

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 5
    My experience with (very) junior team members is that a couple of days between reviews is too long. They bang away with good intentions without finding a path forward. Short morning and afternoon sessions for the first month or so worked better. Once they'd found their feet -- and, more importantly, knew when to ask for help -- we reduced the frequency. – Michael Green Sep 7 '14 at 5:34
up vote 12 down vote accepted

I recommend the following guidelines:

  • Involve the junior developer in your design meetings and solicit his input. This will get him thinking about the big picture, even if he is not ready to do the high-level design himself.
  • Try to isolate and clearly define a module of the application to assign to the junior developer. Describe in writing what the inputs/outputs and other requirements of the module are. Avoid assigning him a module that cannot be easily tested or which can only be tested when integrated with other yet-to-be-written modules.
  • Perhaps the junior developer could help in ways other than coding the core application. For example, he could write test code. Far from being menial work, writing good test scripts makes a valuable contribution to the project and also gives the junior developer a solid understanding of the project.
  • 2
    Absolutely make sure they sit in on design. Then he will understand where his contribution fits in overall, and what value he's adding. He may drown in the complexity but at least he'll know which ocean he's in! – Michael Green Sep 7 '14 at 5:30

I think it depends on which area you want that junior developer to improve. When I was (very) junior they used to give me API's that I need to build one particular confined thing, such as:

  • this function gives N number of personnels from Personnel table
  • this function provides personnel statistics given the personnel's id

->

Task: build a page with a list of personnels that shows his/her statistics when a personnel record is clicked on. Here is a simple sample page built before in the project.

The most important aspect of the given task is being solvable just by that given resources and do not require any changes in them.

All 3 ways look good to me. Actually trying 10 different agile ways at the same time should give you good results soon, at least you'll know which way works and which one does not (which one will work best depends a lot on the personalities of the players).

The pair programming problem will not occur if you stick to the process with the typing/thinking hats switching every 10-minutes (or so), no exception, following the process originally described by Kent Beck (I don't remember where)

As for involving other people in the design - what we have found that helps is if during the design phase some design documents (with some UML models) are created. The other people (your junior) can then proof read them, review them, play devil's advocate. This role of an independent unspoiled 3rd party can be actually very beneficial, e.g. for exploratory testing - http://www.softwaretestinghelp.com/exploratory-testing-beyond-traditional-testing-boundaries

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