I'm leading a team of programmers and I have had a number of interns/junior programmers who came into the team in the past decade. Some of them have done well and have continued onwards to become accomplished, senior programmers. However, there is a subset of people that have a lot of enthusiasm and have the right attitude, but even after intensive coaching sessions I am unable to get them up to the right level. Curiously, I find that their programming skills are okay (not great, but in general this is not the main problem). The main issue is that they lack more "administrative" skills around the job. Chiefly, they are unable to be meticulous in their work. They lack skills to read instructions, documentation, emails or other material with the level of attention and thoroughness that is required.

What this ultimately means is that instructions often have to be repeated. The same mistakes are frequently made. When documentation is being read, half of this is "absorbed" and the other half is glanced over and ignored. When something isn't understood it is not interrogated. We have had lengthy discussions of what is unclear or where people are stuck, and 90% of the time it boils down to not having properly understood something or picked up on something important.

I've tried checklists, documenting procedures, and being thorough in the instructions. However, I can't foresee everything and I need a certain level of critical reading and reflection skills - and those are simply not present. But these are some great people that I feel have potential. I know I can't offer them the upskilling and guidance that they need - I am merely there to help their programming skills but this goes further than that. However, when they leave I want to give them pointers as to what they can work on going forward, before going back into a similar programming role. I must note that I operate in a country with a poor education system and I feel several of these issues relate back to an education system where reading, reflection, and critical thinking are not well developed.

What kind of resources should I point these people to? Are there (hopefully online and free) courses that address these kinds of issues? What would they be called? Any other tips?

  • Does you team perform formal code reviews of each changeset prior to or as part of the development process? Apr 20, 2020 at 15:51
  • Yes we do. Do note that in this case I'm wondering what resources to point people to after they have already left the team.
    – user117671
    Apr 20, 2020 at 15:58
  • I also see the question is downvoted - how do I see the reason?
    – user117671
    Apr 20, 2020 at 15:58
  • @user74934 reasons aren't given for downvotes. There is a close vote for the question lacking in focus. Apr 20, 2020 at 16:44
  • I have a daughter who is dyslexic, and what you are saying sounds an awful lot like those symptoms
    – WendyG
    Apr 21, 2020 at 14:53

3 Answers 3


I'm going to use the term "detail-oriented" to describe a person who is "meticulous and thorough" in how they approach a task. I'm going to use the term "intellectually curious" to describe someone who "interrogates" a document when something isn't understood, someone who creates little experiments to figure things out, etc.. I use two terms as I think they represent two different traits. I think both are required to be really successful as a software engineer.

I think intellectual curiosity is something innate to a person - they are born that way or not. I don't know if that can be taught, especially to an adult. As a manager, I'm careful to not assign tasks which I think will require much intellectual curiosity to those incapable of it, and I try hard to test for it in my interview and selection process.

Detail orientation is a different, I think, in that it can be learned, at least to some degree, as an adult. While I'm not sure if there is a specific course to teach it, as a manager, I develop it in my staff by requiring that they take a detail oriented approach to problem solving.

For example, I require (and review) a "plan of attack" which describes the various steps required to accomplish the task, and the criteria for determining when it is finished. For another example, I'll require them to write out the "test cases" for the software, before they complete (or even start, sometimes) development. In all cases, I will interrogate them and their plan to make sure they've captured all the details, and will send it back for a re-do if it is lacking.

I've definitely noticed that after doing this for a few projects, my developers start doing a much better job capturing the details of a task at the onset - which results in better software and much more accurate estimates of the time a task will require.


It sounds like you may be pointing the developers at a whole bunch of documents, then effectively expecting the developers to read and memorise the whole lot. But that isn't happening, and it's not going to happen.

You need to set up traceability. If module X is required to meet requirements 5, 6 and 7, then you need a traceability matrix that says so. You need a test matrix that shows that the tests for module X are demonstrating compliance with those requirements.

Anything that is part of the documentation set must actually be part of the documentation set. Asking someone why their work doesn't comply with an email you sent out three months ago is futile. If it matters, it should be added to the statement of work.

The "definition of done" for a module will involve showing how it meets the specifications/requirements.

  • Thanks but I'm trying to find if there is a kind of discipline or industry that teaches people to read and absorb information, rather than trying to solve this in-house. I've spent many months and sometimes years with the same people and have found I can't teach a certain part of the job that is not related to programming. I'm trying to find out where those kinds of skills may be taught or obtained.
    – user117671
    Apr 21, 2020 at 5:15
  • 1
    @user74934 Perhaps after several years of trying, you need to accept that it's not going to happen, and change the way you work instead.
    – Simon B
    Apr 21, 2020 at 7:44

I think your questions could be rephrase as:

  • How to improve soft skills of developers
  • How to encourage developers to develop new skills to help them grow in their career

The first thing you need to understand is that you can't force them. The more you force, the harder they'll push back.

The second thing is understand the goal of the individuals in your team. Some may want to do as little code as possible, other as much as possible and as few process as possible. Some won't even know what they want. But here is only one side, other sides are salary, workload, meaning of tasks, interactions with people, carrer growth... If you understand what your developer want you may find that some don't want the seniority and what it entails, other want it but may have not yet understood what is required to achieve it.

Once you know what each person wants you can guide them on the track to better themselves by providing advice on how to achieve their goal.

  • Thanks. The people this concerns are themselves interested in improving their soft skills - it's not a matter of them not wanting this. But please note that I am not looking to solve this problem within our team. These people lack skills that are beyond my and our company's scope and I rather want them to 'go back and study', so to speak, but I don't know what kind of resources or support to point them to.
    – user117671
    Apr 21, 2020 at 5:13
  • @user74934 Damn I lost a long edit to answer your comment. I'll do it short here: you need mentoring. Have the senior devs teach their skills, how they work and why they do it like this or did it and don't need to anymore (but because they did it in the past, like reading documentation)
    – JayZ
    Apr 21, 2020 at 8:22

You must log in to answer this question.