What if you could prove to your team that one of your commits didn’t change any behavior? And by any, I mean any. It doesn’t add a new feature; it doesn’t fix a bug. It’s nearly impossible that any behavior is altered by the commit. If you could do that, how would it affect the way your team operates?
Over the years, we’ve seen a bunch of projects in different states of disrepair. We approach each one of these projects with the assumption that every person who touched it did their best at the time with their given constraints. This is the embodiment of our first core value Act With Empathy.
Several months ago, I got a notification to upgrade Docker for Mac to version 18, and there was a note in the recent changes that caught my eye.
Wouldn't it be great if there were a documentation tool that's directly tied to the source code (so that you can always access information that's relevant to the code you're looking at), that doesn't clutter up the code itself, that's carefully and automatically timestamped (so that you know how current its information is), and that's guaranteed to be updated whenever the code is? Oh, wait. There is.
We recently changed one of our core values to remove an obviously gendered term. This is an exploration of what prompted us to do so.
I’ve had the idea for a new testing tool in the back of my head for years. I’ve been calling it Cukeness (more on that name later). I was actually working on the project when I first asked Andrea to join me on the Corgibytes journey. I did a horrible job of explaining to her why it needed to exist. So she said that I should put it on pause and focus on other things instead.
This wasn't the sexiest project we've ever worked on, but a combination of good tooling, careful preparation, and a fair amount of mind-melting compiler error resolution made this a one of our best remodeling efforts of 2018.
A little while back, I arrived at my desk to a message no one likes to receive: the production instance of a client's primary app was down. What's more, the site had just gone live earlier that week, and thousands of users were trying to login.
If you want to eliminate your technical debt, communication HAS to be a critical component of your efforts. If you're struggling to break up your monolith and move to a microservices model, the first place to look is how your team is communicating. Command and control silos will result in monoliths. Self-organizing and autonomous teams give rise to microservices.
We frequently work on projects where it's best to start out with an older version of ruby. Getting these to install correctly feels like a dark art sometimes. Here's a quick series of steps that we had to follow to get Ruby 1.8.7 using RubyGems 1.8.30 installed via RVM.