Sometimes the obvious escapes us. The suggestion to save your work often and habitually is one of those apparent recommendations. It is a newer phenomenon as we have to worry about data loss through various means. Likewise, we have a virtual workplace, and the idea of our work not being done until it is committed is new. The latest generations may not see it that way, but “us old folks” do. There was no need to “save your work” on a typewriter or a written journal. When you performed an action, it was done. The idea of saving or committing our work is a new challenge.
Save Your Work – Avoid Loss
First and foremost, we must consider saving our work before an application dies or power is interrupted. While these occurrences are not necessarily typical, they are destructive when we fail to save early and often. We also might run into a situation where we thought our work was done and saved, but it was not. That can be frustrating when you send a partial document in an email or cause a loss of valuable time when debugging old source code. When in doubt, just hit save again. The time you save may be your own.
The Lesson Learned
I am not sure how many people are surprised that save your work rose to the top suggestion for debugging. While this is often a technical and complex task, it also has simple facets. That is a lesson in itself. We can overthink problems and skip right past the simplest solution. Often that simple step gets us to our solution quickly and easily. However, we must accept that sometimes we make silly mistakes, or human error enters the equation. Next time you are perplexed by a problem, step back to square one and ensure you save your work first.
If you like this season, you will probably like Scott Adams’ book, “How to Fail at Almost Everything and Still Win Big: Kind of the Story of My Life.”
