---
title: "Make Friends on the Ship: Working Happily With Colleagues"
author: "Harry"
published: 2026-10-31T04:49:28.017Z
updated: 2026-10-31T05:08:08.372Z
category: "Career & Teams"
tags: []
canonical: "https://fxblog.dev/posts/how-to-get-along-with-coworkers-developer"
---

# Make Friends on the Ship: Working Happily With Colleagues

## Key takeaways

- A fast, one-line answer from a busy colleague is help, not dislike: judge what people do, not how they type.
- Help that costs you ten minutes, like a quick review or a pairing session, adds up week after week.
- Give credit in public and by name; it costs nothing and people remember it.
- When you find a colleague's bug, tell them first and fix it with them, then thank them in the pull request.
- Teams where people feel safe to speak up do better work; you add to that safety every time you respond kindly to a question.

> **TL;DR** Misread a colleague's short reply, or correct a senior in front of everyone, and you stay a guest on the team for months. How to get along with coworkers: build trust in small, repeated acts. Thank people by name in public, help in ten-minute pieces, and when you find someone's bug, tell them privately first and fix it with them.
>
> **Do this:** Thank one colleague by name in a public channel this week, for one specific thing they did.

Part 2 ended with Pip unstuck and worried. Brock's answer was one line long, no greeting, no smiley. Is he annoyed? Does the crew like her at all? At lunch she finally asks Bun, who is busy filling bowls.

"Brock answered in one line. Did I annoy him?"

"He answered _fast_," says Bun. "That's his compliment. Dumpling?"

**Dev Voyage: Calm Sea, in five parts:**

1. **Your First 90 Days: How to Join a Crew Without Sinking**
2. **Ask Better Questions: The Skill That Saves Your First Month**
3. **Make Friends on the Ship: Working Happily With Colleagues** (you are here)
4. **When You Break Something: Owning a Mistake Without Losing Trust**
5. **Pass Probation on Purpose**

## Read what people do, not how they type

Some people write warm paragraphs. Some write `Node 20. .nvmrc` and go back to work. Brock replied within minutes to a question from someone he had met twice. That's what a crewmate looks like when he's busy.

> **Tip**
>
> Before you decide what someone feels, look at what they did. A fast, correct, one-line answer is help.

## Say thank you where everyone can see it

Bun's second piece of advice was to thank him in the channel. So Pip did:

```text
Thanks @Brock, the .nvmrc tip fixed my build in 10 minutes.
```

Five seconds to write. Brock felt seen, and everyone else learned who knows the build. Brock's reply was "...anytime", which, from Brock, is a speech.

Public thanks is one of a handful of cheap habits that add up. Review someone's pull request and say what you checked. Offer to pair on the thing you fought with yesterday. Fix the broken docs link nobody owns, and mention it in one line. None of these takes more than ten minutes, and people remember who made their week easier.

## Correct in private, first

In week five Pip found that `test_checkout`, one of Brock's tests, failed about one run in five. She saw three ways to handle it.

![Pip finds Brock's flaky test: she can fix it quietly, call it out in public, or tell him first and fix it with him; only the last builds trust and keeps the test fixed](https://fxblog.dev/media/01a1904a-63b8-737b-8f8e-ec44af15e6be/1600)

_Same bug, three ways to handle it_

Fixing it quietly means Brock never learns the cause, so his next test has the same timing bug. Raising it in standup gets it fixed, and Brock remembers being corrected in front of everyone. Pip took the third way and sent a direct message:

```text
I think test_checkout fails about one run in five because it waits
a fixed 200 ms for the cart. Want to pair on it?
```

They fixed it in twenty minutes. The pull request said "with Brock".

> **Warning**
>
> Don't open with the bug in a meeting, even when you're sure. Being right in public costs you the person you were right about.

## This is part of the job

It's tempting to file all this under being nice, on top of the real work. But when Google studied what made its own teams effective, in Project Aristotle, the strongest factor it found was psychological safety. Amy Edmondson's research, written up in Harvard Business Review, describes the same idea.

> **Note**
>
> Psychological safety, in Google re:Work's words: team members feel safe to take risks and be vulnerable in front of each other.

Every kind answer to a newcomer, every public thank-you and every private correction makes your team a bit safer to speak up in. You don't need to be senior to start.

## Try it

This week:

1. Thank one person by name, in a public channel, for something specific.
2. Review one pull request and say what you checked.
3. If you find a colleague's bug, message them privately with the evidence and offer to pair.

By week seven Pip has a friend in Bun, a pairing partner in Brock, and the discount feature is nearly done. On Friday at 17:32, with everyone thinking about the weekend, she deploys it. At 17:38 checkout starts returning errors to real customers. Part 4, **When You Break Something: Owning a Mistake Without Losing Trust**, is Pip's next hour, and what Kit says when she tells him.

## Read this with your AI

```text
Read the post "Make Friends on the Ship: Working Happily With Colleagues".
1. I'll describe a colleague's mistake I found. Draft the private message I should send them.
2. Suggest three small ways I can help my team this week, given my role.
3. Rewrite my last thank-you message so it names the person and what they did.
```

> **Success**
>
> You can build trust with colleagues on purpose, and correct someone without losing them. Next: **When You Break Something: Owning a Mistake Without Losing Trust**.

## FAQ

### How do I point out a senior colleague's mistake?

Privately and first, with the evidence and an offer to help: "I think test\_checkout fails one run in five because of a timing wait; want to pair on it?" Fixing it quietly or raising it in a meeting first both cost trust.

### Does a one-line reply from a colleague mean they are annoyed?

Usually not. Look at what they did: a fast, correct answer to someone they barely know is help. Thank them by name in the channel; that tells you more about the relationship than their writing style.