Tags→#workflow
Review your own PRs
I wrote in a (student) newspaper once. I bet I wrote ~10 typos per page. 9 of which I caught on my own review. Similarly, most bugs I write are apparent to myself when I review the code. It's like it's two different brain modes: producer and reviewer.
Build for today. Only today
I often add a field, model or endpoint that I need 'tomorrow'. When 'tomorrow' finally shows up, it's usually not quite what I need. Note to self: Stop building for tomorrow. Stop build it 100% complete. Stop over-generalizing to fit future scenarios.
Don't abbreviate variable names
Variable name: don't make them short and cryptic – let them be as long as they really are. Sidenote: Subscribe to that channel, it's great.
Don't write comments
There is a consistent way of describing how a program should work, it is called writing code. Writing comments that describe how code work is usually an excuse for writing bad code. Exceptions: documentation/issue links, and sometimes bad code is required.
Test "commit driven development"
Writing smaller commits is a constant practice that I feel often pays off. The Primeagen's reflections on the topic is worth seeing (from 11:16, earlier parts are so so). Challenge: for your next feature, write commit messages first!