0. Be logical and realise the machine code is only running the logic that you have programmed into that code which the program executes. If you understand all the concepts and fundamentals, even the most basic fundamentals, you will then be able to engage with AI to help you with your code, but you must know how to program first, so that you may ask AI to correct the errors that will present to ensure you’re actually a true programmer.
lol roadmap, make webpages, stay away from frameworks, stick with the basic fundamentals and innovate, work alongside with AI to create super cool pieces of software for web development purposes, perhaps even apps that align with the web development projects. Have fun. Re-invent web design and web development for the personal computer sphere that will bring webpages back to the people, so that personal home pages may exist as they did in the 90’s but with 34 years of advancements. Leave the business pages to all of the cliche web designs we’ve all seen before and create not over the top but webpages a person would want to have so others who have personal computers may see their webpage, a store of information unique to their interests and self expression unlike social media which imposes limitations on the freedom of expression, but to also be their main point of call over the internet complimentary to social media.
6. Read the docs properly! Too many times for me, an error was caused by overlooking something in the docs. Even the seemingly unimportant text (e.g. as a footnote) are usually important. If the docs are unclear, ask for help either on forums or in a community group e.g. discord if they have one. Or simply create an issue and ask the developer.
When I realized that I didn't have to learn an entire library but instead how to search on a documentation or resource a specific information, I managed to finish my projects faster. I am not that good at memorizing exact technical stuff but instead I memorize concepts and abstract processes, so I give up forcing myself to memorize new functions with their exact implementation, instead I know at the higher level what tot do and where to find that information. I also have a file with code snippets for specific tasks. Coding now is a joy. So my advice to my younger me would be: 1. Learn general stuff about what ALL programming languages have in common: (variables, functions, loops, conditions) 2. Don't worry to much if you can't memorizing the exact specific syntax for certain things, just write it down on a text file 3. Try to do the same thing in 3-4 different ways and see where it breaks the code, that way you learn what doesn't work and you figure out why it doesn't work.
"Learn by doing" is absolutely one of the biggest, if not the biggest, hurdles to overcome when you want to code. You have to commit to failing quickly and failing fast. You need to look forward to the problems and want to solve them. Failing is a "GOOD THING". This is not just something that only applies to programming. This applies to life as a whole! Usually, the hardest things in life are very rewarding and worth the time. But that only holds if you interpret it that way with the right attitude. Good advice Esla!
Could not agree more!!! I've been dipping in and out of it for years, giving up quickly by 'watching' rather than doing. Started a small project recently, using books and the net to help with any specific problems and I've learned more from my mistakes than I ever learned watching endless tutorial videos!
All so true. The only thing I'd add to this for beginner programmers is this: before you write a single line of code for a project, outline the entire program in comments in the same way you are taught to outline a paper. Amazing what a difference this makes.
I often do this and I've had coworkers ask me why. I point out the obvious: my first programming language was English (insert any human language you're comfortable enough in to be creative and express what needs to be done.) The more I did this the fewer bugs I found when I finally coded and executed my programs (and most of the ones I did find were simply typos).
You can write your main control methods that handles the key execution, but then your secondary methods don't need in the details, but just get the basic structures, classes, and event system / execution path working. Then work down to the details from there.
I said nearly the same thing as you to an intern at work last week about comments and commit messages. Programming is story-telling and being aware of it results in better code.
As someone with 30 years experience in programming, I 100% agree with this advice. For me, 'prioritize understanding' is something I'm been guilty of skipping. I have deadlines, and I see an example that works, so I run with it, only to later realize it wasn't the best solution to the problem and may even end up being a bigger problem in the end!
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.
I agree. The best thing I've learn graduating as an engineer and now use every day as a programmer: 1/ Architecture: knowing from the start how computer works (CPU, cache, RAM, heap/stack memory, ...) is a bless. Whatever language or technology you are using, you should always know how it works. If some language manage complicate things for you (memory) it's still up to you to use it well. 2/ Boolean algebra. Every scientific student should learn that, it is beautiful and very useful. 3/ Assembly. As a C/C++ programmer, there are so many problems I could never solved without analyzing the generated assembly. Always be curious, invest your time to understand in depth the how it works rather than learning to repeat what you see.
Why on EARTH would you recommend new programmers to learn Assembly? Not only is Assembly hardware specific, it’s almost always NOT computational “safe” (thread safe). Stack and Heap is important to understand (boxing and unboxing). The market for hardware specific Assembly programmers is next to zero. The market for C++ programmers is VERY small and getting smaller by the year. But understand exactly how a CPU works with RAM I/O is going to turn someone off programming quickly … they don’t need to know how the CPU is doing predictive evaluations to determine operation efficiency for the next instruction. Not even going to start in on the HAL and its coding implications.
@@robainscough Like I said, I'm a C++ developper. Assembly knowledge helped me solving countless bugs with much more success than colleague that never tried having a look to disassembly to understand problems and performance issues. I've heard that C++ or compiled languages are over for decades. But guess what, they are still there and used to build most OS and many big server application. C++ is evolving every years and several compiled languages have been created relatively recently. Assembly knowledge will always be very useful with those technologies. Thinking you don’t need any assembly knowledge because the compiler handle it for you is like thinking you don’t need to know how memory is used with managed languages.
do not memorize everything. understand the concepts and build a mental index/keywords, so you can search/find details of whatever you need whenever you need them. Good video!
Ms. Scola: Thank you dearly, for this video. I watched it twice, and I can see the logic behind your video, and you know what? Your right. #2 was especially helpful. In 1981, I got a TI99/4a computer as my first system. Wonderful system aside from one tiny problem. THERE WAS NO STORAGE to speak of! Yes we had an audio tape storage, but that was worthless. 99% of the time it wouldn't save all the code or correctly so I gave up. I finally started just typing back in the code I wanted when ever I started the computer. Ultimately coding became instinctial to the point I could write it in my head, or work out problems, by simply thinking of it. Ultimately by the 90s I burned out since it was so damned frustrating to write; We had a saying in one of my computer classes; 1 hour programming, 5 hours debugging cause there wasn't any debuggers, no google or nothing. I've been starting back into BASH and Python for about a year, but struggled badly. I now know, I was doing the other part; learning the language, not programming. :( Now at 58 I'm trying to became something in IT, (I'm just starting) but this entire video is useful for many things, especially since I now know I'm ADHD but now controlled and so much better than I was. Your other video about having a roadmap also helps in just basically learning, but also in my writing too since ADHD causes problems with that. My job will pay for some IT certificate trainings, but with this new structure, maybe now I can even go on to even better things. Thank you again, for helping an older, frustrated person now possibly achieve her goals and dreams in life. -- Kantuck
You have shared my thoughts. Many of my friends randomly started learning about programming languages and lectures instead of the origin , purpose and logic to learn programming. Really a good video : )
🎯 Key points for quick navigation: 00:00:14 *💻 The speaker has been a software engineer at a FAANG company for almost four years, gaining confidence over time despite early struggles.* 00:00:43 *💡 The first lesson: "Learn by doing." You can't master coding by just watching videos; actual practice is essential.* 00:01:12 *🌐 Start by building something you want, like a website, to learn more effectively and create a portfolio piece.* 00:01:27 *🧠 The second lesson: "Learn to program, not just a programming language." Understanding concepts is more critical than memorizing syntax.* 00:02:39 *🔍 Focus on understanding the abstract concepts behind algorithms, which can be applied across any programming language.* 00:03:20 *🗺️ The third lesson: "Create a road map." Determine what you want to build, then learn the necessary technologies in a structured way.* 00:05:15 *🔧 The fourth lesson: "Prioritize understanding over everything." Take the time to understand why your code works, which will save time in the long run.* 00:07:06 *🔁 The fifth lesson: "Get used to failing." Failure is essential for learning and growth as a software engineer.* Made with HARPA AI
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 I ever found, no confusion is left. Thanks for sharing the things that teachers normally do not teach about.😀😀😀 Coding Was HARD Until I Learned These 5 Things... 1. Learn by doing 2. Learn to program, not programming language 3. Create a roadmap for yourself 4. Prioritize understanding 5. Get use to failing "5 Lessons to Ease into Programming: Insights from a Software Engineer at Fang Company" [00:01] Learning by doing is the key to mastering coding. - Practice problems and power through adversity to improve coding skills. - Avoid shortcuts and invest time in writing code to deepen understanding. [01:01] Code actively by building projects, not just watching tutorials. - Choose a project to build and learn required technologies. - Focus on learning to program, not just a programming language. [02:04] Understanding algorithms conceptually is more crucial than memorizing in a specific language. - Focus on grasping the concept of algorithms rather than just the syntax in a programming language. - It is essential to be able to implement algorithms conceptually, regardless of the programming language used. [03:12] Create a roadmap based on what you want to build. - Identify your end goal to determine necessary technologies. - Utilize free and paid resources to kickstart your software engineering journey. [04:15] Structured course with hands-on practice problems and real-life projects for aspiring software engineers - Course covers fundamentals and offers specializations in front end, back end, or devops - Provides coaching, feedback on code, and free introductory module [05:14] Prioritize understanding over everything - This advice is crucial for effective coding. - Taking the time to understand a problem now saves time in the future. [06:17] The best ways to learn as a programmer - Referencing the official documentation of the programming language for accurate information - Don't be afraid to ask colleagues, friends, and senior engineers for help [07:26] Embrace failure to grow as a software engineer - Taking on tasks that are challenging or intimidating can lead to valuable learning experiences. - Seeking discomfort is essential for personal and professional growth.
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.
My learning algorithm is a "depth first" approach (no pun intended). The "prioritize understanding" point is super important. A good rule of thumb is: if the answer to a question, poses one or more questions itself, then you don't understand the concept yet. You should continue asking questions, getting answers to them, until you encounter the "leaf node" question, and you then can go back up the "question stack", asking more questions as needed. Initiallty, it will take a long time to learn certain concepts this way, but it's a meta-skill, useful in many aspects of life outside of programming.
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!
Thanks. I thought i could take shortcuts with C++ but every progress I made sent me right back to the basics which i kinda skipped😂 this video has re-in-forced my interest in re-learning the problem solving concepts instead of coding. Thank you!
Number 1 is very important for a lot of people. Don't get too concerned about doing coding the "right way" or making lots of mistakes. You need the mistakes. You should read about patterns and other practices but don't always try to implement them straight away. You will realise when your code is repeating itself or becoming messy and you will naturally refactor. It will take time. As she said just work on a self initiated project, not something too simple but not huge. Something that you or someone you know might actually use.
Great advice; all relevant, all true. However, I highly recommend switching #4 and #5. It is a fact that people remember the first and last item on lists the most, and Understanding is in my opinion the most important advice. In fact, tongue in cheek, the list should be: #5 Understand, #6 Understand, and #7 Understand.
I LOVE YOU!!!! Finally, someone that gets it! I actually just lost my job as a teacher because most schools want happy students not knowledgeable ones. I told my students what you are saying. Students have to know what they are doing and actually be able to do it not just watch others do it and hand in someone else's work for their "A". Failure is good to learn from and we grow by problem solving which is just part of life. Your playing the piano example is perfect because I am a musician that is changing careers to computers and you have to practice to be good at anything. I apply my practicing music techniques to learning computers - a lot of repetition and problem solving. Thanks again.
you truly do speak my language lovely lady and I surprisingly understood everything here perfectly with my seriously cluttered PTSD mind. I have visual spatial learning needs especially (and gifts) and usually get bogged down listening to videos and lectures but there's something special about your style, whether it's your accent, your clarity, your focus, I don't know but there was something unique about your delivery that had me understand absolutely everything perfectly so thank you very much. Obviously this is a line that I'm very interested in studying. As a sideline I did actually wonder at 3:55 whether the potted plant was a prehistoric dinosaur or maybe that's just my crazy imagination. Anyway you do have much time on your side whereas I don't but I shall take a look around your channel to see if there's anything else that I might learn, and thank you. Have a fabulous week ahead 🎉
"what do you want to build?" whatever gets me a job, I'm not doing this for fun. Everyone asks this question but very rarely do they allow for the prospect that some people are studying programming solely to get a job, not because it's a "passion".
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.
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.
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 3rd semester will begin on 2nd sept and I was exceptionally down however your last suggestion actually motivated me a bit to continue my struggle. 🎉❤
Adding to the lineup is the 80/20 rule. Only 20% of the language is used for 80% of the coding jobs. The rest are either used in special situations or rarely used at all (trivia). This ruile can be applied to anything. You don't need to learn everything at the beginning.
This video was a refreshing paradigm shift for me. I have been told that I spend too much time pondering the fundamentals and that I ask too many questions concerning situations that might never be encountered. While some of that may be true in certain professional contexts, the "learn by doing" mantra leads to very bad and difficult to overcome habits without the understanding aspect. Personally, I don't feel comfortable sharing my programs with others when I haven't already tested all reasonable possibilites for it to fail... And I can't rightfully do that when I don't understand what I wrote haha.
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.
Some great advice here. I would add that beyond picking a project to start coding, commit to deploying and ideally monetizing it, even if it only makes $1 in ad rev. My first personal project I ever did, I had invested so much time I thought “why don’t I just publish this as shareware?” (Yes I’m old). This is a super important lesson, as coding a project for yourself, you can avoid the tough parts and bug fixes and documentation and polish and support and it doesn’t matter. But in production 80% of the work is the last 20% to release. By going through this exercise I felt 10x more confident at my next job, as I had “closed the loop”. I think I made $45. This was my first software company.
Depends on the colleagues. If they are normal - they will help in any cost (and if you are decent as well). If they are toxic - nothing will help you, you are doomed.
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.
Coding is an interesting mix of hard and easy. Hard stuff is hard, or really hard. Easy stuff is why I reads posts online saying how easy coding is (and I wonder how many million line code projects they worked on? :) In my experience the hardest part of coding is actually modifying existing code to work better, or different, without altering behavior that you are not supposed to alter. But when you are learning coding, you are probably writing your own, simpler code. In which case, there's three principles I believe in. (1) Breakdown the problem, pretty much everyone agrees with this. (2) At least try to do some design work up front, how will these steps you broke the problem down into, be organized in the code? And (3), especially when you are new to coding, consider re-writing code until you are happy with it, you are going to make mistakes, that's the learning process. As you improve, you will do less re-writing. One technique I have used a lot, is to write a program "top down", just to get started. Say you decide you need a function that reads in some file, then parses it, then builds some data structure from the data in the file. So I write the function like readFile(fileData); parseFileData( fileData, parsedData); transformParsedData( parsedData, finalData). Then I try to write the minimal viable code that "kinda" works. I write this higher level functions in the same way, top down. Start with dummy classes, or whatever style of programming you are doing. Refine the code to get something that "kinda works". Then go back with the knowledge you gained, and think more about the design, write up the design, then code from the design. If need be, do multiple iterations. My version of so called "rapid protoyping." A smarter person than me might imagine the whole thing in their head, code it up, then it works. Bravo! But I think a lot of us, need an iterative approach.
Over the past eight months, I’ve dedicated myself to mastering front-end development despite having no prior programming experience. Each concept I grasp-whether it’s HTML, CSS, or JavaScript-feels like a small victory, and every problem I encounter becomes an opportunity to learn and grow. Rather than ignoring these challenges, I’ve embraced them, knowing that solving each issue only sharpens my skills further. With every hurdle I overcome, my confidence in my developing abilities increases, making the journey both rewarding and empowering. While I often see people boasting about completing front-end roadmaps (which i doubt Xd) and landing jobs within six months, I’ve come to understand that genuine progress takes time and dedication. My journey has been about steady, persistent learning, rather than rushing through milestones. Thanks for the video Sweet Elsa !
This 5points are the • MOST BASIC • MOST IMPORTANT • MOST EFFICIENT • MOST ACCURATE • MOST PERFECT to grow in this field I have watched tone of videos regarding similar topics like this. But, the way you describes it just fabulous 🙇🏻
Having a fundamental understanding of what you are doing is paramount to programming. If you don't understand what's happening, you will be in a lot of trouble when you are refactoring and debugging.
File handling has always been hard for me so while learning python, to sharpen my skills I created a file organiser which helped me to learn more complex file handling functions such as os.path.join or smth like that and os.path.splitext or smth like that, anything I didn't know I used Google to learn syntax and how to use the functions
Solid advice. I agree with most of what was being said in this video, however one should keep in mind conceptual learning is also must while learning to program and sole focus on building things may induce to skip on conceptual or theoretical part. In job interviews conceptual part is as much important as the practical part. So you can't underestimate book learning even while learning something as practical as programming.
I came across your video by chance and really enjoyed it! It took me back to when I was just starting out and learning all these rules as a fresher. I'm currently working with CodeIgniter and would really appreciate it if you could create a video series on DSA from beginner to advanced in PHP. It would be incredibly helpful for me and others in the community. Just subscribed to your channel-thank you for the great content! 😇
In computer programming, a string is a data type that represents text as a sequence of characters, words, or symbols. Strings can be used to store text or code for various purposes, such as web development and database operations. They can also be used to communicate information from a program to the user. from google
Thank you. 5. I do not feel that it is the reality, in fact I really appreciate the image you have shared, so I will look for body's discomfort. Because the thing we search to develop, is certainly only our out of sense being.
Great video. It is very simple advice but "simple" is not the same as easy. I have lost count on the number of times I have tried to learn coding. I think this advice may get me through it. Thank you.
This video nails what hundreds and thousands of coding learning videos fail to explain to the newcomers in the field. I started learning coding by myself as a hobby, until i understood what was missing in my life. At first was confusing and i was feeling lost in the myriade of materials and the endless videos, just like someone walking through unknowns paths hoping that will get somewhere. By my hard self learned experience i totally agree with the content of the video. First you have to know where you wanna go, than plan the skill`s path you must follow and than learn those required skills along the way by doing. Many learned coding concepts will be useful even in other fields, projects or coding languages. The best 8 minutes advice a novice coder will find on youtube , just came too late for me :) My bonus tip: unless you are into front end developing, start with python.
You eventually get to a point in your coding journey where you can watch YT videos on 2x speed and understand everything that’s going on. But that comes after coding for years, not before.
#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.
The most important thing is to prioritize under understanding . I think that this video helps me to change the way i learn to program , so think you for that
This is what I'm learning now: learn by actually doing it. The memorization part too; I thought I needed to do that…I know my roadmap because HTML and CSS are required for my grad course. Take the time to understand is important because there's a lot I don't understand; frustrating here as I learn. I don't have an issue with failing because I know that's how I learn. Thanks for your five bits of lessons. Appreciate this!
Good advice. I'm three years into being self-taught and I can vouch for this advice. When Elsa talks about taking the time to understand a solution if you see one offered, it's a bit like saying that in order to learn to write, you must also practice reading too. As for failing, it feels sometimes like you are no good as a programmer when you face endless bugs, but this is normal. Spend a day writing code, spend two days debugging. :) Yeah, there are those magic moments when you write something complex and it works first time, but those are the exception. :) You are moving forward in steps and we just can't map every single step at the first attempt every single time. So every bug you encounter is just another step that you didn't realise you had to take. And like she said, the more painful it is learning [from a bug/issue], the more you will be learning from that. You don't forget that stuff. Earned a subscriber! :)
I wrote my first program 47 years ago, and in that time I have worked with 23 computer languages. Notice I said "worked" not "studied". That means I actually wrote programs in all of those languages. What ended up happening is that over time I created a "metalanguage" I use in my head. It can't be written down, and there is no compiler for it. But it has all the common language constructs. All languages have looping, branching, subprograms, and variables. Once programming is generalized in that way, coding becomes a process of translating what I have in my head into the syntax of the language I am using at the time. Since I am currently using C, C++, C#, ISIL, and T-SQL, I pick the syntax which is had the most commonality between all 4 languages. For example, there is no such thing as "the best choice" for loops, so it doesn't matter if you use a for, while, do-while, or jump (for Basic and assembly code). I tend to use "while" most, followed by "for", because it appears in most languages. In most cases, the compiler is smart enough to optimize your code for you anyway, and that frees you from thinking about the idiosyncrasies of the language so you can just focus on turning your ideas into a program.
@@Jedbullet29 It just developed over the years as I picked up new languages and noticed the commonality between them, so I kind of think it might take a decade or so to teach it to you. 😄
1. Learn by doing
2. Learn to program, not programming language
3. Create a roadmap for yourself
4. Prioritize understanding
5. Get use to failing
0. Be logical and realise the machine code is only running the logic that you have programmed into that code which the program executes. If you understand all the concepts and fundamentals, even the most basic fundamentals, you will then be able to engage with AI to help you with your code, but you must know how to program first, so that you may ask AI to correct the errors that will present to ensure you’re actually a true programmer.
lol roadmap, make webpages, stay away from frameworks, stick with the basic fundamentals and innovate, work alongside with AI to create super cool pieces of software for web development purposes, perhaps even apps that align with the web development projects. Have fun. Re-invent web design and web development for the personal computer sphere that will bring webpages back to the people, so that personal home pages may exist as they did in the 90’s but with 34 years of advancements. Leave the business pages to all of the cliche web designs we’ve all seen before and create not over the top but webpages a person would want to have so others who have personal computers may see their webpage, a store of information unique to their interests and self expression unlike social media which imposes limitations on the freedom of expression, but to also be their main point of call over the internet complimentary to social media.
When this happens as is starting now, you’re welcome.
@@user-jk8kn3ij8o what are you babbling about? lol webpage webapage..no!
6. Read the docs properly!
Too many times for me, an error was caused by overlooking something in the docs. Even the seemingly unimportant text (e.g. as a footnote) are usually important. If the docs are unclear, ask for help either on forums or in a community group e.g. discord if they have one. Or simply create an issue and ask the developer.
The Algorithm recommended this video. The timing was impeccable. “You have to take the time to understand what you are doing”.
Agree
.
When I realized that I didn't have to learn an entire library but instead how to search on a documentation or resource a specific information, I managed to finish my projects faster.
I am not that good at memorizing exact technical stuff but instead I memorize concepts and abstract processes, so I give up forcing myself to memorize new functions with their exact implementation, instead I know at the higher level what tot do and where to find that information. I also have a file with code snippets for specific tasks. Coding now is a joy.
So my advice to my younger me would be:
1. Learn general stuff about what ALL programming languages have in common: (variables, functions, loops, conditions)
2. Don't worry to much if you can't memorizing the exact specific syntax for certain things, just write it down on a text file
3. Try to do the same thing in 3-4 different ways and see where it breaks the code, that way you learn what doesn't work and you figure out why it doesn't work.
Thank you!
This helped me so much
"Learn by doing" is absolutely one of the biggest, if not the biggest, hurdles to overcome when you want to code. You have to commit to failing quickly and failing fast. You need to look forward to the problems and want to solve them. Failing is a "GOOD THING". This is not just something that only applies to programming. This applies to life as a whole!
Usually, the hardest things in life are very rewarding and worth the time. But that only holds if you interpret it that way with the right attitude.
Good advice Esla!
Could not agree more!!!
I've been dipping in and out of it for years, giving up quickly by 'watching' rather than doing.
Started a small project recently, using books and the net to help with any specific problems and I've learned more from my mistakes than I ever learned watching endless tutorial videos!
All so true. The only thing I'd add to this for beginner programmers is this: before you write a single line of code for a project, outline the entire program in comments in the same way you are taught to outline a paper. Amazing what a difference this makes.
I often do this and I've had coworkers ask me why. I point out the obvious: my first programming language was English (insert any human language you're comfortable enough in to be creative and express what needs to be done.)
The more I did this the fewer bugs I found when I finally coded and executed my programs (and most of the ones I did find were simply typos).
Yes pseudo code in plain English
You can write your main control methods that handles the key execution, but then your secondary methods don't need in the details, but just get the basic structures, classes, and event system / execution path working. Then work down to the details from there.
I said nearly the same thing as you to an intern at work last week about comments and commit messages. Programming is story-telling and being aware of it results in better code.
@@williamivey5296
Makes sense❤
As someone with 30 years experience in programming, I 100% agree with this advice.
For me, 'prioritize understanding' is something I'm been guilty of skipping. I have deadlines, and I see an example that works, so I run with it, only to later realize it wasn't the best solution to the problem and may even end up being a bigger problem in the end!
This is the best lecture on introductory programming I've ever heard. Bravo!
This is something that sould be at the beginning of every programming tutorial on youtube. Well said, Elsa.
Straight on. You're a good coach.
Most people run away from the work input, yet expect a max output.
Great advice! I have been programming for 30+ years, and this is exactly what you need to do. Thank you! Cheers Dave
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.
I agree.
The best thing I've learn graduating as an engineer and now use every day as a programmer:
1/ Architecture: knowing from the start how computer works (CPU, cache, RAM, heap/stack memory, ...) is a bless. Whatever language or technology you are using, you should always know how it works. If some language manage complicate things for you (memory) it's still up to you to use it well.
2/ Boolean algebra. Every scientific student should learn that, it is beautiful and very useful.
3/ Assembly. As a C/C++ programmer, there are so many problems I could never solved without analyzing the generated assembly.
Always be curious, invest your time to understand in depth the how it works rather than learning to repeat what you see.
I start learning C and I really don't know what the career for this language what I can do ot work with I will be so much thankful if you help me out
Do you have any book or channel recommendation to learn all thise topics you suggested in your reply?
Why on EARTH would you recommend new programmers to learn Assembly? Not only is Assembly hardware specific, it’s almost always NOT computational “safe” (thread safe). Stack and Heap is important to understand (boxing and unboxing). The market for hardware specific Assembly programmers is next to zero. The market for C++ programmers is VERY small and getting smaller by the year. But understand exactly how a CPU works with RAM I/O is going to turn someone off programming quickly … they don’t need to know how the CPU is doing predictive evaluations to determine operation efficiency for the next instruction. Not even going to start in on the HAL and its coding implications.
@@robainscough Like I said, I'm a C++ developper. Assembly knowledge helped me solving countless bugs with much more success than colleague that never tried having a look to disassembly to understand problems and performance issues.
I've heard that C++ or compiled languages are over for decades. But guess what, they are still there and used to build most OS and many big server application. C++ is evolving every years and several compiled languages have been created relatively recently. Assembly knowledge will always be very useful with those technologies.
Thinking you don’t need any assembly knowledge because the compiler handle it for you is like thinking you don’t need to know how memory is used with managed languages.
C++is very hard
do not memorize everything. understand the concepts and build a mental index/keywords, so you can search/find details of whatever you need whenever you need them. Good video!
Ms. Scola:
Thank you dearly, for this video. I watched it twice, and I can see the logic behind your video, and you know what? Your right.
#2 was especially helpful. In 1981, I got a TI99/4a computer as my first system. Wonderful system aside from one tiny problem. THERE WAS NO STORAGE to speak of! Yes we had an audio tape storage, but that was worthless. 99% of the time it wouldn't save all the code or correctly so I gave up. I finally started just typing back in the code I wanted when ever I started the computer. Ultimately coding became instinctial to the point I could write it in my head, or work out problems, by simply thinking of it.
Ultimately by the 90s I burned out since it was so damned frustrating to write; We had a saying in one of my computer classes; 1 hour programming, 5 hours debugging cause there wasn't any debuggers, no google or nothing.
I've been starting back into BASH and Python for about a year, but struggled badly. I now know, I was doing the other part; learning the language, not programming. :(
Now at 58 I'm trying to became something in IT, (I'm just starting) but this entire video is useful for many things, especially since I now know I'm ADHD but now controlled and so much better than I was. Your other video about having a roadmap also helps in just basically learning, but also in my writing too since ADHD causes problems with that.
My job will pay for some IT certificate trainings, but with this new structure, maybe now I can even go on to even better things.
Thank you again, for helping an older, frustrated person now possibly achieve her goals and dreams in life.
-- Kantuck
What helps me is putting layman terms to names in software for example an array is a list, an entity is something you add fields to, etc
An array isn't a list. A list is a list. An array is an n-dimensional list.
You have shared my thoughts. Many of my friends randomly started learning about programming languages and lectures instead of the origin , purpose and logic to learn programming. Really a good video : )
1. Learn by doing
2. Learn to program, not programming language
3. Create a roadmap for yourself
4. Prioritize understanding
5. Get used to failing
You you are casually destroying her watch time 😂😂
🎯 Key points for quick navigation:
00:00:14 *💻 The speaker has been a software engineer at a FAANG company for almost four years, gaining confidence over time despite early struggles.*
00:00:43 *💡 The first lesson: "Learn by doing." You can't master coding by just watching videos; actual practice is essential.*
00:01:12 *🌐 Start by building something you want, like a website, to learn more effectively and create a portfolio piece.*
00:01:27 *🧠 The second lesson: "Learn to program, not just a programming language." Understanding concepts is more critical than memorizing syntax.*
00:02:39 *🔍 Focus on understanding the abstract concepts behind algorithms, which can be applied across any programming language.*
00:03:20 *🗺️ The third lesson: "Create a road map." Determine what you want to build, then learn the necessary technologies in a structured way.*
00:05:15 *🔧 The fourth lesson: "Prioritize understanding over everything." Take the time to understand why your code works, which will save time in the long run.*
00:07:06 *🔁 The fifth lesson: "Get used to failing." Failure is essential for learning and growth as a software engineer.*
Made with HARPA AI
Thank you ❤
This is awesome I would definitely recommend future programmers to this video!
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 I ever found, no confusion is left. Thanks for sharing the things that teachers normally do not teach about.😀😀😀
Coding Was HARD Until I Learned These 5 Things...
1. Learn by doing
2. Learn to program, not programming language
3. Create a roadmap for yourself
4. Prioritize understanding
5. Get use to failing
"5 Lessons to Ease into Programming: Insights from a Software Engineer at Fang Company"
[00:01] Learning by doing is the key to mastering coding.
- Practice problems and power through adversity to improve coding skills.
- Avoid shortcuts and invest time in writing code to deepen understanding.
[01:01] Code actively by building projects, not just watching tutorials.
- Choose a project to build and learn required technologies.
- Focus on learning to program, not just a programming language.
[02:04] Understanding algorithms conceptually is more crucial than memorizing in a specific language.
- Focus on grasping the concept of algorithms rather than just the syntax in a programming language.
- It is essential to be able to implement algorithms conceptually, regardless of the programming language used.
[03:12] Create a roadmap based on what you want to build.
- Identify your end goal to determine necessary technologies.
- Utilize free and paid resources to kickstart your software engineering journey.
[04:15] Structured course with hands-on practice problems and real-life projects for aspiring software engineers
- Course covers fundamentals and offers specializations in front end, back end, or devops
- Provides coaching, feedback on code, and free introductory module
[05:14] Prioritize understanding over everything
- This advice is crucial for effective coding.
- Taking the time to understand a problem now saves time in the future.
[06:17] The best ways to learn as a programmer
- Referencing the official documentation of the programming language for accurate information
- Don't be afraid to ask colleagues, friends, and senior engineers for help
[07:26] Embrace failure to grow as a software engineer
- Taking on tasks that are challenging or intimidating can lead to valuable learning experiences.
- Seeking discomfort is essential for personal and professional growth.
So true. Thanks for sharing to the community.
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.
My learning algorithm is a "depth first" approach (no pun intended). The "prioritize understanding" point is super important. A good rule of thumb is: if the answer to a question, poses one or more questions itself, then you don't understand the concept yet.
You should continue asking questions, getting answers to them, until you encounter the "leaf node" question, and you then can go back up the "question stack", asking more questions as needed.
Initiallty, it will take a long time to learn certain concepts this way, but it's a meta-skill, useful in many aspects of life outside of programming.
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!
Thank you so much for the lessons. No more getting stuck in tutorials 👍
Thanks. I thought i could take shortcuts with C++ but every progress I made sent me right back to the basics which i kinda skipped😂 this video has re-in-forced my interest in re-learning the problem solving concepts instead of coding. Thank you!
I needed this video, as I'm new to this. But that light-up dinosaur behind you is SO cute!! I want one.
Number 1 is very important for a lot of people. Don't get too concerned about doing coding the "right way" or making lots of mistakes. You need the mistakes. You should read about patterns and other practices but don't always try to implement them straight away. You will realise when your code is repeating itself or becoming messy and you will naturally refactor. It will take time.
As she said just work on a self initiated project, not something too simple but not huge. Something that you or someone you know might actually use.
"No discomfort, no expansion." Ok2 noted!
no discomfort no expansion ---> no pain no gain
The algorithm today blessed me . Nice video
Stuck in the middle between "Never write a line of code" and Junior seniority and this video is very helpful. Thanks for your advice Elsa
Superb advice Elsa, thank you! A very high tolerance for failure, and an ability to get up again, is a kind of superpower.
Like a dog on a bone
I was struggling with a certain code and It's been 2 days and this vid pops up! Incredible timing! Thank you my lady
Glad it helped!
I have been a developer for years, old school, and I am impressed by your maturity and deep understanding of the necessary pedagogy.
Great advice; all relevant, all true. However, I highly recommend switching #4 and #5. It is a fact that people remember the first and last item on lists the most, and Understanding is in my opinion the most important advice. In fact, tongue in cheek, the list should be: #5 Understand, #6 Understand, and #7 Understand.
i agree with all (each has their own path and taste)
I LOVE YOU!!!! Finally, someone that gets it! I actually just lost my job as a teacher because most schools want happy students not knowledgeable ones. I told my students what you are saying. Students have to know what they are doing and actually be able to do it not just watch others do it and hand in someone else's work for their "A". Failure is good to learn from and we grow by problem solving which is just part of life. Your playing the piano example is perfect because I am a musician that is changing careers to computers and you have to practice to be good at anything. I apply my practicing music techniques to learning computers - a lot of repetition and problem solving. Thanks again.
Which key/chords d,you program in lol
Not in today’s world it’s all smoke and mirrors. It is better to tell a lie than tell the truth.
This was so goooood! I am just beginning. I loved each point. Number 5 is really important for me as well! Great video! Thank YOU!
Other code teachers don't say this. This is so invaluable.
I love this video. You learn nothing from success. You learn from pushing through failure.
you truly do speak my language lovely lady and I surprisingly understood everything here perfectly with my seriously cluttered PTSD mind. I have visual spatial learning needs especially (and gifts) and usually get bogged down listening to videos and lectures but there's something special about your style, whether it's your accent, your clarity, your focus, I don't know but there was something unique about your delivery that had me understand absolutely everything perfectly so thank you very much. Obviously this is a line that I'm very interested in studying. As a sideline I did actually wonder at 3:55 whether the potted plant was a prehistoric dinosaur or maybe that's just my crazy imagination. Anyway you do have much time on your side whereas I don't but I shall take a look around your channel to see if there's anything else that I might learn, and thank you. Have a fabulous week ahead 🎉
Thank you, what a great work, keep going ❤️
"what do you want to build?" whatever gets me a job, I'm not doing this for fun. Everyone asks this question but very rarely do they allow for the prospect that some people are studying programming solely to get a job, not because it's a "passion".
Single best video on what to do to get better that I've ever seen. I actually learned something here, thank you Elsa!!
I've been programming since the early 00s. This short video is spot on.
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.
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.
Hi Elsa, as a noob, I really appreciate this. Thank you!
As a software engineer for over 20 years, I agree. You have to put in the hard work to become a good engineer, learn from doing and ask questions.
Thank you, just THANK YOU! ♥
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). :)
Amazing! Simple and straight to the point. Thanks!
My 3rd semester will begin on 2nd sept and I was exceptionally down however your last suggestion actually motivated me a bit to continue my struggle. 🎉❤
i think the most amazing thing is that she's been at amazon for 4 years! most people churn out of amazon in 18 months.
Adding to the lineup is the 80/20 rule.
Only 20% of the language is used for 80% of the coding jobs.
The rest are either used in special situations or rarely used at all (trivia).
This ruile can be applied to anything.
You don't need to learn everything at the beginning.
This video was a refreshing paradigm shift for me. I have been told that I spend too much time pondering the fundamentals and that I ask too many questions concerning situations that might never be encountered. While some of that may be true in certain professional contexts, the "learn by doing" mantra leads to very bad and difficult to overcome habits without the understanding aspect. Personally, I don't feel comfortable sharing my programs with others when I haven't already tested all reasonable possibilites for it to fail... And I can't rightfully do that when I don't understand what I wrote haha.
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.
As someone who's been doing this professionally for around 15 years, I 100% agree with ALL of these. Especially 1, 2, and 4.
A lot of value on this video ! For me it’s perfect timing bc I’m just getting started so thank you so much
I wish I could like this more than once. Very helpful and reassuring advice! Thank you!
Some great advice here. I would add that beyond picking a project to start coding, commit to deploying and ideally monetizing it, even if it only makes $1 in ad rev. My first personal project I ever did, I had invested so much time I thought “why don’t I just publish this as shareware?” (Yes I’m old). This is a super important lesson, as coding a project for yourself, you can avoid the tough parts and bug fixes and documentation and polish and support and it doesn’t matter. But in production 80% of the work is the last 20% to release. By going through this exercise I felt 10x more confident at my next job, as I had “closed the loop”. I think I made $45. This was my first software company.
Remember, It is semantic over syntax always
If you are afraid of looking stupid in front of your colleagues you could always prefix your question with "this may be a stupid question, but"
when you ask, you MAY look stupid once. when you don't ask, you DO look stupid every time.
@@g06o84r and you will remain stupid if you dont ask, coz you will lose the opportunity to learn and get your answer
There are no stupid questions....just a lot of inquisitive idiots.😅😂
Depends on the colleagues. If they are normal - they will help in any cost (and if you are decent as well). If they are toxic - nothing will help you, you are doomed.
I think this is the only video in the world that says this. Wow! Amazing.
certainly takes time learning in that way, and money. I began a few months ago, wish me luck! best video recomendation!
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.
Coding is an interesting mix of hard and easy. Hard stuff is hard, or really hard. Easy stuff is why I reads posts online saying how easy coding is (and I wonder how many million line code projects they worked on? :) In my experience the hardest part of coding is actually modifying existing code to work better, or different, without altering behavior that you are not supposed to alter. But when you are learning coding, you are probably writing your own, simpler code. In which case, there's three principles I believe in. (1) Breakdown the problem, pretty much everyone agrees with this. (2) At least try to do some design work up front, how will these steps you broke the problem down into, be organized in the code? And (3), especially when you are new to coding, consider re-writing code until you are happy with it, you are going to make mistakes, that's the learning process. As you improve, you will do less re-writing. One technique I have used a lot, is to write a program "top down", just to get started. Say you decide you need a function that reads in some file, then parses it, then builds some data structure from the data in the file. So I write the function like readFile(fileData); parseFileData( fileData, parsedData); transformParsedData( parsedData, finalData). Then I try to write the minimal viable code that "kinda" works. I write this higher level functions in the same way, top down. Start with dummy classes, or whatever style of programming you are doing. Refine the code to get something that "kinda works". Then go back with the knowledge you gained, and think more about the design, write up the design, then code from the design. If need be, do multiple iterations. My version of so called "rapid protoyping." A smarter person than me might imagine the whole thing in their head, code it up, then it works. Bravo! But I think a lot of us, need an iterative approach.
God bless you for this
I started programming recently
And I've been struggling soooooo badly
Thank you for helping to put context to my journey ❤
Over the past eight months, I’ve dedicated myself to mastering front-end development despite having no prior programming experience. Each concept I grasp-whether it’s HTML, CSS, or JavaScript-feels like a small victory, and every problem I encounter becomes an opportunity to learn and grow. Rather than ignoring these challenges, I’ve embraced them, knowing that solving each issue only sharpens my skills further. With every hurdle I overcome, my confidence in my developing abilities increases, making the journey both rewarding and empowering.
While I often see people boasting about completing front-end roadmaps (which i doubt Xd) and landing jobs within six months, I’ve come to understand that genuine progress takes time and dedication. My journey has been about steady, persistent learning, rather than rushing through milestones.
Thanks for the video Sweet Elsa !
That’s great 🙌 keep up the good work!
@@ElsaScola I’ll update you when I’m a full-stack pro! 🚀👨💻
keep it up bud, im on the same road as you
@@Ibrahim-ui1ns U too man 👊!
This 5points are the
• MOST BASIC
• MOST IMPORTANT
• MOST EFFICIENT
• MOST ACCURATE
• MOST PERFECT
to grow in this field
I have watched tone of videos regarding similar topics like this.
But, the way you describes it just fabulous 🙇🏻
Yes. Great advice here.
There's a bug in the for loop at 2m27s. Using
If you take advise, take it from the best!
It was code design patterns like services & FP paradigms that unlocked coding for me.
Having a fundamental understanding of what you are doing is paramount to programming. If you don't understand what's happening, you will be in a lot of trouble when you are refactoring and debugging.
File handling has always been hard for me so while learning python, to sharpen my skills I created a file organiser which helped me to learn more complex file handling functions such as os.path.join or smth like that and os.path.splitext or smth like that, anything I didn't know I used Google to learn syntax and how to use the functions
You are absolutely right. coding is like Mathematics. One has to keep practising.
Great advice, thanks!
Solid advice. I agree with most of what was being said in this video, however one should keep in mind conceptual learning is also must while learning to program and sole focus on building things may induce to skip on conceptual or theoretical part. In job interviews conceptual part is as much important as the practical part. So you can't underestimate book learning even while learning something as practical as programming.
I came across your video by chance and really enjoyed it! It took me back to when I was just starting out and learning all these rules as a fresher. I'm currently working with CodeIgniter and would really appreciate it if you could create a video series on DSA from beginner to advanced in PHP. It would be incredibly helpful for me and others in the community. Just subscribed to your channel-thank you for the great content! 😇
One of the best advise i recieved in my entire life so far. Thanks for making this video.
In computer programming, a string is a data type that represents text as a sequence of characters, words, or symbols. Strings can be used to store text or code for various purposes, such as web development and database operations. They can also be used to communicate information from a program to the user. from google
Thank you. 5. I do not feel that it is the reality, in fact I really appreciate the image you have shared, so I will look for body's discomfort. Because the thing we search to develop, is certainly only our out of sense being.
Great video. It is very simple advice but "simple" is not the same as easy. I have lost count on the number of times I have tried to learn coding. I think this advice may get me through it. Thank you.
Lesson #1 Work hard. .....Alright, let me stop you right there. ✋🏼
This video nails what hundreds and thousands of coding learning videos fail to explain to the newcomers in the field.
I started learning coding by myself as a hobby, until i understood what was missing in my life.
At first was confusing and i was feeling lost in the myriade of materials and the endless videos, just like someone walking through unknowns paths hoping that will get somewhere.
By my hard self learned experience i totally agree with the content of the video.
First you have to know where you wanna go, than plan the skill`s path you must follow and than learn those required skills along the way by doing. Many learned coding concepts will be useful even in other fields, projects or coding languages.
The best 8 minutes advice a novice coder will find on youtube , just came too late for me :)
My bonus tip: unless you are into front end developing, start with python.
You eventually get to a point in your coding journey where you can watch YT videos on 2x speed and understand everything that’s going on. But that comes after coding for years, not before.
Thanks a lot for these, learnt a lot
Thanks!!! Good advice
[1:30] This is what the programmer Andy Harris recommends to avoid the programming language trap.
#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.
Elsa, you are absolutely _brilliant_ !
The most important thing is to prioritize under understanding . I think that this video helps me to change the way i learn to program , so think you for that
You just caught me all my mistakes
This is what I'm learning now: learn by actually doing it. The memorization part too; I thought I needed to do that…I know my roadmap because HTML and CSS are required for my grad course. Take the time to understand is important because there's a lot I don't understand; frustrating here as I learn. I don't have an issue with failing because I know that's how I learn. Thanks for your five bits of lessons. Appreciate this!
The 4th one was the best advice 😉
Good advice. I'm three years into being self-taught and I can vouch for this advice.
When Elsa talks about taking the time to understand a solution if you see one offered, it's a bit like saying that in order to learn to write, you must also practice reading too.
As for failing, it feels sometimes like you are no good as a programmer when you face endless bugs, but this is normal. Spend a day writing code, spend two days debugging. :) Yeah, there are those magic moments when you write something complex and it works first time, but those are the exception. :)
You are moving forward in steps and we just can't map every single step at the first attempt every single time. So every bug you encounter is just another step that you didn't realise you had to take.
And like she said, the more painful it is learning [from a bug/issue], the more you will be learning from that. You don't forget that stuff.
Earned a subscriber! :)
Word of advice is to learn reg expressions irrespective of the language you choose without which you're shooting yourself in the foot.
I wrote my first program 47 years ago, and in that time I have worked with 23 computer languages. Notice I said "worked" not "studied". That means I actually wrote programs in all of those languages. What ended up happening is that over time I created a "metalanguage" I use in my head. It can't be written down, and there is no compiler for it. But it has all the common language constructs. All languages have looping, branching, subprograms, and variables. Once programming is generalized in that way, coding becomes a process of translating what I have in my head into the syntax of the language I am using at the time. Since I am currently using C, C++, C#, ISIL, and T-SQL, I pick the syntax which is had the most commonality between all 4 languages. For example, there is no such thing as "the best choice" for loops, so it doesn't matter if you use a for, while, do-while, or jump (for Basic and assembly code). I tend to use "while" most, followed by "for", because it appears in most languages. In most cases, the compiler is smart enough to optimize your code for you anyway, and that frees you from thinking about the idiosyncrasies of the language so you can just focus on turning your ideas into a program.
Can I have your brain syntax please 😊
@@Jedbullet29 It just developed over the years as I picked up new languages and noticed the commonality between them, so I kind of think it might take a decade or so to teach it to you. 😄