Communications Icon

Communications

How developers communicate.
38 Stories
All Topics

Abdulfatai Popoola abdulapopoola.com

10x your feedback game by choosing kindness over niceness

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.

Smashing Magazine Icon Smashing Magazine

How designers should ask for (and receive) high-quality feedback

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.

JS Party JS Party #240

Bringing the vibe

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.

Communications howtoprofessionallysay.akashrajpurohit.com

A guide for your daily "professional" interactions

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.

Communications samjulien.com

The painfully shy developer's guide to networking for a better job

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.

Communications randsinrepose.com

What we lost (when we went remote)

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.

Adam Keys therealadam.com

Don’t be spooky

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…

Communications olivierlacan.com

High fidelity remote communication

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 stackoverflow.blog

Best practices for writing code comments

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 hiddedevries.nl

Criticism pushes the web forward

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.

Evgenii Ponomarev evgenii.info

How to deal with pushback to your initiatives

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 stefanbuck.com

Tips to get faster code reviews

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”?! 🤣

Elixir github.com

Papercups - open source live customer chat in Elixir

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.

Git github.com

Communicate important updates to your team via git commit messages

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?

Communicate important updates to your team via git commit messages

Jessica Kerr jessitron.com

Why purple developers are the real 10x engineers

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

Why purple developers are the real 10x engineers
Player art
  0:00 / 0:00