Debug Yourself Through®

Backing up is like investing

The quote above is from this article on the Backblaze blog.

It stuck with me because I’ve been a very poor investor. Not anymore! I need a backup solution and I’m looking to learn more about the process.

While working on this, I caught myself thinking about the process I have been using for the past 5 years. I realized I never wrote about it and I would love to share it with the world.

So in this article, I decided to share the process I use when researching and learning new concepts.

To be honest, I am quite ignorant. Especially when it comes to my work. But I’m doing it on purpose.

This ignorance helped me expand and step out of my comfort zone many times, throughout the years.

For example:

The client needed automated development environments?

— Let’s use Docker — only knew the name and the fact that containers were becoming a “thing”.

Another client wanted to revamp their UI?

— We’ll do it in React!

A different client wanted to improve their backend application — which was bananas, by the way.

— Let’s do micro-services, use a message bus and run everything in the cloud using Docker.

You might think to yourself: “I hope nobody ever works with you! You’re a menace to people’s businesses!”. You might even be right, thinking about that. Probably, there are consultants who walked this path, before but because they lacked core, underlying principles, they failed miserably and in the process endangered the client’s business.

Let me make myself clear, here. What I did is propose to them those solutions. The decisions were made with the client and their teams’ approval.

Here’s something for you to tweet / share:

If technology adoption is a team effort, it should also be a team decision!

Back to the ignorance. For all the situations outlined above, I had little to no experience with those technologies.

But I have two pillars I relied on:

• My willingness to learn and my resilience to change. These two personality traits were an immense help throughout my career.
• The Internet’s power to give me the information I need.

I base all the knowledge and experience I have to date on these two pillars.

You’re a debugger

When I was thinking about writing this article I didn’t have a name for the “technique”. The name came up while I was writing it.

I called it Debug Yourself Through®.

So here is the process:

1. Observe the error.
2. Admit that it’s a bug and not a feature request.
   • If you work in software development, you probably know the never-ending discussion of bugs vs. feature requests.
   • This helps you take ownership of the problem so you can figure out the steps to take to solve it.
3. Set an initial breakpoint.
   • In short, you fiddle with “the code” until you figure out where the problem bubbles up. This helps you with the initial evaluation of the problem.
4. Add a new breakpoint to the piece of code you want to reach.
5. Work on the problem and try to solve it to the best of your knowledge. This is where StackOverflow and other resources come in.
6. Hit refresh and check if the code hits the second breakpoint.
7. Go Red-Green-Refactor.
   • Cycle through steps #4 — #6 and refine your implementation.
   • Remember, you’re looking for good enough, not perfect. Know when to stop and move on.

Let’s take an example:

1. Observe the error

My computer failed me and I have no backup. I lost work and personal files.

2. Admit it’s a bug

I don’t have a proper backup in place and unfortunately I rely solely on Git for my “backups”. After all, I only write code, GitHub is an OK place to back it up.

There’s no reason for me not to have a backup. As a professional software development consultant, my work is critical both to me and my clients. Backup should be there. It is MISSING.

It’s a bug!

3. Set an initial breakpoint

Play back everything that happened up to the point I’m currently at.

I turned on automatic updates for my Mac. Apple has been pestering me for a week to accept an update and restart my computer. I delayed it because I had work to do and wasn’t in the mood to restart my computer.

I let that update go through but never took the time to see the outcome. After the restart took place, I closed the lid immediately after the install process finished and I was redirected to the login screen.

Opened the lid 6 hours later to find myself in front of a macOS install screen complaining about a missing OSInstall.mpkg.

Welcome to the new reality. I’m locked out of my laptop and to top it off, my “R” key stopped working. Cannot login / decrypt my hard drive to access my files. Can’t get through the install process without formatting.

4. Add a new breakpoint

I need backup. Fast! This is where I need to go next so I start gathering information. I create a note and add links about backup strategies, backup providers and generic backup information. Then, I look for techniques specific to backing up Apple computers, information about whether or not Time Machine backups are worth it.

I will need a cloud backup because at the moment I don’t have any backup-suitable hard drive or anything of that matter.

5. Work on the problem

I start learning all I can about the backup process, services available, I do cost calculations, feature comparisons and everything in-between. Then, I try to reverse-engineer the process and figure out the parts I didn’t get right the first time.

6. Hit refresh

I commit to a set of emergency, contingency measures, that would keep me safe starting as soon as possible. I install Backblaze, I start backing up the important files. I try to see which areas of the computer are not backed up. I can already see that my home folder is not backed up. This means that my SSH keys are still on my machine, as well as various dotfiles.

7. Red-Green-Refactor

I take the knowledge I already have and the articles I haven’t had the time to go through and try to get more advanced information from them. I use my existing knowledge to evaluate whatever comes through the system at this point.

I go back to step #4 and set a new breakpoint. Now I need hardware backups. Full system backups, to be precise.

I learned about the 3-2-1 backup strategy on the Backblaze blog and I’d like to expand on that. Time for refactoring.

So this is it, my 7-step process for problem solving. I truly hope people find this useful and if you need any clarification, get in touch through the comments or by tweeting at me — @oprearocks.

Cheers!