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
The four stages are:
The code doesn’t compile/build/parse
The tests produce an error (as opposed to a failure)
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.
Way back at RubyConf 2019, I announced a book about sustainable web development using Ruby on Rails, based on my 6+
y ears of experience doing so at Stitch Fix (and 18 months not doing so at LivingSocial).
It’s done, it’s 450 pages, and you can buy it now for $49.95 as an ebook (PDF, epub, Kindle, Markdown
formats). If you write Rails code professionally, and struggle with keeping your app maintainable and easy to work
on, this is the book for you.
Getting responsive images to work via the srcset and size attributes to img is not easy, especially because
almost all documentation I have found is vague as to what exactly the word “pixel” means in any given context.
This post will sort that out.
I recently did an interview with local DC dev community Hatchpad about the dangers of blindly applying patterns, and how not-helpful the SOLID principles are.
One thing mentioned that isn’t in the SOLID book is that we all need to understand not just the
advice we’re given, but who is giving it. What is the actual experience of the person telling us how we should
If someone is giving out advice I want to know – “Have you done that? Have you experienced this problem, or is it just theoretical?”
I try very hard to only give advice based on my actual experience, and I try to contexutalize that experience as
much as I can to avoid it being mis-applied. It’s not easy and I don’t always do a great job, but I’m very aware
of it. Even if my advice boils down to “it worked for me, anyway”, that’s better than “I haven’t tried it, but it seems neat”.
Names of things matter. How we react to the realization that some names of some things offend some people is
important. Unlike the names of countries, towns, or Army forts, computer software can actually be renamed
relatively easily, yet we still struggle to have even basic conversations about it.
I want to share the way I think about it: acknowledge a person’s feelings, understand who might feel excluded by
a name, decide if excluding them is OK, and, if not, figure out how to change the name.