A few readings on managing software products

A grab-bag of readings that I found helpful. These are all just opinions; there’s not one true way of doing anything. It depends on the project and on the team. However, the below readings should give you a good place to start and iterate from.


Kanban/Trello Workflow

An overview of a Kanban-like process for product management.

More details about using Trello for product management.

A very powerful Git flow

This is behind a paywall (but there’s a trial period). It’s very low-level and tactical, so it might be hard to understand right now; but you should refer developers that you work with to it, and they should either have a flow similar to this one, or very good reasons for using something different:

thoughtbot’s Git Flow

Code Review

One of the most common questions I hear is, “How do I keep my team happy / how do I retain good developers?”

One of the most important components of staying happy for developers is feeling like we’re always continuing to learn.

One of the best ways to promote learning on a team is a strong Code Review Culture.

  • It feels great to get alternative ideas on how to attack a problem right when you are setting out. Often, someone else on the team can alert you to a different approach that you hadn’t considered or heard about.
  • You would be surprised at how often a junior developer can teach a senior developer a new trick.
  • And, obviously, Code Review is an incredibly good way to train junior developers.
  • Code Reviews demolish knowledge silos, reducing your risk.
  • Oh, and they helps catch bugs sometimes, too.

A low-level walkthrough of how to perform productive code reviews.

A high-level perspective on how and why to implement a strong Code Review culture.


The development section of thoughtbot’s Playbook (the whole thing is worth a read).

Technology Choices


Should I use Heroku or AWS? (You can substitute Microsoft Azure or Google Compute Engine for Amazon AWS.)

Cutting edge vs boring tech

Choose Boring Technology:

Let’s say every company gets about three innovation tokens. You can spend these however you want, but the supply is fixed for a long while. You might get a few more after you achieve a certain level of stability and maturity, but the general tendency is to overestimate the contents of your wallet. Clearly this model is approximate, but I think it helps.

If you choose to write your website in NodeJS, you just spent one of your innovation tokens. If you choose to use MongoDB, you just spent one of your innovation tokens. If you choose to use service discovery tech that’s existed for a year or less, you just spent one of your innovation tokens. If you choose to write your own database, oh god, you’re in trouble.

I believe Rails is this kind (the good kind) of “boring”.

A counterpoint: Why I wouldn’t use Rails for a new company. The author’s basic thesis is to “skate where the puck is going” in terms of developer enthusiasm/mindshare, which makes sense.

However, I don’t believe that there is a clear successor to Rails – yet. The author mentions Node.js, but I believe that it has already stabilized in mindshare. Elm and Phoenix are both showing promise, but they still aren’t even close to having a rich ecosystem of “gems” and Stack Overflow answers like Rails has, so you will be spending some of your “innovation tokens” re-inventing things that the Rails community has already solved.

Here’s DHH himself on the topic: What makes Rails a framework worth learning in 2017?


A guide to producing software estimates.

A counterpoint: Why software estimation is a losing game

I tend to agree with the latter.


A collection of essays from Basecamp on Hiring.