0/ Work with other developers, ideally next to them, on the same project. Learn from them no matter you think them "good" or "bad".
1/ When given the choice between making something exist and making it not exist, lean toward the latter. ie. Minimize Everything. Remove everything that can be. Things must earn their right to exist.
2/ Choose the best names you can come up with. If you can't find a good name for something, there is a chance it shouldn't exist. There are books about this.
3/ Code should enable things, not be a problem itself. Make it the easiest to maintain and understand above all other criterion. Code like you have an audience that will be reading that code while not really caring regardless. You can't expect the maintainer to care as much as the writer, it would be impolite to do so.
4/ Think a lot about what things should be splitted in two concepts, and what concepts should be merged into one. Iterate designs until they seem impossible to enhance. If it feels wrong it is probably wrong.
5/ Recognize your weak parts and improve them, not only those that are good already.
6/ Don't confuse input errors and bugs.
7/ Create the right abstractions if necessary and at the right level. Lean toward "no abstraction" if you're unsure of the best design yet.
8/ Forget everything systematically. If you need to remember something, find a way not to have to. You need all your neurons to learn new things constantly.
9/ For the hasty: work on legacy systems. This is the "hardcore difficulty" level of programming. Do some parsers.
10/ Don't give a name and reify everything, in fear it would become a topic of mental activity. Example: since users will report the biggest problems the most, maybe there is no need to record every last user wish. If a task is faster than to record it in the todo-list, make it right away, etc.
This was definitely the most influential experience of my software career. Being one of 5 devs that maintained a 5 million LOC montrosity was a hell of an education.
I use sub-TODO lists with thematic stuff (ie. freelancing-related, related to this or that product, etc). Then I get to not see it which is really helpful.
A good TODO list doesn't have too many stuff in it, so why not hide parts of it.
Then each day wake up and think "I'll do all that very doable backlog today".
1/ When given the choice between making something exist and making it not exist, lean toward the latter. ie. Minimize Everything. Remove everything that can be. Things must earn their right to exist.
2/ Choose the best names you can come up with. If you can't find a good name for something, there is a chance it shouldn't exist. There are books about this.
3/ Code should enable things, not be a problem itself. Make it the easiest to maintain and understand above all other criterion. Code like you have an audience that will be reading that code while not really caring regardless. You can't expect the maintainer to care as much as the writer, it would be impolite to do so.
4/ Think a lot about what things should be splitted in two concepts, and what concepts should be merged into one. Iterate designs until they seem impossible to enhance. If it feels wrong it is probably wrong.
5/ Recognize your weak parts and improve them, not only those that are good already.
6/ Don't confuse input errors and bugs.
7/ Create the right abstractions if necessary and at the right level. Lean toward "no abstraction" if you're unsure of the best design yet.
8/ Forget everything systematically. If you need to remember something, find a way not to have to. You need all your neurons to learn new things constantly.
9/ For the hasty: work on legacy systems. This is the "hardcore difficulty" level of programming. Do some parsers.
10/ Don't give a name and reify everything, in fear it would become a topic of mental activity. Example: since users will report the biggest problems the most, maybe there is no need to record every last user wish. If a task is faster than to record it in the todo-list, make it right away, etc.