New Year’s & the Power of Mindset

In some ways, New Year’s is nothing more than a collective fantasy – we flip the page on a calendar or the date displayed by our phones now reads “Jan 1” and we all agree that this means that it’s now a “new year” and time for a “new start”. Maybe all of this is a bit arbitrary, but I don’t think that it necessarily follows that it’s unhelpful or meaningless to frame one date vs. another as “new.”

Continue reading “New Year’s & the Power of Mindset”

Rails 7: The Missing Instructions

Sadly, I had a lot of difficulty getting Rails 7 with Turbo and Stimulus up and running. The Rails docs feel like they’re missing a few steps, so I wanted to document the commands I needed to run to get Rails 7 with the hotwire.dev tooling up and running.

Continue reading “Rails 7: The Missing Instructions”

Best Practice: Code Like No One’s Watching

When writing code, it’s often easy to trigger the “freeze” response from the “fight, flight, freeze, or fawn” list of trauma responses.

“I bet I could make this SQL query more performant…”

“It feels like I could use a design pattern here…”

“This variable needs a better name…”

There are multiple issues at play here:

Continue reading “Best Practice: Code Like No One’s Watching”

The Single Best Piece of Productivity Advice I’ve Received

This advice came from a former employer who mentioned it during a team-wide productivity learning session. It’s not original to him, but it’s where I first heard it:

Continue reading “The Single Best Piece of Productivity Advice I’ve Received”

Ruby Paper Cuts

I love programming in Ruby and (especially) the Ruby on Rails framework. That said, they both have some oddities and conventions that leave me scratching my head, making me wonder what such smart people are thinking, and questioning the very nature of reality…you know, much like an episode of a Disney+ or CW show.

Continue reading “Ruby Paper Cuts”

“Tests” are Not “Code Quality”

“Tests” and “code quality” – two concepts that I’ve seen conflated by developers, team leads, and CTOs alike:

Our codebase has a lot of tests and great test coverage.
Our codebase is high-quality!

No, not necessarily. All that having a lot of tests means is that you’ve, you know, tested your code. Having 100% test coverage says nothing about the quality of the code being tested.

Tests don’t atone for bad architecture. Tests don’t absolve you of design pattern violations. Tests don’t repay tech debt.

You can test good code. And you can test bad code.