I’ve long come to prefer the “functional” style of CSS, where each class represents a single CSS property set to a single value. I learned this from Adam Morse, author of Tachyons, which is a older framework, but it still checks out. I’m not here to advocate for this style (read Adam’s post for that), but to talk about how I use SASS to create higher-level re-usable styles with Tachyons, achieve the best of all worlds when managing CSS, all without some unstable, unfriendly JavaScript toolchain.

If I had one piece of advice for using Rails, it is to treat Rails for what it is, not what you might like it to be. This was the subject of my talk at Rails Conf 2022, but it has a few practical implications for, among other things, how to organize the code in your Rails app.

Test-Driven Development is often sold as a way to be more productive or produce better designs, but it’s these unprovable claims that make skeptics even less likely to adopt the practice. Instead, TDD should be sold as a tool to reduce the risk of software not working as intended without expending huge amounts of effort and time doing so. Because that’s what it does (yes, it’s about testing).

Product design—really all of design—is about how the user’s problem is solved. It’s about how it works, not how it looks. Each problem gets addressed in one of five ways: direct support via the happy path, a supported edge case, the customer support team, the engineering team, or oblivion (where it is not actually solved).

Inexperienced designers focus entirely on the happy path, whereas most product designers focus only additionally on edge cases. Even then, the lack of involvement from engineering and customer support can leave the design woefully under-developed.

This post outlines a slightly structured model for thinking through a product design inclusive of the entire user experience, including customer support.

When writing tests, it’s useful to consider that the tests are always in one of four distinct stages, and knowing which stage they are in can direct your next steps. This can make testing a bit less painful than it might otherwise be.

The four stages are:

1. The code doesn’t compile/build/parse
2. The tests produce an error (as opposed to a failure)
3. The tests are failing
4. The tests are passing

As mentioned in a previous post, I’m CTO of an early stage startup and the engineering team is me and one other engineer. We don’t pair program but we do review pull requests—at least sometimes. I want to talk about how we do it, why we think it works, and how it might scale.

Previously, I gave an overview of getting started as CTO of a startup. I’d like to expand on the first part, “Understand How the Business Works” by talking about surfacing business metrics or key performance indicators as early as you can to keep everyone aligned. This is a great way for you to understand the business and motivates good data modeling from the start, which is a great way to manage carrying costs.

Since May of last year, I’ve been CTO of Mood Health, which is a pre-Series-A startup providing clinical treatment for anxiety and depression. The engineering team is myself and one other person, and what I’ve experienced is something I knew intellectually: write as little software as possible.

To do this effectively requires understanding how the business works, designing your code, process, and tools for constant change, and being ruthless in delivering solutions that require the least amount of software. I want to talk about exactly what this means and why it’s important.

Earlier this year, I was in the position to choose the framework for the startup at which I’m now the CTO. I could’ve chosen anything. I went with Rails. And you should, too. It still is the best framework for getting up and running and for continued iteration and development.