Back in 2014, I started to experience repetitive stress injury (RSI) pain in my forearms and wrists. At the time, I’d moved from a hybrid “talk to people / type at a computer” type job to a job that was pretty much full-time “type at a computer.” The pain started to become pretty debilitating, and I even developed a ganglion cyst in one of my wrists. Things weren’t getting any better on their own so it was time to do something.
I’m definitely more of a “try to fix it yourself before resorting to expensive medical treatments” kind of guy, so I started doing some research, making some changes, and trying a few different things. Now, almost 10 years later, I’m completely pain-free so long as I stick to some good habits and use good tools. In the hopes that my learning will help others, here’s what helped me overcome RSI as a software developer.
DISCLAIMER: I am not a doctor, so please consult with yours before making any changes. The following is more a summary of my journey that you can hopefully use as a jumping off point for your own recovery and should not be taken as medical advice – use at your own risk.
Continue reading “RSI and Software Development”
I recently wrote a post for the Maxwell Engineering blog regarding best practices around using concerns (aka. modules or mix-ins) in Ruby. You can check out part one of the four-part series at the following link:
Concerns in Ruby: Part 1: Concerning Concerns
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”
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”
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”
Recently, I needed to debug some issues with a Sidekiq queue in a Ruby on Rails app and figured I’d take the time to figure out how to run Sidekiq locally. Thankfully, it’s really quite easy!
Continue reading “Running Sidekiq Locally in Rails”
“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.
The road forks.
The two paths are “do it right and push the deadline” or “take on technical debt.”
Neither path should be taken all the time.
There are two possible ways to use story points in Agile. One is toxic, demoralizing, and will probably drive your developers to look for employment elsewhere, while the other is mildly helpful, which is about all you can hope for from story points in Agile.
Can you tell which is which?
“This [story / issue / ticket / whatever] was estimated as only 2 points (about one day’s worth of work) but it took a whole week to complete!
“Why did it take so long?!”
“We estimated this [story / issue / ticket / whatever] as being 2 points (about one day’s worth of work) but it ended up taking an entire week.
“What did we miss in estimating that could have told us that this task was more than 2 points worth of work? How can we improve our process?”