I work as the lead dev on a small team. I manage 3-4 devs.

I don't have any issues with this particular dev apart from that given their level they should be completing tasks faster. This isn't just my interpretation; another senior member of the team feels the same way.

This dev is normally dilligent and commited to what we do. They are a good employee but if I am being honest I don't think they're a natural developer. That doesn't mean they're terrible at what they do.

There's a number of things that can slow down a dev:

  • the task is naturally complex
  • distracted by other tasks
  • getting stuck and not knowing how to proceed
    • ...and not looking in the right places for answers
  • life gets in the way; personal issues, feeling demotivated, etc
  • slacking

I know that the last option doesn't apply here. Like I said, they are commited.

For context, this issue is most obvious when they're having to do a task they've done many times before (i.e. tackling a similar bug/feature). It looks like they just aren't learning from these experiences? They seem to get stuck and not be able to take a step back and view the problem from another angle. They do ask for help eventually.

My intention is to speak to them but I wanted to make sure I have constructive feedback, not just "work faster please". I also don't want to instill in them anxiety or pressure about how long they take as that might make things worse.

  • 6
    Just to be clear on your question @Turnip , what do you mean by saying you don't think he's a natural developer? Commented Oct 20, 2022 at 16:06
  • 3
    Decades of research seems to show that there is no significant measure by which anyone is innately better at programming than anyone else. If there was a discernible category of "natural developers" then university admissions departments and graduate recruiters would love to find it. We do know that a lot of people who try to become programmers don't succeed, but we haven't found anything innate that would distinguish them from the ones who do succeed.
    – kaya3
    Commented Oct 20, 2022 at 21:42
  • 25
    I think you are missing something from your list of things that can slow down a dev: fear of not doing it (exactly) right. In my experience this is very common, and can afflict even excellent developers. Could that be the case here?
    – John Wu
    Commented Oct 20, 2022 at 22:07
  • 16
    @kaya3: We might have not found the underlying reason for this yet, but the fact that becoming a productive developer is amazingly easy for some people and terribly hard and/or impossible for others is obvious to anyone who has worked in that industry. In colloquial speech, being a "natural developer" means just that, it does not imply any particular biological cause.
    – Heinzi
    Commented Oct 21, 2022 at 5:58
  • 2
    @kaya3 it has kept some researchers well paid for decades so it's a sucessful study. In reality people are more suited for dev work for the same simple reasons they're suited to most things.
    – Kilisi
    Commented Oct 21, 2022 at 6:43

14 Answers 14


I think you hit the nail on the head with this part of your post:

It looks like they just aren't learning from these experiences?

See if you can determine why. While everyone is different, I have found that WRITING DOWN (yes, I know that's old-fashioned but it's worked for 1000s of years) things really helps with recalling and even if it doesn't, the notebook serves are a reference for issues when they come up again.

The key, in my mind, is to enhance their learning so that they are able to work more efficiently in the future.

Another technique that I've found helpful when working with junior developers is to help lead them through problem solving. They do the work and you resist the urge to jump in and do it for them. You're just there to facilitate and advise.

  • 2
    I like this, it would be awesome if more senior engineers jumped in on guidance and observed how junior devs problem solved and helped to correct things early on constructively. Unfortunately, it seems like that kind of culture is very company/team dependent. Commented Oct 20, 2022 at 16:05
  • 4
    I think this is a side-effect of the way students are taught in universities these days. My college years were spent learning how to learn things. I didn't realize it at the time but it's very clear now especially after working with others who were simply taught things. They know what they know and really struggle with learning new things. In any technology field this is a big problem. So the onus is now on employers to see to it that juniors learn how to learn or they will end up with a relatively useless employee.
    – jwh20
    Commented Oct 20, 2022 at 20:05
  • 3
    That's a good point, learning how to learn - and even how to problem solve - is a super valuable skill Commented Oct 20, 2022 at 20:08
  • 12
    Writing stuff down is what kept me productive when I was pregnant and post-partum and had really bad "brain fog". My mind felt like a sieve. I like this answer because it doesn't assume the reason for the brain for, rather just a general solution.
    – stanri
    Commented Oct 21, 2022 at 6:40
  • 2
    Writing things down has been working so well for me that the technical notes repo I've been keeping since 2017 is now at 250k words. But these notes can go anywhere; for notes on how a program works, I'd keep them header comments in the code or Markdown files right beside the code. Reviewing these together can make sure that individuals and the team understand what they're doing and share that understanding. Remind everyone that the result often isn't always used later, but the process of writing and editing such documentation is usually what produces the most benefit.
    – cjs
    Commented Oct 21, 2022 at 7:59

If you've established that they're objectively slow, the next step is to work out what it is that they're slow at.

Reading and understanding tickets? Finding the relevant bits of code that need changing? Understanding the current code? Working out how to solve the problem? Actually writing code? Writing unit tests? Testing that their fix works properly? Documenting their changes? Sending their code for review? Something else?

This means sitting down and talking with them, and seeing how they approach and an task and where they're struggling. Once you've found out which area(s) they're slow in, you can then look at how to address that. But until you understand that, you're just guessing.

If an application is "slow" then the first thing that you need to do is some proper troubleshooting and profiling to determine where the problem actually is - and this is no different.

  • The term for the analogous thing on an application would be profiling - seeing which parts take which relative or absolute amount of time when done as part of the whole task, not micro-benchmarked in isolation. Difference between Benchmarking and Profiling Commented Oct 23, 2022 at 9:54
  • 1
    @PeterCordes Thanks, that's the word I was looking for. I knew that benchmarking wasn't quite right, I just couldn't think of what the correct term was.
    – Gh0stFish
    Commented Oct 24, 2022 at 10:01

I don't have much to add to the other answers regarding what kinds of intervention might be helpful, but I want to address this part of your question:

My intention is to speak to them but I wanted to make sure I have constructive feedback, not just "work faster please". I also don't want to instill in them anxiety or pressure about how long they take as that might make things worse.

My advice would be to frame this as a matter of professional development (that is, "development" in the sense of improving one's skills, not software development). If the speed at which they're working is not actually causing problems for the company then there is no need to think of this as an intervention to fix a problem; rather, it's about recognising potential and trying to find opportunities to achieve it. And improving this employee's skills will be beneficial for their career, not only the company.

So this can be good for them, too, and if they can see that then this will be a cooperative endeavour, rather than an intervention imposed on them from above. Meanwhile, there might also be worthwhile professional development opportunities for your other devs, in which case you wouldn't even have to obviously be singling this particular dev out.

  • This is a matter of professional development. No question about it. The reasons for slowness can be many, but ultimately slowness absent improved quality/accuracy or completeness = lower productivity. Commented Oct 21, 2022 at 13:34

I believe the first task before a discussion is to come up with a list of possible impediments that is broader than what you've described. In my experience some (junior) programmers don't realize that they are perceived as slow so the coaching is important.

Here are some causes of "slowness" to complete work I've seen in my coaching:

  1. Analysis Paralysis - too many ways to do things, unclear/uncertain about the best (or better) course of action- and unclear direction.
  2. Shiny object distraction. In the course of working new concepts, ideas, are encountered and results in too frequent shifting focus, attention or approach.
  3. Failure to understand the objective(s) - either because they are vague, or not specified. Implied, unstated objectives are very difficult to meet.
  4. Unfamiliarity with tools, approaches, languages or responsibilities in the organization.
  5. Failure to avail themselves of the best tools and knowledge (e.g. not able to do a good search for options, or to understand the results they do find).
  6. Inability to discern between MUSTs and SHOULDs. That is trying to solve problems that do not require solving. This is really item 3 in a different form.
  7. Unusually difficult problem domain. Some problems are Easy only if you've seen or tackled them before.
  8. Perception that asking for help, or asking for too much help is a negative. Sometimes teams inadvertently reinforce this belief by their behavior.
  9. Inter-personal issues / team dynamics / perceived inavailability of mentors co-workers.
  10. Personal distractions.
  11. Disinterest. Some problems are just not interesting and cause procrastination unless personal discipline is applied.
  12. Intense pressure to complete something "perfectly" sometimes robs people of motivation.
  13. No "definition of done" together with unstated expectations that may result in too little (incomplete) or too much work (overkill).
  14. Being asked to do maintenance on poorly written code. This can be very daunting. It may be necessary, but often requires a lot of learning, trying.
  15. Lackluster approach to debugging and problem solving (and/or a non-existent debugging philosophy and tools)

So given those (and many other possibilities), I would recommend first coming up with observations about the programmer that may apply. Then you can ask questions to illuminate. E.g. "Do you enjoy the work you are doing?", "What do you least enjoy about your work?" Are team members helpful when you ask? How aggressive are the project deadlines? What is the most useful thing you've learned while working here? Are you finding the resources you need to be able to get the work done? Are you clear about what your current project is? How do you known when you are done? What about your last project - how satisfying was that? Is there anything I can do to help you be more effective?

For example in my recent coaching, I realized that one of our programmers lacks fundamental understanding of the language being used and was struggling to understand the error messages being emitted. In another case a programmer was looking up error messages on the internet and "blindly" trying the suggestions without paying attention to the context of the answers.

  • 1
    This is an underrated answer. You do have to dig through these to find any semblance of an actionable cause. Though, at the core, if this is someone with more than 3 years of experience (especially if out of a Comp Sci degree), there is probably very little to be done if it's objectively not a motivation issue.
    – VSO
    Commented Oct 22, 2022 at 3:08

Rather than attempting to give feedback away from their programming process (such as in a meeting or an e-mail) from what is apparently a position where you don't know the details of the problem, you should sit down and pair program with this developer for a few hours, or have another senior developer do this. The more senior developer should let the junior programmer take the lead and at first simply follow along without commenting too much. Once you start to see where the issues are and what's slowing the developer down you can both offer advice to that developer and consider building processes and tools that will help in areas that slow down not only this developer but perhaps other ones, too.

As a more general thing, having developers pair up on a regular basis will help a lot with getting developers on the same page and spreading good techniques throughout your development team. (If you've not done much pair-programming before, it may be a good idea to try it out first with someone with whom you're more co-equal. But honestly, I can as easily think of ways this could be worse, rather than better.)

One commenter has suggested that it's possible this technique may may lead to the junior developer being disabled by crippling anxiety. I'm going to suggest that this is less likely than with other feedback techniques for several reasons. When you are providing small items of feedback such as "what do you think of doing X instead of Y right here" instead of "everything you do is too slow" you're both pointing out much smaller problems of nowhere near you-could-be-fired size and you're helping the junior developer to reach a solution, rather than just leaving him with the stress of figuring it out himself. You can also provide counter-intuitive advice that he would be unlikely to follow himself without your direction: if he habitually keeps doing something really inefficient in the editor, he may need to slow down in order to break the habit and speed up, which is not something he may come up with himself if he's received only advice that he's "too slow."

  • 3
    I was going to say exactly this. One little tidbit I might add is to do the pairing with another developer first, both so that you have a baseline to compare and so it doesn't make them nervous you are there to fire them. Commented Oct 21, 2022 at 10:44
  • It's an interesting suggestion and worth a shot. If I had to hazard a guess though, this could end up backfiring. Why? Because in my experience, pair programming works better with programmers who have a structured flow, who can take suggestions and adapt to them, or can voice aloud their thought process. Someone that approaches tasks in an unstructured way, basically fumbling about, even on repeated tasks, is likely to be very unproductive once someone is watching them. And that's apparently what we have here. Commented Oct 22, 2022 at 22:03
  • @Chan-HoSuh Backfiring? Do you think someone is more likely to learn how to fumble less if you just leave them alone than if you pair program with them?
    – cjs
    Commented Oct 23, 2022 at 4:24
  • @cjs Hard to say. People have different psychological makeups. As an extreme example, some find the experience of having a superior "correcting" their work live a traumatic one. I'm not sure in that case they would be learning anything. Psychological studies show such a stressful scenario can, for instance, reduce cognitive flexibility and reinforce habitual patterns. Commented Oct 23, 2022 at 22:48
  • 1
    @Chan-HoSuh Thanks for your comments. On further reflection I think that this technique is less likely than the alternatives to lead to the sort of backfiring you're talking about; I've edited the post to explain why.
    – cjs
    Commented Oct 24, 2022 at 7:11

I am surprised that no one else has brought this up. My two cents is 'familiarity with the tool set'.

Anyone can fumble with a table knife to tighten or loosen a slotted screw, but a slotted screwdriver is "designed for the task". Maybe your developer has access to the same toolset as everyone else, but is not familiar with ways to use the tools to get through tasks more efficiently. For example:

  • Using a SQL Trace tool to examine which query is not producing a correct output, instead of repeatedly stepping through client code
  • Using a browser's console log to debug Javascript, again instead of repeatedly stepping through code. Also, the debugger() function to set breakpoints
  • Using an IDE instead of a plain-text editor
  • Making the best use of debugging, formatting, refactoring features of the IDE instead of doing things the hard way
  • DRY (Don't repeat yourself)
  • Making good use of object oriented development principles and SOLID. I've found that a surprising number of developers don't put good principles into practice, and it makes writing code and maintaining code much harder.
  • Using Entity Relationship Diagrams to understand relationships. In a complex scenario, visual representations are great tools to assist a learning curve.
  • Using CSS instead of inline styles

There are many more ways I can think of to optimize the work. Some of you might think these things should be quite obvious, but I really don't think these are concepts that are taught in classroom environments. Some developers are of the mindset that if they aren't taught to use a tool in a certain way, then they just don't.

You might bring up some of these topics in a Lunch-and-Learn session for the team, and avoid singling anyone out individually. Ultimately, sharing these kinds of things is good for the entire team. Come up with topics, and delegate the presentation so everyone gets a chance to learn and share. What do you have to lose, and what do you have to gain?

Best of luck.


Have you considered that they could be slow on tasks they've done before because they think they're going to be easy so they put them off?

If I have a large unique task that I know will take a full week's worth of development, I work hard every day to finish it. If I have a task that I know will take 5 minutes, I put it off over and over because I know I can finish it quickly so I don't need to work on it yet.

Consequently, a 5 minute task and a week long task might get finished at the same time, because I've put off the 5 minute task while working on the week long task.

If this is the case, you could have the first day or two of the sprint be the days that they're expected to work on easy tasks and get them finished. Then, the later parts of the sprint should be dedicated to the harder tasks that will take longer.

If I've misdiagnosed the problem, you can ignore this, but I wanted to throw this perspective out there.


You can establish standard practices from Scrum in your team which would mitigate or prevent issues you've described:

  • Use backlog for tasks. Break down complex tasks into smaller pieces
  • Limit work in progress to avoid distraction - single piece flow tend to be faster and don't need context switching
  • Organize planning before each development iteration to discuss how long would it take or what's the best way to solve existing problems in a backlog
  • Short daily meetings to talk about what's done, goals or impediments
  • Have recurring retrospective meetings where the team could discuss what went well and what could be improved. In this way, you could step back and propose more conceptual solutions to repeating problems.

Or try pair programming:

the courtesy of rejecting phone calls or other distractions while working together, taking fewer breaks at agreed-upon intervals, or shared breaks to return phone calls (but returning to work quickly since someone is waiting). One member of the team might have more focus and help drive or awaken the other if they lose focus, and that role might periodically change. One member might have knowledge of a topic or technique which the other does not, which might eliminate delays to find or test a solution, or allow for a better solution, thus effectively expanding the skill set, knowledge, and experience of a programmer as compared to working alone. Each of these intangible benefits, and many more, may be challenging to accurately measure, but can contribute to more efficient working hours.


These are my "facts".

A) We all work at our own pace, this isn't inherently or necessarily "improvable".

B) Slow is sometimes synonymous with low quality, ie we can do less in a shorter time frame.

C) There are no accurate benchmarks to measure the correct time to spend on a task.

My suggestion would be,

  1. If it's not acute, leave it.
  2. If it is acute, switch the talk from time to quality. Ask them to deliver the best thing they can in a set time frame, ie one week.

Give relevant feedback on quality issues, only if you feel that a software engineer with the same experience level would have easily done better. Things like no tests, poor encapsulation, etc. Given the limited time frame, Missing requirements aren't relevant, only grossly incorrect ones.

If there is a comment from you about encapsulation more than exactly twice, it's time for HR to get involved. Say so the second time: "We talked about encapsulation, this is a basic requirement from your code. Please make sure we don't have this discussion again, otherwise we will need to consider if you fit this position. "

  • 1
    Slowness (all other things being equal) IS a measure of productivity. No one wants to pay a painter who takes 10 days to do what another painter does equally well in 4 hours (unless paying by the job, but even then there is the wait time). No one wants to wait 4 hours for a chef to prepare his meal when it is expected to happen in 20 minutes or less. The same is true of "slow" programmers. Unless the slowness results in better quality (accuracy, completeness), it is a net negative. Commented Oct 21, 2022 at 13:30
  • @SteventheEasilyAmused, developers are not house painters. Consider, Michelangelo was paid as an artistic designer, not as a painter - they wouldn't have paid a brass tack for his work (or even let him near the ceiling) if he was painting solid colours with a roller, no matter how quickly he could cover an area. So too with developers, slowness is not intrinsically a measure of the productivity of the things they are actually paid for, which is quality of design conceived, not volume of code typed out.
    – Steve
    Commented Oct 21, 2022 at 14:11
  • @Steve that you used the word "slowness" is the point. I wrote "slowness - (all other things being equal) is a measure of productivity. I recognize that programming is a creative process, so that part of your analogy is accurate, but a lot of programming is like "painting houses" - there is a clear objective, the means to accomplish it are well understood, and its a matter of getting it done. In that world, the quickest to do a good job is the most productive. Commented Oct 21, 2022 at 14:23
  • @SteventheEasilyAmused I don't disagree, my suggestion was to help making the conversation simpler. "Go faster" is not constructive. "I expect the deliverable to contain proper comments and input validation" is.
    – NiRR
    Commented Oct 21, 2022 at 19:40
  • Developers are probably more like house painters than Michelangelo, who actually meticulously scheduled and planned multi-year projects, carefully budgeting to not waste time or money. Commented Oct 22, 2022 at 22:19

It makes sense to do some preparations, so good that you ask around before going to talk to them.

Try to be specific (first to yourself) on WHY the lower speed is a problem. Make it as factual as possible. If you can explain that in nice words, you can ask your dev for a quick chat and explain that you see it as a problem and investigate if the dev acknowledges this. If they don't, all the effort you will put into it will probably be met with resistance in some sort of way.

If they acknowlegde the problem, it is now a shared problem which you can try to figure out together.

Don't immediately come up with solutions of your own, first start exploring if the dev sees areas that might be problematic and can be improved upon. If so, offer help if posssible.


As software developers, we need to know a lot of things. A lot more than most (albeit not all) professions. This knowledge is also spread over a plethora of different areas, infrastructure, algorithms, languages, etc. Which really doesn't make it conducive to storing everything in your brain all at once. Even the best devs find this hard.

I'm a large proponent of developing a "second brain" that stores all of this information in a well-organised way so that we can nip in, find what we need and get back to the task at hand when we encounter something we've seen before.

Personally, I recommend using Obsidian for this. It lets you build a knowledge base for yourself using markdown. One of the best features is that it lets you graph relationships between different motes of knowledge which helps when you're trying to recall how various different things fit together.

In the case of your developer, he could create a new note every time he encountered something he didn't know how to solve, and then update it with the solution after receiving help. This would then be linked with the project, technology, etc. Then, when he encountered the problem again, he could check his Obsidian Vault, search for the things related to x bug and he'll come across this document and know what to do.

The key thing to note though, is that for this to work it requires diligence and the pay-off is in the long-term as the knowledge base grows, it's not a short-term fix.


I'm afraid I lean heavily towards those other answers which question whether there is even a problem here.

If you accept that they are already giving a full effort - which is the real judgment that a manager is expected to make - then what else is there to change or optimise?

There will inevitably be individual variation between developers, so it is silly to assume there must be a problem just because others could work quicker. There will almost always be someone on a team who comparatively performs worst, because those determined to establish a ranking will find increasingly minor or subjective things to distinguish each member.

You also don't quantify the difference between the speed you would expect and the speed achieved. One developer taking twice as long as another, for example, would seem well within the realm of "variations in ability", that cannot necessarily be changed by any advice or alternate methods. Be careful to ensure that you are holding people only to sufficient standards, not trying to hold everyone to the maximum standard that any one individual does achieve.

My recommendation would be to keep an eye on the situation, but do not raise a problem unless you have made a specific diagnosis and have a feasible remedy.

Telling him to ask for help sooner may not be a real remedy, because it may erode the productivity of others called to help more frequently (if he could have got to the end on his own in a reasonable time), and it may erode his own productivity sooner or later if it undermines the time he has to spend on properly getting to grips in his own mind with certain difficulties.


I think the best thing you can do is to model the correct behaviors yourself and give the team opportunities to share knowledge without the constant pressure of "getting-it-done" asap.

Many folks do better when they can see how others approach problems. By "approach", I mean in a general sense. What's the workflow? Where are the information sources? What are the relationships across the org that help others? If the team is working as isolated individuals, each person has to discover on their own what they need to proceed. That can take A LOT of time.

This can be compounded when you're dealing with senior level people, who as you mention yourself, are held to higher expectations. These folks will feel shame in asking for help. They're battling internally with pressing on with digging a trench with a teaspoon or bothering someone else and risking being judged as a "help vampire". Sometimes it's better to reach out proactively or at least foster an environment where people feel safe to get help and ask questions-- is your environment like that?


One important piece of information missing in your question is: Is it same software in which they solved similar bug / added similar feature earlier?

You know softwares grow in complexity over time. More and more features added and there comes a time when it becomes immensely difficult to add another feature. There are just too many ropes to look at to stop oneself from getting tangled and the application to go haywire.

Another thing is, why would you think it would take significantly smaller time to do same software change?

Yes, some time would be saved because the research/learning is already done but depending on complexity of algorithm and one's luck in quickly finding a solution it can be a small amount of time. The algorithm still has to be implemented and its may be this part thats taking the bulk of time. There is no way to reduce this. You see while the solution is now well known and learned there are other things unique to this software that must be look out for that were not present in the other software the solution was originally found for. Each software has its own quirks and limitations.

You are using your home-made personal metric which very probably nobody else is using. Its very likely to be wrong. Similar in software development dont mean what you think (hope) it means.

Frankly you dont sound like one who has done hands on programming for a while (months, years). May be you have moved up the managerial ladder sometime ago. You sound like a customer who thinks since he has explained what he wants the work will be done by evening.

  • "Frankly you dont sound like one who has done hands on programming for a while (months, years)" -- I am curious how you came to such a drastic and wildly incorrect conclusion.
    – turnip
    Commented Oct 23, 2022 at 12:18
  • You are the one that downvoted obviously. Very self-serving. Anyway, the answer to your question is: you dont give importance to or set aside enough time for implementation. Thats the point of my answer above. Implementation is important. Also, its not inherently bad to move up the managerial ladder.
    – Atif
    Commented Oct 23, 2022 at 13:18
  • "Anyway, the answer to your question is: you dont give importance to or set aside enough time for implementation." -- again, where are you drawing your conclusions from? What in my post makes you think I don't consider implementation time? I've even mentioned task complexity as the first reason for things that can slow one down. That implicitly refers to implementation time. And yes, I downvoted you because you could have easily discussed implementation time without insinuating anything. In fact, your opening statement is good.
    – turnip
    Commented Oct 23, 2022 at 13:32
  • 2
    This, as written, sounds very judgmental (and really jumping to conclusions with little evidence). I expect answers on StackExchange to be have a more constructive approach/tone.
    – Basya
    Commented Oct 24, 2022 at 9:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .