Lessons I Learned Working on Motorcycles I Use as a Developer

Long before becoming a developer had even crossed my mind, I knew I loved motorcycles. The problem solving, logic ,and reward from fixing a mechanical problem and getting a bike back on the road (or dirt) was hugely rewarding.

At first glance, coding and working on motorcycles seem to be very different skills. The general task of problem solving seems to be the only clear similarity. As I've progressed in my career, I've realized just how similar the two can be. It's surprising how many of the lessons in patience and logic that I learned from working on motorcycles, could aid me just as well if I applied them in my job as a developer. These are a few of the lessons most schools don't teach that working on motorcycles taught me and have aided me the most as a developer .

Don't chose something just because it's the newest, coolest, cutting edge thing out.

Many people will avoid buying a motorcycle the first year a model or version is out. People would rather wait and see if all the kinks were worked out before release or if there's something that needs to be fixed in the following years, recalls that need to be handled, or just a bad design that may dissuade the buyer from the new model altogether. In development - software, frameworks, and tools are often like this too. Some of the main reasons to be cautious about using the newest option is the potential lack of support, untested code, lack of knowledge base, or few resources. Sometimes these are quickly ironed out, the code is proven true and mass adoption provides enough support and documentation to adopt fairly early. Sometimes the lack of resources becomes a brick wall in your project which only lots of time and investigation can tear down.

It's hard to know when there may be some major hidden bugs, oversights and gotchas that could render your software nearly useless. In the worst case, after testing, the code could have to be completely redone or restructured. Unless you really know what you're doing and can dig in to find the source of an issue, in code you may not have written, it's probably better to wait until there's a little more of a support community, there's plenty of documentation, and bugs have been exposed and worked out.

Keep things clean and organized

When taking a bike apart or putting it back together, a dirty workspace and disorganized parts and procedures can make a job that should have taken a couple hours take far longer. In the moment, it's easy to believe you'll remember where all the nuts, bolts, and clips go and in what order, but quickly the number of parts on the floor has tripled and an easy task has become a puzzling exercise of trial and error.

Code can end up the same way, it can quickly become a disorganized mess due to poorly named components, thrown together methods, code you meant to revise later, and duplicate snippets that could be better structured for reuse. Sometimes it helps to think about your projects as if you were going to stand up and walk away from them at any moment, leaving some stranger to continue what you started with no explanation, using only what currently exists. In an ideal world , they should be able to walk in the next day, review your task, find all of the parts of your disassembled engine, or the parts of your project that are in progress, and be able to pick it up and continue without extreme frustration and lengthy investigation. This isn't to say that every line of code should have a comment (or every piece you remove from the motorcycle should have a written journal entry of your procedure).

It's important to find a good middle ground so you're not wasting time but also setting yourself, and anyone you're working with, up for success. The importance of keeping your projects and project space neat and organized can apply not just to your code, but also to your desk workspace. Keeping your desk and digital workspaces clean and uncluttered makes for easier focus, less frustration and quicker stop and startup time.

Make sure you truly understand what you're doing

If you don't understand how a motorcycle or its components work, it's highly likely that you won't be able to put everything back the way you found it without a lot of extra headache. Similarly, if you don't fully understand the tools or frameworks you're working with, you're greatly increasing your chances for failure. It's so much easier sometimes just to copy and paste in code from examples, quickly test the easiest scenario and move on. After all, if it works, why invest more time on an already tight time schedule… Right?

Wrong.

Code in examples isn't always up to date to the latest version, it might be a hugely oversimplified to show the bare minimum, or it might be extremely overly complicated to display every option and configuration so you end up with bloated code or unintended issues. Having a good understanding of what you're working with is invaluable and any time investment early on pays off tenfold in the time you won't have to invest puzzling things out later.

The longer I work at my desk and in my garage, the more similarities I notice between my occupation and my hobby. My desk is just a less dirty, air conditioned, faster paced workshop where I work on building a different kind of digital machine. As time has progressed, there have been many lessons that have transferred from garage to desk but also from desk to garage. The key to being good at either is continuous learning to make your job as fluid as possible, with a process as efficient and well-organized as possible.