Problem on focusing on a learning path? Just do what Mohammad Ali did!
I have to admit that maintaining focus and motivation is hard. After a few effective days my energy is low, and I take a (too long) break, and then the momentum dies.
So I pick up another topic: pixel art, inhale, whatever - and for some time the momentum returns. Or maybe it's an entirely new momentum?
A big problem with the courses I use is that they're not really breakable into actionable chunks that would give me a sense of progress. Learning a game engine consists of big actionable blocks of chunks. nothing small.
Thinking about how to solve that reminded me of a somewhat funny approach. Imagine a person training something only to drop it in the middle to start something different, only to drop it in the middle to begin something different, and so on...
Sounds familiar?
Nope. That's not me (this time).
Meet your new productivity coach:
Mr Muhammad Ali.
He did not go with the flow of the blocked practice, which basically focuses on one learning material for a prolonged time.
Anecdotes are saying that he was unable to do more than 5 minutes of practice doing something that other boxers did for 20 minutes. His coach joked that in the gym he looked like “the world's worst boxer".
His way of learning was similar to what is called interleaved practice - which in Ali’s case meant jumping from one practice to the other.
How does this work in learning gamedev?
Instead of focusing on one path, I should jump around even more.
Not doing a course until it bores me. But jump off while I’m still at it.
And jump between all those topics I will need to learn anyway.
Will that help me maintain momentum? Maybe…
What I do think is that perhaps doing one thing daily is not as good. I get it - you have to show up. But what if showing up daily exhausts your energy?
It’s time for an experiment!
Which I will most probably divide even more.
Monday - Godot
Tuesday - Inkle
Wednesday - Pixel Art
Maybe, there is something like smart context switching?
If u dev in practical stages, u set up a minimum viable code to show that it's working then expand & reiterate w each test. The more frequent the tests, the less code u have to examine to determine the error. Your jump around method seems rife w errors that u will have a hard time tracking down.
I've heard of this before - the idea to stop doing something while it still interests you, which makes it more likely you'll look forward to picking it back up again.