Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
I 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 -
@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? -
@StopWastingTime
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. -
@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. -
As 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.
-
Depends. 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.
my issues with self learning .
Me : hmm so i want to make X. how can I make X?
*searches Internet. finds 15 min video title "Building X tutorial" *
tutorial guy : "Hey guys today we are going to make X. let's start. so here is this code a.b.c(d) . This will make X for you. Ok Bye "
Me: *tries his code* Hmm cool, it works. I got X . So let's guess what his code does ..
hmm so i think 'a' does this_thing. let me check. oh yeah my guess was right.
so let's go with 'b' .. hmm ok this does this_another_thing i guess . oh yeah it works.
...
"Yes i know how to make X, yay!"
----------------------------------------------
But this approach of finding the correct code and then guessing what it does does not always help me . i make presumptions based on a limited number of tests and they might not cover all the functions of a particular code.
thus there are chances that what *i* think a particular code does is completely different from what the code is supposed to do, under different circumstances. I constantly need someone to validate my assumptions and definitions.
So any other approach to learning that you devs could suggest?
rant