You and your team have decided it’s time to build a new feature. You’re adding wings to your flagship car but you aren’t sure whether they should be swept forwards or back and you can’t decide. So what do you do? You run an experiment!

As someone whose able to build software, and has done professionally for quite a while now, it can be hard to put yourself back in those early days of when you used to do all this stuff for fun without a care in the world. That’s something I’ve been trying to get back to recently, and the way I’ve been able to do it is to write just software for me.

Working in software is to be surrounded by constant change. It can be really difficult to figure out:

As developers we often plant our flag in a particular lane or technology and then ride that wave as long as we can. Sometimes it’s because you really enjoy that thing and just want to keep using it, sometimes it’s because you think that’s the best move for your career, or sometimes you’re force to based on the kind of field you work in.

If you’ve been part of the workforce for any amount of time you’ll have an opinion on meetings. They can range from a chat between two people through to 100+ people all getting presented at. Meetings can be either in-person or online nowadays, and honestly there’s not much difference between them for the purposes of this post (though I value in-person more).

A topic that always crops on when speaking to Ruby on Rails developers is fixtures, or factories. A common dividing line or fence that people typically fall on one side or another of.

Depending on where you work, engineering is often one of the last teams to learn about an upcoming feature. A lot of the time it has already been discussed and debated by Product and Design teams, trying to hone in on exactly what it is they want to build, and then engineering gets handed the final result often present as: this is what we want to do, go do it.

It has been a while since I’d attended a conference that gave me such an energy boost that I feel compelled to write about it, but that’s what happened at Rails World 2023 back in October.

It’s extremely rare that the first implementation that I write to solve a problem is the best one I’m able to come up with.

I’ve been recently trying to think of my work as operating at different “zoom levels”. We often fall into these modes automatically, but it’s something you can consciously do if you identify the need.