How to help a junior developer that refuses help?

Question

In my team, I am the person with the most experience. We lack a strict junior/medior/senior split so we are all equals. I have been involved with this project from the start and because of that I have an extra developer support role, which gives me the time and responsibility to help my team members.

I have one team member who is very inexperienced and an introvert. He never asks for help. Trivial stories take multiple sprints to finish. When I offer to pair up with him or help him in any form or shape, he assures me that he is almost finished and that he doesn't need help.

Then when the story does finally come up for review, there are usually multiple things that are not maintainable, overcomplicated or downright wrong. When I try to bring this up during code review, he gets offended very easily by my comments.

He strongly believes that code that works is good enough and views me as dogmatic for insisting on maintainability. I argued that unmaintainable code often contains more bugs, even intentionally relaxing the code review on a couple of stories to prove my point. Nonetheless, he still views me as a nuisance.

How do I best approach educating this team member? How do I reach him? I would really like to help him but it feels impossible.

Answer 1

Your company is committing a mistake by treating all developers as equals. All developers are most definitely not equal.

As a junior, they haven't proven themselves. They may never become a great programmer. Junior programmers need guidance, or they need sufficient space and time to mess up until they gain experience. Both, probably.

Given that guidance is faster, here are my suggestions:

• Have the boss make the pair programming a requirement for this developer. Either for the next task, or couple of tasks, or until further notice. Switch out partners or not.

• Make it clear that criticism of work is not personal. Learned this on my first job. While it's certainly not a universal attitude, it's immensely helpful when you can criticize work without criticizing the person who did it.

• Explain to them that they don't know what they don't know. Also known as the Dunning-Kruger effect. True wisdom is in knowing that you know nothing.

If none of that helps, even after months, it may be that they are not suited to the environment or the career. At which point you fire them.

Answer 2

This situation sounds as though it's gone way beyond helping your colleague into a disciplinary matter. The big red flags are consistent patterns of:

• Dishonesty - saying something is nearly done when it patently obviously isn't.
• Incompetence - when his code turns out to be repeatedly problematic at review time, and not improving, plus
• Denial - if he acts as though a bad code review is a personal affront not an opportunity to learn

One major point of frequent code reviews and sprint retrospectives is to nip this sort of issue in the bud, and a good Scrum Master or similar role with a bit of authority in the team should spot these issues appearing and raise them at higher levels. If you really are "all equals" in the eyes of the organisation - in that a raw junior has the same degree of autonomy as the most experienced - and your management aren't willing or able to get usefully involved, then you're going to find it difficult to change the situation. Rotating the pairs may help, if only to establish in the rest of the team's minds that the guy is a problem.

Answer 3

IMHO let your boss force him to pair up with you.

Let me share my experience as I was like him a few years ago and I also had a senior developer who was a "nuisance" to me.

I was forced to pair up with him for a realy complex project I didn't achieve to finish up. The outcome after some beginning problems is that I did now don't think he is nuiance but a friend and mentor.

I learned more in this 4 month pair programming than in 5 years of software development school and 2 years of lone developing. I think now about this time as the most important phase of my working life.

So please force him for his own good.

Answer 4

This is a very general purpose answer, but I believe it is applicable.

Do not try to change him. Changing people is a very ugly process. It is much easier to make an environment which encourages himself to change.

I have had experience with such developers (disclaimer: I was one of such developers, and I leave it to my coworkers to decide whether or not I still am one of such developers). One of the hardest lessons I have had to learn is that not everybody views code the same way. A product which is "good enough" to a developer may actually be good enough to them because they're used to a workflow which makes it easy to throw away pieces they don't need. It's not until that developer realizes that their code must be maintained by others, who desire a different quality of code.

I still have spats with people who believe copy/pasting code 20-30 times is "good practice" rather than refactoring it to avoid duplication. I have spats with them because they're not entirely wrong. There are environments where copy/paste is actually the most maintainable solution (I just have the belief that my team is currently not operating in one of those environments).

I would say the solution is two fold:

• Explain to the young developer that this is a team effort, and the end product is not just his piece of the puzzle, but the entire completed puzzle. The phrase "we are all equals" is incorrect. The lack of senior/medior/junior does not mean everyone is equals as in "everyone's opinions are equally valid," it means there is no artificial business construct forcing inequality like "I've been here 5 years, so I know more than you." In the end, the team has to agree upon the best way to ensure the team's best performance. The team should divide work with that in mind. Your past performance will affect how the team values your opinion. If not, it is a defunct team. (Hopefully past performance will not dictate the teams' predictions of future performance, but it would be foolish not to account for the past as well.)
• Offer options. People who are trying to change the world love options. Let them know they are welcome to continue developing in ways that conflict with team norms. The team will work with them. However, they should know that the easiest way for the team to work with them is to only hand them less valuable and less interesting tasks, because the team needs a cohesive product at the end, and the team does not believe giving them valuable tasks will result in a cohesive product. Consider making smaller stories whose purpose is to be given to those who are not acting within team norms. On the other hand, if they are interested in doing valuable tasks, the team will work with them as well. However, they may have to submit to things like peer programming if they want to work tasks which the team considers above and beyond their demonstrated ability to produce long term value. Let them decide their future, don't force it. Eventually business logic will need to cut costs, and a developer doing less valuable tasks will be first on the chopping block. Until that point happens, try to give them opportunities.
• This is kind of tongue in cheek, but tell them to go read the source code to GCC. GCC developers generally recognize that the lack of coherence in the approaches of the developers over 20+ years has gotten GCC to the point where maintaining it is a major chore. It's getting harder and harder to make meaningful improvements to the code base. If your company happens to have a legacy product which is in bad shape, you could rotate this developer to that product for the same effect (but clearly your perfect company has no product fitting this requirement ;-) ). Once they've seen how it feels to use someone else's bad code, they may be more ready to admit their process has its flaws.

Answer 5

You need to get the entire team to help each other to improve. Not only will this make work more interesting, it will also mean that inexperienced coworkers get frequent feedback from several sources. Feedback from one person is much easier to dismiss than feedback from many.

This is a management issue and as such should be raised with management. It's a standard issue with standard answers. If management is not aware of that, your real problem is not that you need to educate the coworker, but that you need to educate the managers. That one is harder.

You mention "story" and "sprints" so I assume that means you work in an Agile environment. You also mention that stories take multiple sprints (as in "more than 2"), so I have to assume the company doesn't have an efficient Agile environment yet, and is open to improvement.

The standard approaches to solve your problem in the context of an Agile framework, as I know them, are as follows:

Frequent peer reviews

• Enforce frequent check-ins. Code that compiles and runs should be checked-in several times per day, and be built by the build system and run against all automated tests. Yes, the build will break a few times each week, but it should be fixed within 5 minutes each time.
• Enforce peer reviews on all check-ins.

Once this is agreed on by a management committee such as the Scrum of Scrum (or the equivalent in your company) this can be enforced with a script that requires check-in descriptions to state the name of the reviewer. Such a script can be written in less than 30 minutes.

Collaborate on stories

• During sprint planning break down stories into tasks, as a team. Aim to have tasks that shouldn't take longer than half a day. If you aim for all of the tasks to take more or less the same amount of time you can keep the sprint planning meeting quite short because there's no need to put estimates on the tasks.
• During a sprint, have as many people as possible work on one story at the same time. Finish stories as a team, one story after the other. This can involve agreeing on pair programming as a team.

Raise and fix roadblocks

Use the daily stand up meeting. It is visible when someone gets stuck, often before they themselves realize it. If someone picks the same task 2 days in a row, raise a red flag. The tasks were supposed to take about half a day. There is a reason which causes the task to take more time, and it's not procrastination. If the task is more complex than anticipated, split the task into 2 tasks. If the task requires more expertise the one working on the task should pair up with someone who has the expertise. If the task is blocked put the task back on the board.

Enforce Pair programming

This is one of the standard solutions, but I don't like that one, at least not as a permanent solution. People should pair program because they want to, not because they are told to. Therefore I'll add some more opinion here: If pair programming is enforced then it should be done with the purpose to train the developers on the concept. To do that, it should come with a time limit, 1 or 2 sprints. For example one could say "Many of our developers don't have much experience with pair programming, and we want to change that. To do so, pair programming will be mandated for all work for 2 sprints, starting with the sprint after next. After that it will be your choice if you want to pair program."

Answer 6

Make it clear to him that writing software is a collaborative effort. He needs to work with the other members of the team to create good software.

Try to get him to understand that constructive criticism is a good thing. Try to make sure that you're not directly criticising him, you're providing him with constructive feedback to for his professional development.

And I'm sorry, but code that works is not "good enough". Code has to be documented and maintainable by the next guy. Bear in mind that even with your own work you might very well be the "next guy". You're not going to remember the code you wrote 6 months ago, so when it comes to maintenance or changes a good coding style and documentation saves more time than it costs. At the moment, it sounds like he's only doing half his job.

Answer 7

There are plenty of ways to answer this question, but before we start, the first issue to address is - Is it your problem to solve? Are you expected to mentor less experienced developers? are you expected to cross train your team mates into technology that they are not as familiar with? Do other team members allow you to perform these roles without issue?

Hopefully the answer to the above question is yes. If the answer is no, then you need to talk to the person who's problem it is. (your boss?)

The first step is to figure out what are acceptable end solutions.

This might seem obvious, but there are different outcomes that may alleviate your pain. The best outcome may be that he becomes a social and productive member of the team, contributing efficiently and effectively to project delivery, but that may not be credible. Other good outcomes could be that he is moved onto a different project, where he is more competent to deliver, and able to work in a team of one. It may be he is completely incapable of thinking like a programmer and is better suited to support. There are plenty of other solutions out there if you think creatively.

Personally, I'd invest in a beer for the guy. Chat to them out of the office in a relaxed way. As part of the conversation I'd ask them about how they think work is going? ask them what they would like to be doing in a few years time, and let them know that you want them to succeed, and will help them, if they want with the challenges they are facing. Remind them you were inexperienced once, and got to your level by asking for help and learning from more experienced programmers too.

There are techniques that may help this person understand what they need to do. No doubt almost all the answers here will mention pair programming, but there are also other ways too, that can help with the more autistic developers. for example, you write the unit tests, he writes the code often helps with gaining confidence and focusing the developer on the task at hand, whilst keeping some independence in his work space.

If you manage to gain their cooperation, It may also help at the planning stage to have the developer propose their design, and provide a time estimate for each of the tasks. Allow them 2x their time estimate for any task without issue, but when a task has already taken 3x or 4x the estimate, that's the point to interrupt and insist on an update of the task status.

At the end of the day, if they are refusing to accept any assistance, are continuously making project delivery unpredictable, are producing more bugs than features, then the future of this project is at risk with their continued participation on it.