I work in tech and have a co-worker who does not know how to correctly use asynchronous programming. He's otherwise a fine developer, but this is getting on my nerves a bit because he keeps writing code that is significantly slower than it could be and which could be fixed with a few small changes from sync calls to async ones.

Since I review most of his code, I point out this mistake every time I see it and explain how and why he could use asynchronous programming here but it doesn't seem to "click" for him. I believe if he'd sit down for a few hours, read an article or two about how and where to use it and code a few examples with it, it would make a huge improvement for the code he writes.

I'm having trouble on how to bring this up without sounding condescending/arrogant though, as I feel that's how I would come across if I straight up told a developer with multiple years of experience he should learn such a "basic" skill. How do I best approach this?

  • 20
    Why is it your job to tell another experienced developer to go and learn something "basic", instead of just telling your/his boss about the lack and let them handle it?
    – Aida Paul
    Jun 29, 2023 at 10:29
  • 18
    The environment is a startup, there isn't a manager for me to tell this to, us engineers are in charge of ourselves. Our boss would be the founder, but he's not very technical so I'm not sure he's the right person. We're both staff engineers working in an agile environment with regular sprints, but we do retrospectives on the progress of the project in general rather than individuals. I'm not 100% sure what you mean by "promote continuing education", but our company doesn't offer extra money for paid outside education if that's what you mean. Let me know if you need any other clarification
    – user137679
    Jun 29, 2023 at 11:33
  • 20
    As someone who also works as a programmer, I would want to know if my coworker thought I lacked knowledge about something. I often find myself not knowing something, which I fix by reading up on it. But if I wasn't aware that there was a skill/knowledge I lacked, then I wouldn't be able to fix that lack of skill/knowledge. I'd say, tell him the truth. Jun 29, 2023 at 12:23
  • 47
    The assumption that async is basic makes me think you need to step back and evaluate this more. Assuming simplicity that isn't necessarily there can also be a trap
    – vbnet3d
    Jun 29, 2023 at 19:30
  • 15
    Why do you think using async is required in this code? Jun 29, 2023 at 20:43

13 Answers 13


As part of your code review, you could say, "Can you rewrite this section to be asynchronous? it would greatly improve the speed"

... and include a link to a tutorial showing the basics of async programming in whatever language you're using.

and "Let me know if you have any questions about it"


Why do you consider it a "basic" skill? The ability to program in an async fashion absolutely depends on the language you use. JavaScript? Hell yes. Pascal? Hell no.

Do you consider it basic because you now understand it? Can you think back to a time when you didn't understand it?

Try putting yourself in their shoes and think how would you want to be treated and what would help you learn better? How about pairing with them so you can have the conversations at the time? What about a cheat sheet for when doing something async would be preferred over not doing it?

One final point - you say

he keeps writing code that is significantly slower than it could be

Does it matter? Do you have benchmarks to show you need faster code? Is the async approach more complex and is that complexity warranted?

  • Comments have been moved to chat; please do not continue the discussion here. Before posting a comment below this one, please review the purposes of comments. Comments that do not request clarification or suggest improvements usually belong as an answer, on The Workplace Meta, or in The Workplace Chat. Comments continuing discussion may be removed.
    – Lilienthal
    Jun 30, 2023 at 19:17
  • 5
    I think this answer adds valuable perspective. I applaud the point that the language matters as to how "basic" a skill it is AND the point that profiling (benchmarking) is vital for optimization. However, I feel that it's missing one, vital piece that is at the crux of the question: how to open the conversation, assuming they decide to do it, the part about saying something like, "The code would benefit if you were more familiar with async/await. I'd like to work with you to learn how to use it better.".
    – Corrodias
    Jul 1, 2023 at 0:15

The main thing that makes your feedback condescending is that you call the skill "basic". It's wholly unnecessary to imply that he should really know this, and is an utter moron for not knowing it already, when there is actually a tutorial on the internet that explains it.

Instead, you should abandon that feeling of superiority right away. Yes, there is something you know that he does not, but there are likely also things he knows but you do not. You knowing something he does not does not make you the better person.

Moreover, this is not about who is the more skilled developer, but about using async calls to improve the code. So focus on that!

And if you must send a social message, do so from a place of compassion. For instance, you might share that you, too, found this hard to learn at first, and that tutorial X was the one that made it click for you.

  • 31
    Upvoted for noting that in order to avoid communicating condescension, one has to first avoid feeling condescension. A lot of people think they can simply conceal their true feelings on a subject, but for anyone who isn't a master actor/spy, their true feelings will leak out and be detected within minutes :) Jun 30, 2023 at 1:11
  • 4
    "And if you must send a social message, do so from a place of compassion. For instance, you might share that you, too, found this hard to learn at first, and that tutorial X was the one that made it click for you." this. THIS. Is a purely brilliantly, totally just marvelous answer!! This was stunning. Brilliant!! Jun 30, 2023 at 13:45
  • 2
    Maybe, @JoshPilkington, meriton read between the lines just as the coworker might and sussed out the attitude that the OP is carrying into this. We all feel superior about things we know that all those other morons don't know... If you honestly don't, well, then, you're a better human being than 99.99% of the rest of us.
    – FreeMan
    Jun 30, 2023 at 17:35
  • 4
    @JoshPilkington because the language was arrogant: presupposing this particular skill is basic and should be universal. Instead, the actual issue at play is: the project is written in an async manner, so blocking calls generally should be avoided. The developer simply needs to be told this, and possibly nudged toward some reading about async programming. The fact that the OP did not even think to phrase it like this suggests condescension and a lack of empathy in this situation.
    – chbaker0
    Jun 30, 2023 at 18:22
  • 2
    It's not about being right. Even if coworker should be embarassed for not knowing async, embarassing coworkers is not usually conducive to learning, because every brain cell busy with embarassment is a brain cell not devoted to understanding async. If you want a factual, constructive learning environment, you should not needlessly drag negative emotions into it, and avoid any impression of judging your peers.
    – meriton
    Jul 5, 2023 at 3:44

How to inform a co-worker about a lacking technical skill without sounding condescending

Offer an option to all.

Mention to your boss that during code reviews, you have noticed an ongoing weakness in asynchronous programming.

Ask your boss if you can give a short 30 minute presentation on how to best perform asynchronous programming—maybe as a lunch and learn type event. Be sure to solicit others' opinions on the matter.

If yes, present those basics. If the targeted coworker attends—great.

If the presentation is not approved or the coworker does not attend, simply continue with critiquing code reviews and move on.

  • 7
    So now all colleagues have to waste a lunch break, which is their own time, on a work related presentation that has no value to them. Just because one colleage lacks one specific skill, and another colleague doesn't want to 'confront' them about it?
    – user140332
    Jun 30, 2023 at 6:27
  • 6
    @Servaes A typical lunch and learn is only attended by those interested in the subject. No obligation to attend is implied. By offering to all, everyone interested can learn, even the presenter. Jun 30, 2023 at 8:34
  • 4
    @Servaes In a comment above he mentioned that the programming team is only 3 people. So "all colleagues" is just 2 other people, and one of them is the coworker in question. And even if there were more, if there are regular team meetings you could make this the topic of one of them.
    – Barmar
    Jun 30, 2023 at 14:20
  • If you go this route, be prepared to back up your claim with evidence that this isn't just an opinion thing. eg. It may just be the async adds complexity and your colleagues have made the judgement it isn't worth it for maintainability. Jul 3, 2023 at 11:01
  • 1
    @StackerLee if there is a risk for that, you can also simply adjust the spin of the meeting and formulate it more open as in, let's take a look at async programming and why we might want to use it and where; then get the pros and cons listed, show "how little" added complexity it is (if that's the case) and what your requirements are and see if that meets up. And if everyone else is a naysayer you told them it would cost them later - but ideally you can help them convince themselves that it's a valid solution. Jul 5, 2023 at 2:15

You are framing the problem badly. The problem is not on him, is on the code.

  • When you give the feedback, try to frame the issue around the code itself. "this code does X. if it did Y we'd gain Z." instead of "you did X and you should done Y because Z".

  • Please, be patient. When directing, is common to fellow devs to not understand your sense of quality even after explaining the same thing over and over. Just be patient and take the time to explain it again, finding new ways to do it.

  • Be detailed in your code reviews, give examples, docs, etc. use pair programming so he can see how you code and understand better how you use async and why.

If you give him the time, not only he will grow, but you will earn his respect in a big way. Trust this random internet guy, I applied those principles as tech lead for many years.


The best way is obviously choosing not to get frustrated. Beyond that, how about organizing a workshop about asynchronous programming?

("This is not my job" is not a good reply. Things that will improve the achievements of the company are everybody's job.)

And it is fun. People spend an hour or so learning new techniques and it can begin to change the corporate culture.

For example, I read a book dealing with how the culture of unit testing was expanded in a major company. The way they did it was not "Do unit testing!" but instead implemented a workshop for all new employees implying that "everybody in this company does unit testing" (which was not yet true). Soon, all new employees carried this unit testing culture and changed the corporate culture.

  • What book are you referring to with the unit testing culture change?
    – Naomi R
    Jun 30, 2023 at 19:47

Would it be condescending to say the question relies on a ridiculous premise, which is that async code is "basic"?

Writing correct, resilient, and maintainable multi-threaded code is amongst the most challenging of development activities.

If there are reasonable savings in time for the user, and if there are reasonably local and straightforward transformations between sync and async code, then I'd suggest putting a memo together for your colleague illustrating the code transformation you suggest.

For example,

CallC() //3 seconds each, 9 seconds total



EndCallC() //3 seconds each, 3 seconds total

But if you find that somehow the size of this memo begins to exceed a couple of pages with a few diagrams, then I'd take heed that it may not be as simple to grasp as you believe!

This is especially the case once you add in everything to handle possible failures and errors thrown.

  • OP might clarify, but there might be a different understanding of what basic means... in the sense that driving a car isn't necessarily basic as in simple (there are lots of risks and you can kill people) but for a job as a taxi driver it is a basic skill to be good at your job. Just to consider. (And to be clear: No I don't want to imply that async programming is exactly on the same level of importance for any programmer as driving a car is for a taxi driver, it is just an example to illustrate the point^^) Jul 5, 2023 at 2:17

Instead of explaining it to him, I would try turn it around and let him explain why he didn't use async calls in specific cases. Maybe he has good reasons (they certainly can add complexity and the performance differences of very fast or rarely called functions may not be that important). But don't demand an answer right away, let him time to research an answer. You could try to frame it as "We often seem to have different opinions about synch/asynch calls. I think asynch would be better here but maybe I'm missing something. Can you give me some pros and cons for which to use here?" so that he can't simply give in and use your solution without further thoughts.

More generally I would also try to establish regular short presentations from team members (followed with a discussion) about various technical topics. Come up with a list of topics that you think might be interesting and useful for everyone (programming best practices, patterns, tooling/productivity tips, etc) and include topics that developers struggle with. But instead of holding a presentations yourself about those topics you want others to learn about, you should try to steer it in a way that team members sometimes get to do topics they don't know much about. I actually don't mean to do this just as a cover-up for the asynch topic, but as a sincere attempt to improve overall quality and productivity.


I'm having trouble on how to bring this up without sounding condescending/arrogant though, as I feel that's how I would come across if I straight up told a developer with multiple years of experience he should learn such a "basic" skill. How do I best approach this?

Then the simple answer is: don't.

People have different skillsets, abilities and aptitudes, and what one person will consider "basic", for another may be very exotic and alien if they come from a different backgrounds. If you need a practical example, someone coming from say database engineering background may be very alien indeed to asynchronous, but to him a more API-oriented developer questions about data structures could equally be seen as "basic".

As you are not a leader of the team, it's not your responsibility or even prerogative to tell him to:

sit down for a few hours, read an article or two about how and where to use it and code a few examples with it

It's simply not your job and from what you describe this is how the company is intentionally setup. And the best you can do is to keep showing him a way to what you consider a better way during reviews, but you cannot force him down that path. As this is ultimately what you want to achieve, but it simply is beyond your reach.

Of course if there are serious issues coming from that supposed lack of "basic" knowledge (and I cannot express enough how "basic" is not universal) then you must raise this with whomever the boss is, and explain in very specific term what is the actual harm caused by behaviour X. And I mean example like "because Foo doesn't understand Async operations, the ticket he was working on was delayed, and we had to delay release of X which impacted business in Y way.". If it's not severe enough that you can come with realistic examples of that, best not to rock the boat and possibly turn the relationship into an adversary one. More so as you would be the one overstepping bounds in it.

  • 7
    Telling someone that it would be a good idea to take some time to study is not "[forcing] him down that path". Programmers constantly have to update their skills/knowledge in order to stay relevant in the business. It doesn't hurt the coworker, it helps them. What would hurt the coworker would be to keep this a secret until it is a big enough issue that you go whine to the boss and get your coworker fired. Jun 29, 2023 at 12:29
  • 1
    @EmilKarlsson by all means, feel free to provide contrary answer!
    – Aida Paul
    Jun 29, 2023 at 12:31
  • 3
    Basically the "boss" is this guy and the other developer. That's kind of normal at startup. So how do you tell your co-manager that he sucks at doing his job? Escalating to the owner is a bit extreme especially if the company's owner is non-technical. It is basically saying to the owner - hey look.. this other guy can't do his job.
    – slebetman
    Jun 30, 2023 at 0:53
  • @slebetman your coworker is not your boss, there is a very big difference between those two, whether that's a startup or not you must never forget it. That means while you can lead a horse to water, as a coworker you cannot make that horse drink from it. Same as you cannot force that person to write the code in the way you think is better. And yes, that's what escalation equivalents too, and if it's not that bad, then there's no reason to escalate, and you just have to live with people developing in another way.
    – Aida Paul
    Jun 30, 2023 at 7:16

This isn't a complete answer, but I wonder if linting could help here. I don't know the specifics of the language or what kind of mistakes your colleague is making, but I have found that many recurrent mistakes can be caught with static analysis tools. If your coworker starts spotting red underlines in his code editor, he will likely take the time to learn why. And in the meantime, you won't be wasting time repeating yourself in code reviews.

For an example of linting rules that can reduce errors when writing asynchronous code, see this article about rules for JavaScript.


Just proving him how much asynchronous calls are improving your software by benchmarking your version against his should trigger interest in his mind.

You could also have the team decide that the software should be async whenever possible, after which you’d just have to ask him to have his code comply with the policy.

Note that both options could backfire, if the expected improvements are not dramatic or if the team doesn’t reach an agreement on the policy.

  • 1
    To potentially include if you agree: The benchmark can also backfire in that it can feel as a personal attack ( being perceived as "hehe, see, my code is twice as fast as yours, told you so") especially if it comes out of the blue. If a benchmark then I'd rather do that in a workshop or demonstration where all code is provided by OP and if the colleague then still argues that they can improve the synchronous code to be as fast, then it can get an interesting coding competition and something to learn for both perhaps^^ (still with some risk that there will be a sore looser but hopefully less) Jul 5, 2023 at 2:25
  • @FrankHopkins Out of scratch I’d agree, but in the context of this question it is assumed that OP already discussed this question multiple times with his colleague, so he wouldn’t be bragging, but just proving his point, IMO. Although if the colleague is sensitive it might be worth benchmarking on a code sample rather than his actual code indeed. Jul 5, 2023 at 12:48

code that is significantly slower than it could be

This sounds like a what's known as a pissing contest. If the requirements are not specific on performance, and you're not his boss, then maybe the best approach is for you to back off a bit. Your own ego, and not the organization, is the only thing driving this async/sync concern. If the business puts performance specs in the requirements, that's another thing -- but you don't really have a leg to stand on right now with this issue, as far as I see.

Let it go.


I find the most effective way to communicate a lot of things in programming is the "illustrative toy example". You might write up the smallest program you can, once using synchronous logic and once using asynchronous logic, add some debug-prints to it showing the difference in performance between the two, and then send out a general email (and/or a short narrated screen-capture-video) saying "hey, check out this demo of asynchronous programming and how much of a benefit you can get from it".

Seeing is believing, and once someone genuinely understands how a technique will make their life easier and their work product better, they'll be a lot more motivated to use it than if their understanding is only along the lines of "so-and-so says this is the right way to do it".

  • Hmm.... my experience with those sort of mails is that many people think to themselves "Oh, there's something interesting I'll check out later when I get the time... " but never actually do. It doesn't drive home the point that this is what we should be doing.
    – komodosp
    Jun 30, 2023 at 8:41
  • Yes, that is a risk, which is why I try to keep the content as minimal as possible. The chances of someone looking at the content is inversely proportional to the amount of time they expect it to take to review it. Jun 30, 2023 at 13:33

You must log in to answer this question.