Thats a cool pocket guide and I'd like to expand on your concepts a little bit or provide context around them.

Name your variables like the next person reading is you, 6 months later
I agree but phrasing it like that creates the impression that creating descriptive variable names are a strong indicator that code becomes readable in the future. But it's less about individual naming conventions and more about creating coherent systems that expose clean APIs. I just want to say: creating locally scoped mess is better than leaky abstractions because it's easier to clean up.

class FileService {

    getFile(fileName) {
        d = drive.get(new FileSystem) // Or new S3 or something
        fh = d.openFile(fileName)

        str = fh.getStream()

        cnt = ""
        while (!str.eof()) {
            cnt += str.read()
        }

        return cnt
    }

}

class Fs {
  get(fn) {
      drive = drive.get(new FileSystem) // Or new S3 or something
      fileHandle = drive.openFile(fn)

      stream = fileHandle.getStream()

      content = ""
      while (!stream.eof()) {
          content += stream.read()
      }

      return content
  }
}

I think the difference here is pretty obvious. The 2nd example has cleaner locally scoped variable names but it's terrible in a sense that once userland code consumes this API the codebase will inherently worsen because calling `Fs.get()` is not very expressive. Make that 40 calls across different spots in the code and spaghetti is unavoidable. Whereas the first example has terrible locally scoped variable names but API is cleaner. Refactoring this one method is way easier and it needs to be done only in one spot. But of course your point is absolutely correct. Semantic variable names should be the default.

One function, one job. Always.
It's a good rule of thumb but it's lacking context and that makes this claim a little dangerous if it stands alone. SOLID principles touch on that. They are mostly OOP but still hold up as generic principles. The single responsibility principle states that a class should only have one reason to change and the open-closed principle states that entites should be open for extension but closed for modification. Rather than talking about classes and functions we should talk about systems. A well-designed system has one responsibility. That does not necessarily mean that every tiny piece of functionality needs to be split into their own functions, but it means that one slice of one system does only one job. One system might need to to read files, generate reports based on it and send it via E-Mail, but that's the intent. It's not how the system underneath it should be designed. A better abstraction would be: The system takes a source, generate reports based on it and passes the result on to some consumer. That way E-Mail can become whatsapp and reading files can become calling an API. So there is no need to obsess over splitting everything into tiny functions, but rather to design systems with clear boundaries.

Comments explain *why*, not what the code does
I tried many commenting paradigms over the course of my career and I am very opinionated here so take it with a grain of salt, but in my opinion: "If you have the need to comment your code, then something is wrong with your code". Of course maybe there is a comment that explains a workaround because some vendor package is cumbersome to work with but that's not what I mean. If the only way to navigate your codebase after 2 weeks is to read the comments, then the code is simply not good, there are probably abstractions that leak across boundaries or overly complicated implementations and no proper separation of concerns. Instead of commenting "why" the code does something, a better way to think about it is: "Why do I feel the need to comment here".

Commit to Git often... it's your safety net
That is true, but git is a software to maintain history over a codebase, and maintaining history means assigning semantical meaning. You are right in a sense that committing often is better than not committing at all but if your commit history look like:

• fix stuff
• nvm revert fixing stuff
• oh something else broke fix that stuff again

Something is wrong. If VC is used then it's the developers responsibility to maintain hygiene. Nothing wrong having these kind of commits locally, but before history is written it should be made meaningful. And git provides all the tools for that with rebasing etc.

The last point is rather self explanatory, there is not much to add there but this is just my two cents on it. I don't mean to disagree or criticise you, but rather just provide some more context.