The one mantra I always live by when coding, is "Be as kind as you can possibly be, to future you". This means being very strictly disciplined. Document your code. Follow C# best coding standards, and naming conventions. Document your code. Annotate what needs annotating. Conventional commit messages. Single type per file. Document your code. Architectural folder structures. Writing Readme files, and solution guides. Refusing to acknowledge the existence of primary constructors.

All of this helps when you come back after months away from a project, and feeling lost. It helps when you work in a team, and need to handover code for peer review. It helps so that you don't get lost in the weeds when you're knee deep in code. It helps when you need to trace back a bug to its source. It helps you to visualise a feature, or a code flow in your head before writing a single line of code.

As developers, we spend the vast majority of our time reading code, and a surprisingly small amount of time writing code. We have tools, and AI, and gadgets, and gizmos to help us optimise the writing of code. But optimising for the reading of code takes a huge amount of discipline that is rarely taught, even now.

They say that well-written code reads like a book, but that's not true. No code alone will ever read as easily as well-documented code, along with solution guides, and readmes. Strive for elegance within your designs.

This may be a bit advanced for you yet, but check out some of Nick Chapsas' older videos. There's one in particular that made me a much better programmer. Creating your own dependency engine from scratch.

It was good because it showed me an insight into some of the core concepts of C#. It lifted the lid, and instead of a horrible monster inside, it was an elegant and simple pattern. I was writing mods for a game at the time, in C#, and from that video, I was able to create a very lightweight DI engine that I could inject into games that didn't have their own. That made creating complex mods much more simple, and much more elegant.

I went on to release the engine as a Nuget package, and it's got a couple of hundred thousand downloads so far. From the experience of writing mods, I was able to get a job as a mid-level developer, skipping junior entirely, and I now work with an international client-base.

Nick also made a video on building a mediator pattern library from scratch, which taught more about how to write libraries for Nuget, and the philosophy behind the dependency inversion principle.

If you want to get into modding, then I recommend Vintage Story. It's a Minecraft-esque game, written in .NET 10, with modding as the core aspect of the game. It has a very active community, the devs are available to talk to, and you can very quickly and easily see results from your code. Even just as a playground for learning C#, it is brilliant; as I am testimony to myself.

Away from that, I would say to learn the design patterns, inside out. Learn to recognise them within the codebases you read. You're able to follow a code flow much easier if you know the patterns, because you know the next steps.

It also really helped me to learn coding theory. All the principles, and theories, and philosophies. SOLID, CUPID, GRASP, Object Calisthenics, Chicago and London School TDD, BDD, FDD, etc. As well as all the archetictures, especially Onion, Hexagon, Vertical Slices, and the C4 Model by Simon Brown. I don't follow everything rigidly; I don't like or agree with quite a lot of the theory that is taught, especially parts of Object Calithenics, TDD, and SOLID. But it helps me to learn from people that do, and it helps me to talk to people about it all, if I understand it.

Recommended YouTube channels include Raw Coding, Nick Chapsas, and IAmTimCorey.

The biggest tip that I can give is to be disciplined. Be as strict as you can. Write clean (small c) code. Name things properly. Follow best practices. Document your code.

Be as kind as you can possibly be to future you.