Recorded live on twitch, GET IN https://twitch.tv/ThePrimeagen Become a backend engineer. Its my favorite site https://boot.dev/?promo=PRIMEYT This is also the best way to support me is to support yourself becoming a better backend engineer. MY MAIN YT CHANNEL: Has well edited engineering videos https://youtube.com/ThePrimeagen Discord https://discord.gg/ThePrimeagen Have something for me to read or react to?: https://www.reddit.com/r/ThePrimeagenReact/ Kinesis Advantage 360: https://bit.ly/Prime-Kinesis Hey I am sponsored by Turso, an edge database. I think they are pretty neet. Give them a try for free and if you want you can get a decent amount off (the free tier is the best (better than planetscale or any other)) https://turso.tech/deeznuts
ADVERTISEMENT
1. Draw a circle 2. Draw the rest of the owl
"The master has failed more times than the beginner has even tried."
no struggle = no gains
How I learn programming is: - I want to build something - I learn about the thing I want to build and it’s surroundings - I try to find out how to build the things I need - I learn a ton of (at first) useless half-correct things along the way -I build the thing (or I fail to build it)
Can confirm. Throughout my school years, I learned more when my teachers made intentional mistakes and explain why doing that was a mistake
I studied programming for two years and didn’t understand. I learned better by looking at the end result. Then I broke each component of the architecture down to its simplest. Started with the end and worked my way to the start. Kind of like trying to build a tv for the first time by taking apart all the parts of the tv and understanding each component.
I think there's room for both. Showing a final result can give an idea of how a concept is supposed to work. It builds understanding but not skill. Just trying stuff until it works builds resilience and skill but if you don't understand why what you made works you're missing out. You might also keep doing stuff in inconvenient ways because your working in a way that's locally optimal but globally subpar. So I think there needs to be a split of 30% new concepts cleanly introduced and 70% unguided or lightly guided practice.
How I learned it is to do the step by step solution and then start figuring out what means what. And tweaking things try and adjust the solution to fit my current problem better. After a few of those you have a general understanding of how things work and when you do the proper way of learning then it's a lot faster. But this keeps my interest high
It’s important to see the final result when you are first learning. This is because when learning something new, most times you never understand the “why”. The end result gives you an answer to this “why”. Then when you dive into the code and learn more about the individual parts, the “how” becomes clear. Next thing you know you have a solid end to end knowledge of an application.
Why would I rebuild X?! Elon dominates the market, there is no way I could compete with him
So simple yet a deep philosophy
I still didn't see anyone else teach like Jeffrey Way from Laracasts. His approach is pure learning. He builds on the screencast the wrong version, shows you the error, then fixes it (kinda), shows you the way, and then improves the fix again. He is just brilliant.
There's a construction set called Meccano by the old toy company Hornby, this exact understanding was known to them at the time of construction (it's as old as 1898) where they would intentionally fudge the instructions with mistakes, so that the individual creations would become more unique. This concept is lost to time as people are hungrier and hungrier for learning but refuse to subject themselves to any failure or strife.
I know that prime speaks with an authorotative voice, but actually people have studied what works best. They've looked at high-schoolers learning to program (I think in the Netherlands), and split it up in three groups: - One was mainly focused on learning code through reading, i.e. they read code, discussed code, and then implemented new stuff. - One was mainly focused on writing code, i.e. the thing that is described here. A bit of guidance, but mostly trial-and-error - The third group was a mixed group with both, but still a large focus of intentional reading. When it came to performance in tests afterwards, the reading and mixed group were fairly close in performance, but the mixed group won out. The "mostly-trial-and-error" group did the worst of all. The conclusion of the study-authors was that too much emphasis is placed on writing of code, and trial-and-error, and too little of just reading comprehension. We need to do more stuff like "explain what this piece of code does in your own words?" and also things like "why does it have this bug?" "which method implements this?" "describe this function in your own words" I think, yeah, just following a tutorial is stupid. But reading, the "clean solution by a master" is something that is undervalued in programming courses all over the world!
2nd year of uni in cs, a HUGE majority of my learning is as follows: 1. Want to make a thing 2. In the simplest terms possible determine how that thing will work 3. Figure out how to make it work in code with previous knowledge or looking up how to do the operation that i need 4. Either do your best to rewrite and optimize the code or just upload to stackoverflow and get your code obliterated by everyone with a keyboard and wifi
One way to get understanding is through failure. You let reality tell you you're wrong over and over again until things start to work. And the hope is that things work because you understand what you did. Another way that I honestly think is better and almost never addressed is by starting with the right answer and trying to break it. You look at each step and think of all the ways you could do it differently and then see if they work or why they don't. Basically, you go backwards in an attempt to prove to yourself the "correct" version is actually correct.
This has an element of truth, but is dangerous to follow to an extreme conclusion. Throw them in the deep end, sure, but make sure they have working arms and legs first. The first method is great for getting up to speed on specifics when you know what you're doing generally, the second builds character - but only if you have those basics down first. You have to build up both parts of your personality, passive and active motivation and perception.
Honestly programming is pretty easy when you realize all that needs to be done is learn the core logic : If statement For loop While loop Switch case Methods Classes Polymorphism Inheritance Objects Etc. (Learn about scanners in languages like Java to apply this or use game engines for interface in the beginning) And if you want algorithms things like : Bubble sort Quick sort Selection sort Etc. Data structures : > Linear (start here) : LinkedLists, Stacks, Queues > Nonlinear : Binary search trees (BST), heaps, etc. After this you can program many things, from video games to small and basic software applications. _Utilize AI btw, ask AI to write you what you should learn step by step starting from logic statements -> Algorithms -> Data Structures -> and beyond depending on what you want to program for. I didn’t list everything here, so use AI to fill in the gaps for a comprehensive lesson plan. Make sure however you’re NOT using AI to code, just showing you a lesson plan for you to self study. Really understand these concepts and write it all down_
I agree 100%. Most learning comes from making assumptions about a system and doing things that rely those assumptions, and looking back at those assumptions to reasess your understanding until you stop failing. True understanding does not come from memorisation but from making assumptions and repeatedly interrogating them until your understanding grows to account for most nuances and edge cases
I usually do this: - Have an idea - Research what tools I'll need to realize this idea - Learn the tools - Start and finish the project using the tools and sometimes learn / switch to new tools