Programming rules/suggestions to live by

1.  whenever I see nested loops I weep for the performance of the code
2. beware anyone that says they have a quality MR/PR but can't explain what it is that their code does - 9 times out of 10 it has been written for them by AI and 9 times out of 10 it's wrong for the codebase for some reason.
3. write code with the intention that it is going to be read a lot, if it's easy to understand I can almost guarantee it'll get used unaltered forever so leave your mark.  If it's written in such a way that no one understands it then be prepared for it to be re-written or removed by the next eager developer keen to leave their mark.
4. code that's not thoroughly tested isn't a solution to a problem, it's a suggestion of a solution - test, test, test, then give it to someone that loves destroying things and let them test
5. user experience is everything, I am sure your multimillion dollar company has given you the best kit to work with, guess what, your customers might not have budget for that so make sure you see what it looks like on a less spectacular screen and less powerful set up, getting it right for the many is worth more than pandering to the few spoilt little rich kids.
6. you don't know more than the just in time compiler, stop trying to second guess what it will do and optimise your code in such a way that makes it unreadable in the hope that performance will be better, most of the time it won't be and if you can't write it to be both understandable and  performant then chances are your fundamental algorithm needs further thought.
7. understand your problem domain, this is so fundamental that I can't believe it needs to be said but oh so many times the wrong problem is addressed.  Rory Sutherland has plenty of examples of this (https://www.youtube.com/results?search_query=Rory+Sutherland) for example spend millions or even billions making a train journey about 10 mins shorter rather than spend less money and make the train journey pleasurable, the issue wasn't the time taken it was the fact the time spent was detested so address that fact.
8.  just because some code is old doesn't mean it needs to be replaced, also because some code is old doesn't mean it shouldn't be replaced.  Old code can and does still do the job perfectly adequately, don't waste your time fixing a problem that doesn't exist.  Likewise as new innovations are made around code and libraries that some old code uses can lead to the old code being sub-optimal or insecure so definitely needs replacing you need to be able to recognise both scenarios
9. the term best practice is terrible, it implies that whatever practice is being used is the pinnacle ie best, and nothing can surpass it - this is bollocks - applying the term best practice to anything causes people to stop questioning it and simply dogmatically applying it and as with any practice time moves on and what was the best solution yesterday may be the worst solution today.  I really think this term needs to be consigned to the rubbish bin.
10. you're not a guru, you're not a genius, you're not a god to developer kind.  You will forever be learning as a developer, not just from those further along in their careers but also from the most junior of developers you can imagine, the difference is most probably that a junior won't realise they're educating you as they ask what may at first seem like naive questions.