One summer semester of my film degree, I took a class called Advanced Digital Post-production. Because it was a four-week summer course, our instructor condensed a lot of, well, advanced skills to learn into four total projects--one per week, with the whole week to brainstorm as a group and attempt to solve a problem through trial and error. And believe me, most of the time there was a lot of error and mostly scratching our heads wondering what on Earth we could try next.
To run a class like this efficiently, and to make sure we were learning not only the skills and software we needed to learn during the course, our instructor also made sure to teach us a crucial habit for trial-and-error problem solving: logging. Every student in the class had a notebook that we wrote down every step we took when doing anything for the class, whether those steps ended up being totally left field or ended up leading to the right solution. We were graded not only on figuring out the right answer in the end, but in how detailed we kept our notes throughout the process.
Since then, it's been a habit I've sometimes kept up, and sometimes forgotten about. In lieu of writing things down, especially while writing CSS, I end up saving and refreshing files every few seconds or so, previewing every minute change I make and hitting undo immediately if something went wrong. But other times, logging is important. I can't count how many times I'd return to a project weeks or months later and wonder what line of code I'd been working on, or how I finally made such-and-such mysterious element line up correctly after all.
But worse than any of my own mistakes are the mistakes made when working in a team. A lot of times, finding out what's going on when there's a problem one person can't solve isn't that hard with CSS and HTML. They're pretty simple languages, and even when things do get complicated, if you're familiar enough with them you can use the "Inspect Element" menu in most browsers to find the culprit of any styling gone wonky. But when you're not working with something that simple, or still new to it, relying on that isn't so great. And inevitably you end up sending an email that says, "I don't know what happened but now the site looks like this." Or worse, an email to the IT department with a note like, "I don't know what happened but I can't access the login screen."
A couple weeks ago when I created a dual-boot system on my iMac, I logged all of my steps just like in my film class. It wasn't super detailed this time, just shorthand notes on a Post-It notepad. But when I ran into problems, I knew exactly what to type into Google, and if anything went totally wrong, I'd know what steps led me to my problem and could easily give replicable directions to a support forum or one of the Apple Store Genius Bar staff. Fortunately, I managed to get through each obstacle with a simple Google search, achieved my goal, and still have about three copies of all of my data. And logging my steps gave me a detailed record of what lessons I learned for whenever I set out to do a similar project. You can see my a summary of my log here, along with a tutorial to do the same partition and upgrade that I did.
In sum? When working on a project, especially a technical project, write down each step you take, as detailed as you'll need to remember what you were doing. I also like to use this method to keep track what I did during a workday, and this semester, I am trying it out with the Bullet Journal system. This way at the end of the semester, I'll be able to see how long different projects took me to do, what notes I'll need to pass on to my successors, and perhaps what I could learn from or improve upon in the future. Without taking notes along the way, I might not remember everything, or remember it accurately, which doesn't offer a lot of room for improvement and efficiency in the future.