How best to involve junior developer in designing an application from scratch? [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 6 years ago.

Improve this question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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