There's a difference between writing code and writing good code. It is essential to make sure your code is readable and understandable to you, your team and even to an outsider who happens to look at it. Here are some programming practices to consider:
Comments may sound trivial, and it may get boring to write them down, but they are helpful. Comments especially come in handy in group projects. It will help you and others remember what a section of code does. It will also increase overall readability. Instead of using comments to comment out sections of code, try using them to say what the code does instead.
Use The Right Editor
Notepad is hated for the correct reasons. If you're going to write code, you might as well do it in a proper piece of software. The right editor will provide better readability and debugging options. Consider options like VS Code, Vim, Atom, Notepad++ and Sublime.
Commit Changes, Always
You never know what could happen. Your system could crash and you could lose all your work. Consider using Github to get your code to online storage. And always try to commit your changes. Once you have done a task and you have something that works without any flaws, commit it.
Naming and declaring variables may sound like an easy task, but it actually isn't. You could spend minutes trying to figure out the perfect variable name to use. Avoid names like var1, var2 etc and instead got more descriptive variables. Using descriptive variables is kind of like "self-documenting".
One can go through the code and immediately understand what each variable is for. Understandably, there are times when description for variables can get long and tedious. Always try to get it as short and as descriptive as possible.
Documenting your work is the dreaded task. But you have to do it. Or you should do it. Self-documentation is sometimes adequate, where you can explain everything your code does use comments in the code and descriptive variables. Documentation isn't all about this. Sometimes, you have to pull up a different file to explain system requirements, design etc.
It Works? Don't Touch It
Once your code compiles error-free, don't go around touching and experimenting with it. Or if you're going to do this, at least, save a copy of the error-free code first. You may think you're trying to make things better, but you could be doing the exact opposite. Don't go creating bugs when there are none. And in case you happen to spoil it, remember that you can always use "Ctrl + z".
This list is just the tip of the iceberg. There exist other practices which senior programmers will consider ideal. And the above tips will be said to be unnecessary by some people. Everyone is entitled to their own opinions. No one is obliged to follow rules like commenting, descriptive variables and whatnots. But once you start following them, you start to see how much easier coding can get.