Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
SortOfTested24540296dI just read books and docs and experiment. I don't think I've ever been able to sit through a video on code.
- open the book
- go to a section
- try out a concept in isolation
- try out the concept in integration
- if you don't feel like you understand it, try and explore it from a different perspective
- once you firmly have the concept, move to the next section in the book
Basically math proofing
molaram3750296dI can't help but add that most video and blog tutorials are click whoring or SEO garbage.
curioustools5822296d@SortOfTested @M1sf3t nice suggestions. But do you guys always does this for every new X you want to create?
I also try to refer docs or a book at first,but i find them too broad of an explanation to my needs. They will try to explain the framework/tool in great details, but i will end up taking 5x time trying to understand everything and then create X.
So taking huge time to create X but with a deep understanding, or
quickly creating X but with a shallow/guess based understanding , do you always pick the first approach?
molaram3750296d@StopWastingTime doing some small feature without wasting time with docs: priceless. For everything else, RTFM.
Yes, I always engage in bottom up learning. I don't accept magic. Magic inevitably leads to technical debt and poor decisions that may achieve an ouput faster, but will have multiplicative penalties in terms of future effort.
The key is to identify a contextual bottom of the problem domain. If I'm learning dotnet, I start by learning framework concepts, then I stack a language, variables, memory management, structures, abstractions, etc, then frameworks.
Carl Sagan would say in order to make an apple pie, you must first create the universe. That's a bit hyperbolic, but the point is that everything starts somewhere. Learn to identify the root of the problem domain and your study will be significantly expedited as the concepts will naturally flow together one to the next.
Fast-Nop33948296d@StopWastingTime I'm doing a mixture of both. Like from "WTF is this even? How is it supposed to basically work?", going to docs, getting the idea, and then going to code examples.
Or, if it's about something that exists and does what I want, then I care more about how to interface it properly than about the inner workings.
I hate videos in general and prefer written text. Well written blogs and such are great for explaining high level concepts, but rather not for implementation details.
EdoPhoenix1866296dAs everybody else above mentioned, videos are a waste of time(most of the time) read documentation, look at open source projects that use a similar build chain etc. If you want to know about hidden or complex obscure blogs of other devs and rare gems like redblobgames.com are your primary source, although they need some searching.
IntrusionCM6369296dDepends. I hate learning per se, but what you describe sounds more like problem analysis.
X in your case could be anything.
From basic iteration to more complex stuff like dependent async execution (very uncreative atm).
It's valid to make assumptions, when you don't know what's happening.
Write them down. Get the whole picture.
Then tear them apart like misfit said. Find out what it does exactly and how your assumptions were wrong or right.
Rinse and repeat.
The only wrong thing you can do is stop asking questions or accepting a solution without understanding it.