A few months ago, I had a brilliant idea for a website. Then, I had an even brillianter idea: build the website, but outsource all the work.

Every great website starts with an MVP: the minimum viable product. It demonstrates the idea in its simplest form to test whether anyone is interested. When Twitter launched their MVP, you could only tweet pictures of Russet potatoes. Slack famously launched with language support limited to pig latin. Netflix is now so synonymous with instant streaming that you may have forgotten its first version, which required you to select a movie, then wait several days until Reed Hastings arrived at your house to act out the plot himself.

Prior to February 2019, I published all my retrospectives on Indie Hackers:

• KetoHub Month 2

One of the best things I learned from working at Google is the practice of blame-free postmortems. When something goes wrong, you wait until the dust settles, then write a report analyzing what happened. The report explains how the problem occurred and defines concrete steps the team can take to mitigate the problem in the future.

I saw a good opportunity for a postmortem last week. Work officially completed on a bounty-funded project to integrate Sia support into Minio, but it took several months longer than expected and went through multiple large-scale rewrites.

Getting started writing any new language is easier with the help of your editor. In the case of linters, they can teach you the language’s idioms and best practices while you write your first lines of code. Here’s how to set up a new project in Haskell and configure vim for Haskell. Basic vim setup for Haskell What you’re going to need: Vim 8 Your .vimrc A vim package manager (here I use vundle) Airline (Vim status bar) ALE (Linting engine) ghcmod-vim (Reveal types inline) Haskell / ghc Stack ghc-mod, hlint, hdevtools, hfmt This tutorial assumes you already have Vim 8 installed.

This is the second half of my article about how to communicate well and avoid pitfalls in code reviews. Here, I focus on techniques to bring your code review to a successful close while avoiding ugly conflict.

I laid the groundwork in Part One, so I recommend starting there. If you’re impatient, here’s the short version: a good code reviewer not only finds bugs but provides conscientious feedback to help their teammates improve.