tweets from David K. Piano about code reviews

. It reminded me of comments I used to make while reviewing pull requests a couple of years ago:

Reorder imports by grouping them in "some-random-order-I-thought-it-was-correct"

Too often I was replicating “best practices” someone told me in the past or I’ve learned by reading a blog post like this one and I’ve followed them blindly without questioning why I was doing it. However, none of those things were fixing bugs or adding value to the product. I was just making my co-worker’s lives a nightmare by nit-picking on small things.

Most of those comments could be easily fixed by using 

. Some of them couldn’t but they were actually useless. Just because I’d do it differently, it doesn’t mean my way is better. 

, “if it's not automated (e.g., via a linter or formatter), you're either wasting time by manually enforcing it, or the rules are too arbitrary.”

If I could go back in time and give any advice to my old self, it would be: "Hey, dude. Take it easy. Chill out a bit and focus on what's important."

In my experience so far, code reviews are useful for three things:

When we make a generic comment like “Never use Y”, we’re neither avoiding bugs nor using it as an opportunity for learning or teaching. Instead, we should be more specific to the current case:

I think we shouldn’t use Y here because 

As a rule-of-thumb, I try to remember the following:

 Then, it’s also an opportunity for teaching. So, I try to answer the following questions: What bug is it preventing? Why does it happen? How can we fix this?

 Then, it’s an opportunity for learning: 

“I’m not sure I understand this part. Please, could add some comments to explain your reasoning?”

I understand this code, it doesn’t cause any bugs but I’d use a different approach.

 I either leave it alone because it doesn’t change the end-result or I use it as an opportunity for both learning and teaching: 

 This way, I can both teach my approach (in case the other person isn’t familiar with it yet) and learn the reasoning behind not using it (in case that person is familiar with my approach but has a reason for not using it, which I might not have seen).

Some time ago I came across a PR that was fetching millions of items using 

 loop here because it’s blocking the loop. Every post has to wait for the previous request to complete before making another request. This makes the request slower (feel free to run a benchmark and correct me if there’s a mistake in my calculations). We could fix this issue by doing the following:

const batchActions = posts.map(post => doSomething(post.id));

This way, we're performing those actions concurrently, which results on a faster response. Please, let me know if that makes sense or is there something else I’m missing here.

Avoid a performance bug that could hurt the application.

Explain why that issue was happening (blocking the loop).

Give an example of what we could do to fix that issue.

Leave it open to be questioned in case my metrics were wrong or I wasn’t seeing some other problem that made them to use that solution.

Make sure your code review comments are actionable and actually adding value to the product. Don’t waste time on nitpicking things that won’t change the end-result. Does it work as expected and is it passing your CI pipeline? Then, move on.

Code reviews are meant to improve the product and speed up development. If they’re slowing you down and hurting the team, then maybe it’s time to review your practices. At the end of the day, “just chill out and enjoy the ride.” 😉

Will Ceolin

twitter.com

A pluggable and configurable linter tool for identifying and reporting on patterns in JavaScript. Maintain your code quality with ease.

ESLint - Pluggable JavaScript linter

Prettier · Opinionated Code Formatter

Things I wish I knew when I started reviewing pull requests

Mistakes I made in code reviews and what I do now

Shun Kakinoki

Space

When is starlink launching

Space X

, talks about things that might seem obvious the second time you found a startup but they aren't when you're a first-time founder.

First time founders focus on product, second time founders focus on distribution

“First time founders focus on product, second time founders focus on distribution” There are a lot of non-obvious, obvious things about starting a startup: Be a Delaware C-corp if you want to raise capital, talk to your customer all the time, launch fast and figure out how to grow… and most of them are tidbits of knowledge you can hear as a first time founder, but won’t understand until you are a second time founder. 99% of these non-obvious, obvious things are earned through experience and industry expertise while building a trusted network of co-workers and mentors.

Non-Obvious, But Obvious

Non-obvious, obvious things about starting a startup

 teaches how to build GitHub-style hovercards for your Rails application. It uses minimal JavaScript, relying on 

Turbolinks, Stimulus, and Server Rendered HTML is a compelling alternative to modern JavaScript single page apps. Let’s build a hovercard to see how you can kick it old school with a more boring approach.

Building GitHub-style Hovercards with Stimulus and HTML-over-the-wire

Building hovercards on Ruby on Rails

 is a guide for social entrepreneurs to learn how to start and scale a tech nonprofit organization. This guide was created by 

, an accelerator of nonprofits using technology to solve social problems.

The Tech Nonprofit Playbook distills best-in-class advice from the tech nonprofit leaders whose work has transformed the social impact space.

The Tech Nonprofit Playbook - How to Start and Scale a Tech Nonprofit

How to start a tech nonprofit

Jason Evanish compiled an interesting list 101 of questions to ask in one on ones. According to him, "this list will help you make the most of each meeting and have a quick reference when you feel your questions may be getting stale or you have a few minutes left in a one on one."

He covers the following categories of questions:

So you’re having one on ones with your team. Awesome. It’s an essential element to being a good manager. But are you making the most of them? Do you come in prepared and ready to make t…

101 Questions to Ask in One on Ones

Questions to ask in 1 on 1s

Jonas Downey explains how Basecamp built their new email service, 

. Basecamp design lead, Downey was one of the first people to experiment with what would eventually become Hey.

Basecamp design lead Jonas Downey was one of the first people to experiment with what would eventually become Hey, Basecamp’s newly launched email service. Jonas comes on Rework to talk about building software for humans, preserving a sense of fun weirdness as a new product evolves, and managing a big launch during a tumultuous time.



Designing Hey

How Basecamp designed Hey, their new email service

Tutorial teaching how to integrate a MongoDB database into a Next.js application.

Learn how to couple Next.js and MongoDB for your next-generation applications.

Building Modern Applications with Next.js and MongoDB

Building apps with Next.js and MongoDB

 provides interactive exercises and practical problems for learning (and practicing) Regex (Regular expressions).

RegexOne provides a set of interactive lessons and exercises to help you learn regular expressions

RegexOne - Learn Regular Expressions - Lesson 1: An Introduction, and the ABCs

Interactive exercises for learning Regex

This tutorial teaches you how to set up, configure, and use PostgreSQL on macOS. By the time we are finished, you will:

Know how to create and manage databases and users

Know how to use both command-line and UI tools to manage your database

How to set up, configure, and use PostgreSQL on MacOSX 10.7(Lion) and above. 