> Read the documentation on the Gameplay Framework. All of it!
Is it just me or is this an unviable learning strategy? My approach for learning anything has always been to follow small tutorials, build an intuition, and only consult docs when I need some specifics.
I think it's just different learning styles. My preference for learning e.g. a new programming language has always been to read a book cover to cover as the first step (if it's a language established enough to have a book anyway). Note that it's not important that I actually understand everything on this first pass. The cover to cover is mostly about getting the lay of the land so I know what exists, then, even years later when I have a problem that could be solved by using some bit of the language that I read about but didn't really understand but vaguely recall is a thing it springs to mind and I can do my deep dive on that aspect then.
I'm currently doing this with a few programming language books, and the strategy for me is basically to read the book in two passes. On the first pass, the goal is just to get through the whole thing and get a feel for everything it covers. If I don't understand it, that's okay— I just let it wash over me.
It's only on the second pass that I am trying to go through each section carefully and make sure I really understand before moving on, including seeking outside help or resources if I feel confused or stuck.
This feels fun for me, and the casual first pass makes it easy to figure out if a book or language truly appeals to me.
I also feel, strange as it sounds, like for me it save time compared to learning in small increments through tutorials. It lets me more quickly absorb the basics for things that are already more or less familiar, and then I can focus on exercises and examples only for the tricky stuff.
When I first started studying computer science, in high school, the biggest productivity gap was between the students who tried to work only with what they were directly taught in class by the teacher and the students who decided to go explore the language/stdlib API docs on their own. There was a lot of 'wow, how did you do that!?' from the former group and a lot of 'it's built in, check out this part of the manual' in response from the latter. But somehow no amount of exchanges like that could convince the former group to take some time to RTFM in a comprehensive or unguided way, so it stayed that way.
As someone who recently learned UE: yes, this is completely unviable. The UE API docs are almost useless. Use Rider and its code navigation instead, you'll get much better results.
The docs about the concepts are better, those are worth reading.
Your style will get you through a project, but you'll miss out on useful but nonessential features.
For example, a lot of C++ programmers miss the full spectrum of std::algorithm. A lot of Python+NumPy programmers miss out on some useful indexing tricks.
I'm still suffering from not taking a rigorous approach to unix shell.
Everybody is different. It's certainly unviable for some people.
For me, the ideal thing is a book, and great docs can feel like this. Something well thought out, comprehensive, deep, and importantly error checked/reviewed. The downside is books are increasingly rare and get outdated really quickly.
Yeah I agree. For me personally the best combination seems to be a quick start guide to get me bootstrapped and let me get the gun poinTed at my feet, and then solid normal documentation for me to mend my feet each time after I shoot myself.
Some of it is a matter of it being hard to even have the language to know how to ask the questions you have, so a bootstrap or quick start to let you just get in there and start looking around helps a ton and makes the full documentation a lot more accessible.
> follow small tutorials, build an intuition, and only consult docs when I need some specifics
While I basically tend to learn like this - (solve my current problem and move on, since I have limited time to spend on things) - I find that this type of learning can miss some things. Like when the documentation says this is important etc and you never know about it/find out about it the hard way when your stuff doesn't work properly.
depends. IME I tend to go through at least 3 passes of
- read high level architecture docs,
- try to do some small coding
- get confused and google until I get my goal done
- go back to reading high level architecture docs
You're (or at least, I will) never absorb and become productive in all that material in a first pass. But at the same time reading the intro for the mentality of how the big picture works helps a lot to scope into what to focus on.
It sounds more like an intermediate strategy, if you're eager to discover some tricks you missed. First do some small projects to familiarize yourself with the basics. Reading the API before really knowing the context of anything you're looking at seems fairly pointless to me.
Is it just me or is this an unviable learning strategy? My approach for learning anything has always been to follow small tutorials, build an intuition, and only consult docs when I need some specifics.