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.
An overview of a Kanban-like process for product management.
More details about using Trello for product management.
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:
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.
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).
Should I use Heroku or AWS? (You can substitute Microsoft Azure or Google Compute Engine for Amazon AWS.)
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.