There’s nothing quite like having inspiration for a software idea and then jumping into your editor to start coding. At the beginning everything is great: you’re bootstrapping everything and implementing the core idea, fine tuning the UI for the experience you want, and making minor adjustments to the concept as you start to actually use it. But after a while motivation starts to wane and then one day you don’t even open your editor. Eventually you forget about it and question what you found exciting about it in the first place.

There’s an ongoing joke that it will eventually be the year of Linux on the desktop. When it will finally become useful for the masses to flock to the almighty free and open source operating system that is Linux. I don’t think that’s the case just yet, but for 2024 it was true for me.

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.