First of all, thanks to everyone contribution.
I also found @swyx
's Learn In Public (NYC) article and Learn in Public - React Knowledgeable video that offer additional and even broader cues.
A futher interesting reading is @oieeaaaa 's Why do you code? In fact, this would be my next question :D
I recently commented on What are you learning?, but I quickly realized (after the first five characters) that my comment is more about the how than the what.
At times, to learn certain topics can feel as a pretty boring duty. Consequently I chose creative/generative coding (an activity that appeals to me) as booster. I currently adopted a somewhat chaotic, eclectic (broader?) routine.
As part of this routine, and when possible, I often take a working code in some other language to translate it, iteratively "improving" and when possible, learning how original features could be translated too, as Python zip, range functions to ES (vulgo JavaScript).
Not sure how it could work in a medium or long term, so far it is pretty funny and efficient for me.
So, I have to ask now:
How do you learn?
Any suggestion, hint, tip (!) will be very welcome. And good learning to everyone :D
Top comments (22)
I learn by doing. If I hear about something, like GatsbyJS, I open the docs, download the starter template and build something. That's what I did for my portfolio site.
This method might not work for everyone, but it works best for me.
I'm the same way, I can't do that thing where people read the whole docs first, and then doing. I need to get my hands dirty!
I think everyone has a different way to learn, but I think forcing yourself to do something is the best way, for example getting an internship or a part time job doing something new will force you to learn or fail... most likely learn.
By doing, you mean things that you are interested in, right?
Yeah. If I want to learn something, I just start by taking a glance at the docs and then just doing it.
It makes sense, indeed. That's very effective.
This is an invaluable list. Third point is something that I did in school, but I definitely avoid most of the time nowadays. Very good catch, thank you.
In the list, i forgot to say that i write all titles to see what's available, and to use them to write pseudo-code, and then i dig deeper into docs for details. Another point, in my opinion, is to ask myself on what type of data do i work, to see if the operation i want to do already exists in a built-in class, or if i have to compose with them to write my own method.
Finally, when you make a mistake, the compiler talks to you and gives you a lesson, not a fail...
I had it this morning : to provide a consequent portfolio, you might be consistent by filling the github's dashboard's cases to green; no matter the colour of tone.
I should definitely try it... please keep me posted on your experience with this.
I tend to learn via a lot of immersion, basically ongoing casual learning by reading a lot of DEV content.
And then I tend to go deepest by identifying a specific need for the new thing I'm learning and then motivation takes it from there. I tend to focus best when I'm deeply motivated and the rest kind of takes care of itself. Lots of Googling. Somethings that "specific need" is driven by necessity, but sometimes it's sort of manufactured. Like, I find a way to need it because I'm interested.
I used to do a lot of podcasts for breadth but I've essentially replaced it by hanging around DEV (with some podcasts here and there).
I am especially interested to the
manufacturingconcept, finding a way to need it, part. How do you balance this component? Letting it to roll, "discipline", shaping priorities, ...?I used to have a harder time with discipline and distractions before starting DEV. Now my time is pretty filled up and I like what I'm doing that I get tired pretty quickly with new things that aren't obviously helpful.
But sometimes I need to kick myself out of that and be more exploratory. Usually this is when we need to shift to a new approach as a company, but I need to learn more before I can have an opinion. In this case I don't know we need the new tech or concept, so I kind of pretend we do. That's the manufactured need I guess.
I think the big take away is knowing your own motivations and what trips you up and learning how to play the right games with yourself to get down to actual learning.
Thank you, your last sentence is extremely relevant. That's when things flow :)
EDIT:
As an aside, it already happened that the
manufactured needended up clashing withcompanyneeds?I read blogs during my lunch breaks, usually it's something specific like SOLID Principles.
I'll be using DEV from now on 😉
Then when I get home I search for videos on YouTube and watch someone explain the same thing I read that day.
Afterwards I try and put it into practise or think where it might be used. Whether in an old project or while directly working on something.
If I understand well, you start with an iterative, onion like, process: to approach a topic from different points of view and media, then applying it in practice. Is that right?
That's right! Also from various pod casts while driving to/from work/gym.
I learn by getting my hands dirty and reading about other's experiences, like here on DEV or what's going on in my Twitter feed.
But another area I've found that I've learned quite a lot is by helping others. I got into Vue a few years back in its infancy and have found myself pretty active on the forum helping other devs that get tripped up. Sometimes I know the solution immediately, but other times I need to dig into it a bit which has definitely helped me learn how to debug things quite effectively.
Thank you, to help/teach is one of the best ways to fill our on gaps.
Started to play it and forgot to check here :D That's
learning having fun:)I learn by doing, but to really make sure I retained the knowledge I try to teach/explain it to someone else.
To bounce ideas is a nice strategy. And Caffeine-Zombies is cool game :)