The common trope that feedback is a gift is a misnomer: we love giving and receiving gifts but recoil from delivering and accepting feedback. Some truths are hard to hear and discuss, so the gift-giving metaphor falls short.

What if I told you there was a way to overcome that sinking feeling associated with delivering feedback? Yes, delivering great actionable feedback is a learnable skill that improves with deliberate practice. Read my post to learn some useful techniques.

Designers often complain about the quality of feedback they get from senior stakeholders without realizing it’s usually because of the way they initially have framed the request. In this article, Andy Budd shares a better way of requesting feedback: rather than sharing a linear case study that explains every design revision, the first thing to do would be to better frame the problem.

Tejas Kumar joins Jerod & KBall for a wide-ranging convo about React Suspense, human skills, and the four pillars of impact for web engineers. We also discuss the news in “Story of the Week” and give a few quick shout outs to a must-read book and a great new publishing platform for lead devs.

Join Tejas at React Brussels on October 14, 2022! Get 30% off your ticket when you use code JSPARTYTIME at checkout and follow @JSPartyFM on Twitter for giveaway details.

This week Lee Robinson joins us to talk about his journey as a DevRel. We talk about what it means to be a DevRel, what orgs they fall under, how he runs his team at Vercel, Lee’s three pillars of DevRel: education, community, and product, we compare the old days of DevRel vs now, and of course what makes a DevRel a good DevRel.

Kinda like Product Hunt, but focused on side projects. Post yours to see if people think it rocks (or not). Maybe you’ll find some motivation to continue working on it or feedback on what to work on next.

Interesting findings by Melanie S. Brucks and Jonathan Levav:

According to new research one important skill is impacted by the restrictions of video calls: creativity. But why is idea generation negatively affected? And could other skills actually benefit from virtual communication?

An in-progress list of things you might feel like saying attached to things you should probably say instead. For instance, you’re thinking, “Do your job!” But it’s probably more beneficial to say:

It is my understanding that you are the appropriate person to contact in regards to this. But If there’s is someone better equipped for this let me know.

You can also flip the list to translate what you are being told by someone from what they actually mean.

It’s possible to pair well simply by avoiding pairing poorly.

I’ve never thought about it that way, but yeah, makes sense. What follows is a list of things not to do when pairing. Things for navigators, things for drivers, and things for both.

This is just one page from Tuple’s pair programming guide, which looks excellent all-around.

For many software folk, we prefer our networking to have TCP handshakes, not literal (or even virtual) handshakes. If that’s you, this guide might help you get over the hump:

Here’s the truth: you can get what you need from these events without being awkward or creepy. Whether that’s job leads or important connections, there is a well-defined, time-tested way to accomplish this. It will push your limits, but it won’t leave you feeling gross inside. And the more you do it, the better you’ll get at it.

Rands asking himself some tough questions about our “new normal” remote work environments:

Relative to the Pandemic, the single biggest work question I’ve been asking myself for two years is: what did we lose? What is the measurable and objective loss for teams not working in close proximity? I’ve been looking for cracks. I’ve been looking for leading indicators of future doom. The Great Resignation seems like a proper crack, right? But are people quitting their jobs because they can’t work together or because their current job sucks and all this terror in the air has given them a new appreciation of what really matters?

A sobering perspective.

Ben Kuhn is a big fan of one-on-one meeting between managers and their direct reports to discuss whatever the report wants. So, he suggested his partner try them with him to improver her graduate program experience.

In the end, they succeeded far beyond my expectations: Eve thinks our one-on-ones sped up her dissertation by about a year.

What if we could contribute to a project without having to create a pull request? Imagine all we have to do is to create an issue. Yes, you can with GitHub Actions and the new GitHub Issue Forms. Let’s get to it!

Sound career && life advice by Adam Keys:

It’s possibly the best advice for managers I’ve given so far. When you’re communicating with your team, lead with context and reassurance. Never message someone on your team, “let’s talk when you get a minute”. That’s void of information and scary as heck!

I have to remind myself of this when I’m rushing. It’s faster to ping someone to arrange a synchronous talk than it is to write out what I need to say and cover all the bases. But that doesn’t give me license to skip all the context. Broad strokes are okay. An information vacuum is not okay.

Hmm I probably have to work on this one…

Ashley Willis and Ela Krief join Natalie to discuss the ins and outs of management. They discuss what makes a good manager, common mistakes managers make, how to communicate effectively, dealing with conflict, and much more.

Olivier Lacan did an excellent job explaining his process of upgrading his audio and video setup for post-pandemic life. Comparisons and specific gear recommendations included.

It has become quite absurd to argue that remoteness has to mean becoming a less visible and valued contributor to your organization. I hope this post can help you convince anyone who might still believe that communicating remotely still has to be a pain.

Ellen Spertus on Stack Overflow’s blog:

While there are many resources to help programmers write better code—such as books and static analyzers—there are few for writing better comments. While it’s easy to measure the quantity of comments in a program, it’s hard to measure the quality, and the two are not necessarily correlated. A bad comment is worse than no comment at all. Here are some rules to help you achieve a happy medium.

I like rule #6 (provide links to the original source of copied code) and rule #9 (use comments to mark incomplete implementations) in particular.

Hidde de Vries takes a strong, reasoned stance to online criticism of others’ work:

This week, a friend shared a blog post that critiqued a popular framework for CSS. Twitter started to discuss if it’s okay to criticise tools. In this post, I’ll say it is not just okay, it is also important.

This is a tough subject because we identify so closely with the things we create (our code), but Hidde is right: if we want to progress as an industry (and individually) we need to be able to criticize (constructively) and receive criticism. It’s part of the process.

We should give feedback respectfully and constructively, but we should give feedback. And open up to feedback, not demand it to go away. It may not be easy, but it is important to include perspectives outside your own.

This article covers three main reasons why other engineers may reject your technical initiative (such as refactoring, changing methodologies or switching tools):

1. The proposed goals look unattainable
2. They tried the first version and they didn’t like it
3. They don’t agree that the problem is worth solving

For each of these reasons, there are tips you can use to drive your initiative forward.

Stefan Buck:

In this post I share my learnings of doing code reviews for 10 years. I have received positive feedback from my peers in the blog post and since code review is becoming more and more the standard of development I think sharing my learnings here will may help someone.

Number 10 introduced a new term for me. The “gangsta merge”?! 🤣

You can think of this like Intercom or Drift, only it’s open source and self-hosted (unless you use their hosted offering).

We wanted to make a self-hosted version of tools like Intercom and Drift for companies that have privacy and security concerns about having customer data going to third party services. We’re starting with chat right now but we want to expand into all forms of customer communication like email campaigns and push notifications.

Try out the live chat widget on their demo page.

Ned Batchelder asks the question:

“How do you make a space that is good for beginners when there are too many experts who also want to help?”

He has a few ideas, but mostly Ned is looking for advice/ideas from others. This is a challenging problem for many reasons. How would you approach it?

Sometimes you need to communicate changes to other developers on your project. In a small team, a Slack message works okay, but in larger teams and distributed organizations (such as open source projects), reaching everyone can be a pain.

Logging this because it’s an interesting idea, but I’m not sure if it’s a good idea. Is this a good idea?

Jessica Kerr talking productivity:

What makes a software engineer productive? You can list attributes like experience with the language, scientific mindset, intelligence, focus, a personally crafted IDE setup. Yet, in my experience, far and away the biggest factor is: familiarity with the codebase they’re changing.

This echoes some of our conversation with Jessica last year. She goes on to explain how the purple developer (pictured below) is 10x more productive than the others, not because they are inheritently better than them in some way, but because they are the ones who built the system in the first place.

“Spread the knowledge, spread the productivity.”

I love posts like this because they apply to both work life AND life life. Julia covers helping people clarify their questions, figuring out what they already know, pointing them to documentation, explaining what you did, and more.

Can’t find a job working in Go? Perhaps introducing your current team to Go is the solution. In this episode we talk about how Go was introduced at different organizations, potential pitfalls that may sabotage your efforts, some advice on how to convince your team and CTO to use Go and more.