Disclaimer: This article is a bit of an ironic take on the unironic brag posts of “successful” people you’ll find on platforms like LinkedIn. Nevertheless, there are some learnings about software quality that could be helpful.

What can riding a bike tell me about writing software? Well, actually, not so much, since I’ve been a professional software developer for far longer than I’ve enjoyed bikepacking. But nevertheless, there are quite some interesting parallels I discovered.

Before we start, if you don’t know about bikepacking, it’s like going on vacation, but you carry everything you need on your bike. It is a very minimalist way to travel, but that’s precisely what’s so great about it.

Alright, let’s go:

1. Less is more

Only carry what you really need. The fewer items you have, the fewer things can break, the further you can travel, and the more fun you have. At some point you learn that you don’t need as many things on the way as you thought.

Sometimes I think companies just keep adding new features because they have a Product team they need to keep busy. Or do you really use any other features of Slack than messaging? But bloated software has many negative sides. The complexity makes it error-prone, and it requires more resources to operate it. This is costly and produces plenty of carbon emissions.

Your users will also appreciate an app that reacts fast. Fast-loading websites are better for the user experience. An app that doesn’t drain the battery in minutes is much more useful. Same as a light and swift bike.

2. Simplicity

Chose standard components over exotic solutions. You don’t want to end up in some remote location where it takes a couple of days to get a replacement part delivered.

Likewise, prefer simple solutions for problems rather than over-engineering. You don’t want to end up with a piece of software that can only be understood by the developer who just left the company. Simpler solutions tend to be more robust and less energy-thirsty, too.

3. Know and trust your stack

On a long-range trip, your bike is your best companion. The more you know about it, the more problems you can solve on your own. The more you trust it, the more fun you have.

Running an app on a production environment that you hardly know is like a lottery. It might go well. But odds are high that something (TM) will happen. When (not if) production issues occur, knowing how your stack works definitely helps to keep downtimes low. And your blood pressure, too.

4. Test your equipment

Never take an untested piece of equipment on a trip. Chances are high that it doesn’t work as expected, and then you’re screwed.

The same goes for your shiny new library or external service – test it carefully before exposing it to production the first time. You want to know if and how it scales under load, for example. This will avoid unpleasant surprises.

5. Quality is key

Cheap equipment is often tempting. What could possibly go wrong? Well, spending a few more bucks can definitely make a difference.

The bags for my bike are not from the cheapest brand, but I know that they will last almost forever, and the parts that can break are easily replaceable (as in, easy to buy spare parts and easy to exchange). It saves money eventually and is better for the environment.

Writing code that fulfills modern software quality standards is more costly. However, others (and yourself, like after not touching the code base for a few months) will still be able to understand and maintain the code.

If you require a service or a commercial tool, don’t just look for its price. I’m often surprised how many managers entirely ignore the working hours it costs to operate a tool that is not the best choice but costs a bit less money per month.

6. Training is essential

Don’t expect to master your first overland trip immediately. It will take you some training, but you’ll get there – be it biking or software development, working on your skills and gathering experience is essential. For example, the first time you fixed a flat tire or the chain should not be on a tour, even if you watched a YouTube video about it a couple of days ago.

On the tech side, don’t expect to do everything perfectly immediately. It takes time, experience, and learning through failure. To not get surprised by a production outage, for example, conduct disaster recovery exercises. Write down your findings, and create playbooks with easy steps that you can follow when necessary. You will appreciate it in stressful situations for sure.

7. Preparation and requirements

You just launched a new feature within the tight deadline but realize you’ve not considered an important case, and it now bites you in the behind? Now you have to roll back, and customers are unhappy. Probably you should have spent some more time on the requirements, even if that means making the management unhappy (they will always be, anyway).

Before I go on longer trips, I always check what weather to expect, which shops are nearby, where to get some fresh water, or if there is a train connection available in case my bike breaks down. Having alternatives in mind allows me to quickly react to problems.

8. Cleanup and maintenance

A dirty drivetrain reduces your performance and the longevity of important bike components. So you are better off cleaning them regularly. Of course, you should also check the rest of your bike, like screws or tires, now and then to avoid unpleasant surprises.

The same should apply to your software. If I got a penny for every time a full disk caused problems (yes, even in the cloud), I still wouldn’t be rich, but I’d have a nice collection of coins. Seriously, bringing out the garbage (cleaning logs, backups, etc), cleaning up your code, checking your monitoring & logging for unusual patterns, updating (and removing) dependencies regularly, and so on, should be part of your routine to keep things going nice and smoothly.

You and your customers will benefit from better performance, lower operational costs, and a smaller carbon footprint. Enjoy the ride!

9. Take breaks

Bike trips can be exhausting. Just take a break when you need it. Have a coffee and some snacks, and it’ll be easier afterwards.

This is similar to what I encountered when working on challenging issues. If you are stuck on a problem, take a break, have a walk around the block, or sleep on it. Often enough, the solution will come easily when you’re back at your desk.

10. Doing it yourself is more fun

The feeling of accomplishing a pretty long ride only with my muscle power is unbeatable for me. Taking this minimalist approach feels wholesome. That’s real freedom, which I can’t have on an e-bike or in a car. No extra electricity or fuel is required.

Many people are hyped about vibe coding and all that AI stuff. And while I use it too (where it makes sense), I also still enjoy hand-crafting my code. This way, I don’t have to rely on an LLM to accomplish my tasks when it starts writing bulls… hallucinating.

Lessons learned

And that’s it! Although it started as some kind of fun post, I think there are numerous good practices that software development and bikepacking have in common. Seriously, I had to learn some lessons the hard way for both.

Thank you for reading, and stay tuned for my next article, “15 surprising facts doing the chores told me about cloud infrastructure” (kidding) ;-)