Edit: you posted this under the topic of HTML/CSS.
HTML and CSS are just markup/styling sheets, they aren’t real programming languages. Javascript is where the meat and potatoes are and that could be why you’re struggling right now. With CSS there is no logic, either you know what to write or you don’t. I recommend switching to his course on Javascript first because that’ll put HTML/CSS into context and may make it easier to learn.
::::::::::::::::::::::::::::::
A great skill to learn is google-fu. There is no shame in googling your way to success and using someone else’s solution, great engineers do this all the time. Instead of going straight back to mosh’s video, I’d recommend two things:
get pen and paper and really break down exactly what it is you’re trying to do, including all of the building blocks you think you’ll need, like ‘what are my inputs? My outputs? what functions will I need to make? What objects will I need to make? is there anything unique about my problem? which of mosh’s videos/concepts from those videos directly pertain to this problem (and do I need to rewatch them to jog my memory?) etc.’
Go through questions like these and make an inventory. Once you have all of these written in front of you, it’s much easier to set up your algorithm. Step one is to just write down in english what you think you’ll need to do ( example: 1st, import library x, 2nd, initialize variable Z, 3rd, I have to use Z to make A B and C, so I actually have to bring in Q as my third step, etc.).
Once that’s written out, rewrite this step-by-step into psuedocode. You’ll probably find that at this part that you’ll have reorder and/or rethink the steps you’ve made since you’re constrained by the syntax you know (example: if you don’t have an english wheel in your tool shed then you’ll need to bend your metal some other way, but you can still bend the metal with something else using different actions). If there’s code that you’re convinced you’ll need that you don’t know, then google-fu it and try and figure out how other people solved your problem before (or similar problems). This part teaches you how to read/debug the code of others, which is really what you’ll be doing in a programming job.
On the path to finding a solution, dig and dig until you get ‘aha!’ moments. Those are the moments you’ll remember later. Enough ‘Ahas!’ and congratulations you’ve solved the problem. I like to write down examples of their syntax in my notebook for quick reference later, although some people might think that’s overkill.
Once you’ve gotten at least a decent grasp of the pseudocode, then make your first draft. You’ll probably have bugs and that’s fine. The key is to google-fu like before and use stackOverflow and other resources (not Mosh’s example) to reverse engineer the logic of others to solve your problem.
Don’t give up!!! Only once you’ve made something working on your own should you go and see how mosh did it. Pay attention at this point why he did what he did, since he probably will have solved the problem more efficiently than you. Once again, try and write down with pen and paper take aways about his solution that you can use next time (and focus not just on ‘how/what’ but ‘why’). Maybe his code was cleaner because he seperated his concerns, maybe he used syntax that you forgot about that would’ve combined several of your steps into one. These ‘Oooohhh!’ moments only come if you’ve finished the problem on your own with your frankenstein code, and those ‘oh’ moments are a necessary part of self-learning.
