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

Question

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?

Answer 1

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"

Answer 2

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?

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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,

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

...becomes...

BeginCallA()
BeginCallB()
BeginCallC()

EndCallA()
EndCallB()
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.

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

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.

Answer 12

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.

Answer 13

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".