Skip to content

Instantly share code, notes, and snippets.

@MIchaelMainer

MIchaelMainer/coding_with_empathy.md

Last active March 29, 2021 17:57
Show Gist options
  • Save MIchaelMainer/6256cb492f1656a9616d3dbc1cf75db2 to your computer and use it in GitHub Desktop.
Save MIchaelMainer/6256cb492f1656a9616d3dbc1cf75db2 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
coding_with_empathy.md

WIP

I've started to read some interesting articles around "coding with empathy". I finally have a name to attribute to what I've been feeling. I review code. I get concerned about future privacy incidents stemming from changes in the source. I'm concerned for future maintainers of the code base. I'm concerned for the future cognitive load costs to acquire the context to understand the code years from now. I'm concerned about my own lack of conformance to standards. I'm concerned about my co-worker's lack of code comments. I'm impressed with my co-worker's standard commit message format. I appreciate asks for standards. A lot of my feelings (not all I must admit) of concern were coming from a place of empathy - I just didn't realize it.

There is empathy for:

  • your future self when you no longer have the context of that code loaded into your brain.
  • another maintainer that has no idea around what was your thoughts that brought this into your mind.
  • customers that pay the downstream price for code that was harder to maintain because it was written without empathy.

The diversity and inclusion work that happens around us at this company is fundamentally about empathy. Let's take that empathy into how we conduct ourselves in the technical work.

Concrete actions around coding with empathy:

  • write clean commit messages
  • comment when there is more to understand than the code fragment in front of you.
  • apply the deliberateness you have when naming a child as you do when naming variables, functions, classes, modules, etc.
  • factor your code for maintainability -
  • write lots of tests - it will make future maintainers more confident in making changes without breaking something.

Reviewing with empathy

  • assume the code writer was doing their best when they wrote the code. Assigning blame and shame is the opposite of empathy.
  • avoid imperatives when writing review comments. Think of these as teachable moments.
  • do use positive language and consider tone.

You can still provide critical feedback and maintain empathy. It is about intent and delivery. Maintain the intention to improve the code or design, to use it as a teachable moment. Deliver the feedback in the positive to neutral terms, avoid negative or accusatory statements.

Designing with empathy

WIP

Documenting with empathy

WIP

I'd like to develop a presentation on this topic for a team DevX forum discussion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment