One lesson that I never seem to learn, is to follow the framework. As I've learned coding by myself, I've taught myself to think and develop architecture to fit the purpose. It has been quite a few times that I solved a problem and later found out that these were established patterns.
Having the ability to develop patterns, means that I am likely to use it to solve my problems. This sometimes can conflict with frameworks, as they have intended patterns for you to use, and there's no need to solve those things yourself. But the paradox of a good framework, is that it obfuscates the work it is doing for you, making it harder for you to see what exactly it solves, and why it wants you to follow those patterns.
I'm telling you this, as I've found myself staying away from Unity DOTS, finding it just so very hard to use. The documentation is really lacking opinion, leaving it up to you to figure out why you ever would use more than one type of scheduling and how you should structure your data. And both really matter, as it interacts with how DOTS does things under the hood. So I decided to stay away from it and just use burst and jobs to work on a turn based game.
What I've come to realize in working with burst, is that burst requires very flat data structures. And when I needed more complex data structures for the games I was trying to make, I needed to group some of these flat pieces of data together, to create those more complex structures... And I found myself moving towards an ECS based pattern, all on my own. At that point, why not just use DOTS?
And so I did, and now I could work with the framework. But a lot more had changed, as DOTS had matured in the meantime. Tutorials had sprung up and major problems like animation were solved. Support for DOTS had arrived. And now I find myself having fun again while working on my game projects.
And since I also have the resolution to publish more frequently about my progress. Stay tuned for updates on the game that I have decided to release this year.