I find a good approach to getting better at programming is to reflect on the projects you’ve done and try to identify patterns that got you into trouble. Then you can try doing things differently next time, and eventually you end up settling on a style that works for you. At the end of the day it’s really just practice. The one key thing I’ve learned to focus on is reducing the operating context I need to have when reading the code. Once the context becomes too big to keep in your head, then trouble starts. So breaking things up aggressively into small components you can reason about in isolation tends to be the best way to write reliable code you can maintain over time.
I find a good approach to getting better at programming is to reflect on the projects you’ve done and try to identify patterns that got you into trouble. Then you can try doing things differently next time, and eventually you end up settling on a style that works for you. At the end of the day it’s really just practice. The one key thing I’ve learned to focus on is reducing the operating context I need to have when reading the code. Once the context becomes too big to keep in your head, then trouble starts. So breaking things up aggressively into small components you can reason about in isolation tends to be the best way to write reliable code you can maintain over time.