I've been in the software engineering business since the 1970s, I'm retired now but still find myself writing code. All the advice is SPOT-ON. But one bit of advice for Elsa, PLEASE buy a clip-on microphone ("Lavalier mic"). Or maybe just a mic stand.
I am learning to code because I have real life problems I want to solve. I personally prefer practicing with real life problems. I don't like building things for problems that have already been solved. For example building a calculator, task list, etc does not interest me.
*_"Coding Was HARD Until I Learned These 5 Things..."_* You haven't experienced yet how HARD it's going to be keeping your job with AI making huge steps.
Really good video, seriously I was ready to add something to the conversation, but seriously you covered all bases. And the number 1 tip is really the number 1 tip, DO STUFF, whenever I have to help someone with coding and I ask "what have you done so far" and the answer is nothing, there's little to nothing for me to help, I can't gauge how to help that person because it's impossible to know what they need helping with, and most of the time simply trying, getting it wrong and understanding why you got that wrong takes the person farther than if I sit down with them and explain exactly what they need to do. Awesome video!
Brilliant and absolutely true! As a person who has been a software engineer for 37 years and typed out millions of lines of code, I can confidently say that I use these 5 things every day.
Thank you! My mentor emphasizes the understanding of what is happening under the hood and will never give the answer, forcing me to figure it out through my own mistakes. This video is clearly an example of how to approach software engineering with the right mindset. I've learned so much from spending hours staring at my mistakes, drawing diagrams, scribbling on paper, just to teach my mind how to understand what is happening. And also thanks for the course info!
Great video. Conceptualizing the problem is something I wish I could rewind and burn into my brain. For anyone out there just learning - a simple example would be something like, "Imagine you have 10 friends and you need to give each of them a high five. Think about this like what you would do as a human, go one by one and high five them". That’s a for loop. Obviously to anyone who knows what they’re doing they know they can high five all people at once in a lot of cases but for getting started, just think about these things the way you would think about them normally without programming. What would you do? That’s it. Everything else is just syntax and research on how people have figured out the optimal way to do that thing (or if you’re super smart you come up with your own way and people name it after you). :)
My HTML language works on Android play store video plays. But on codpen on web dosent play video but but doesn't show any error ? This is my progress I am 3 days in learning from u RU-vid videos and copying and paste other HTML css java from internet into editor.
THIS!....Was Brilliant Elsa. Incredibly insightful and a must for any and everyone from beginner to advanced to always keep in mind from simple to enterprise tasks. Thanks again.
Good advice. I'd say that understanding at a systems level is also important, such as assembly, opcodes, utf-8, file headers, two's complement - they are the things that allow you to understand all the ones and zeros hexed up in GDB! Doing a few binary exploitation challenges on a site like picoctf is brilliant, it teaches you all the deeper stuff, and you get to understand why C is a memory unsafe language. When I came to learn Rust, which is considered a very difficult language, I found it quite easy because of all the knowledge I had built up at the systems level.
Languages are ultimately just tools and should not be the end goal. Depending on the problem you're solving, you choose the language, read the documentation, learn, and apply it. I believe developing problem-solving skills and approaches to problems is more important. Therefore, instead of focusing primarily on languages, you should first solidify the logic of "algorithms and programming." By algorithms, I don't mean just sorting algorithms, but rather the flow logic of the tasks within the desired software. With greetings and respect.
Absolutely valuable advices. This is something I needed from beginning. It took me ages running through tutorial hell and trying to make "todo lists" and such stuff, unable to work independently, because I sit and what now. So I sat again and ran again through tutorials. This year's spring I finally got a project. I am a bookworm and I often go through antique book shops searching for books no longer in sale in common book stores. I did it every day. One day it clicked - yes, I will automatize it! I was familiar with Python enough to code but not familiar with building. It was pain. Confusion. Hardships. I struggled a lot. But I finally learnt how to sit down, think of project, break into pieces, think of smaller pieces, implement pieces, test them, find flaws, take a day to think of this piece and redo it again and again. My project can schedule scraping, scrape shops, compose mails and provide me a mail with results - book, edition, issue, price, link. It finally works! First version sucked. One big messy file. Second version was more modular but with many mistakes and bad practices. This time I got feedback from experienced guys. I am finishing third version. I am almost done. I learnt many principles in my journey. Something I can sell at interview because I can talk about my project, about design problems I faced and why I chose this solution over another. I feel like I understand now. Alongside my project I try to learn golang and when I said to it, I did one day syntax overview, some practice, and now I am sitting and trying make my own TUI game just using my experience with building. I feel the difference. I can build whole project in pseudocode and now I face just the fact golang forces me to think of "pieces" differently, less OOP, but okay. But it is just fun for rest. I keep moving towards my main project.
Partly agree. Yes, being able to understand what you're doing - instead of grasping the syntax - is vital. After that, it's either looking up the syntax or working your way around it with what you *DO* got. Sure, a language may offer certain facilities, but implementing them yourself doesn't make you fail. A road map? I don't think so. You learn whatever life throws at you (aka what your work demands). Getting to the core of the problem is IMHO meeting half way. Better: learn what is under the hood. I wrote some reasonable good C in my time, but once I learned what (assembly) code C generates in certain situations helped me tremendously. Since then I've only worked with languages that I know the architecture of. It helps me to make much better code much faster.
Hello Dear I hope this message finds you well. I'm Emon, a professional digital marketer with a focus on RU-vid video SEO and Google Ads. Are you struggling with subscriber and video views for monetization? I wanted to reach out and share how my expertise can help enhance your RU-vid channel's visibility and drive more engagement. I was analysing your RU-vid channel
#2 is sooooooooooo important and missed by soooooooo many. Anyone asking me how to start I say learn C. That’s as fundamental as you get (outside assembly) and teaches you good development practices and why things in a computer work that way. Then, pick a language and go. Concepts are the same, syntax and implementation are the only difference.
Learning C: 1. Fire up your editor and start writing code; 2. Fails to compile; 3. Fails to link; 4. Get a SEGV; 5. Go back to 1; 6. Move to another platform; 7. Go back to 2.
