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.
"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!
I still have the printed listing of my first attempt to write a program around 1970. It was an optical marked card fortran program to add 2 numbers on an IBM 1130. I did not read the manual first, and quickly found the syntax was not "intuitive". Got a manual, and kept on going.... By the time I took my first computer course, I was writing complex programs and able to operate the IBM system with a full understanding of the console foo error codes, and restart procedures.
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.
3. For example, array.filter is supppsed to work just like the iterative approach of building an array. However as the size of array increases, filter may not work always. In such cases, iterative approach is the way to build the filtered array. No one tells you this. You learn this by writing the same logic using different ways and finding what breaks the code.
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!
This is how my brain works normally, i need to understand why things do the things they do. And it's frustrating when something doesn't work then manically works. I simple is year a leap year the logic killed my brain with if (year % 4 ==0 && year % 100 != 0 || (year % 400 ==0));{} That single line of code is the whole thing but it works and it took me ages of asking chat gpt why and how to understand it
I've been programming for over 40 years and I was ready to dismiss this video ("not another video from a young person who thinks they have all the answers on learning to program"). But, I was happily surprised. Your advice is spot on. For me, the most important lesson is "Learning is doing" because you end up understanding anyway.
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.
When you first start learning programming, it may seem like language proficiency is the most important thing. But over time, you realize that the key isn’t which language you use, but how you approach problems. This moment of realization is when you truly enter 'god mode.' Being able to analyze problems correctly and discover solutions gives you a power far greater than just knowing the language itself.
I would not call it god mode; that's ego. Learning to write good code should be more personal. Coding well-done offers confidence to explore, learn, and move forward in your growth and career.
Hey...what or how does 1 get to this point. I'm in the failing stage where I am having to look up solutions after I generate my pseudocode or rendition of the logic. Not sure when I will eventually cross the stage without looking up the solutions online or reviewing after. Takes a lot of pains really
Becoming familiar with the reserved words of the language you are using is as important as the logic. Using the words of the language properly, the way they're intended, will move you in the right direction. Errors will minimize when your syntax( or reserved words and punctuation) and logic become most familiar.
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.
Learning to code can definitely be challenging, but resources like this make it so much easier to understand the basics! I’ve seen how Moonpreneur helps kids break down complex coding concepts in a way that’s super approachable.
A lot of developers feel they don't have the luxury of understanding how every code fix works when they have deadlines, but I completely agree that they need to know how it works in order to improve.
I started coding in approximately 1983. At that time everything was included in the hardware (Sinclair ZX81 and Sinclair ZX Spectrum). You turned on the computer which didn't have any software installed from elsewhere, and the first key you hit was a part of the number for your first line of code, usually "10". Something like that. Today you have to understand what IDE would be best, what language to choose, what framework would be suitable for your project, how different parts and versions are dependent of each other, how much disk space you will need in the long run and on what drive you should install the IDE, where and how to find the information you will need when coding (books, text sites, videos), and a few more things. So you have to do very much research before you can start coding, or you have to be prepared to go back to the beginning if you did a bad choice. And when you start watching the first introduction video, someone will start throwing a lot of strange, technical words at you while scrolling through code and menus, for more than five minutes, before writing the first line of code. What did we do wrong when we ended up here?! Nowadays, when you are coding, you will be rewarded much later in the working process. Today you really have to have patience if you want to get to the finish line in your project. You can't expect to say "Hello World!" in the first day of your programming career, like we did in the 1980s.
I am coding Python in Idle, which is almost as basic as your ZX81. What, exactly, is hard about print("Hello World!")??? You aren't making any sense whatsoever, Dude.
@@lepidoptera9337 Sure. You can start any kind of IDE and quite fast reach that stage when you can start writing code. But if you thought that that was the goal for all the research that I was mentioning, you missed my message and the bigger picture. My situation is that that I have made so many choices about languages, frameworks and other things, through the years, and seen my skills (and software) become more or less obsolete, that I nowadays prefer to think twice when making choices for a new project. By doing so, I will be rewarded when coding problems will get solved easier and when the software will live for a longer time. One of my better choices have been VBA in Access - a rather "closed environment" which rarely has been changed. The worst cases are from making site specific add-ons for a web browser and seeing the code on the web site being modified. But that problem is indeed about other kinds of choices. In other words, don't take that sentence about "Hello Word!" too literally. The project doesn't stop at "Hello Word!", does it? Also remember that a bad choice or defect introduced early in the development process can have big consequences (se table at en.wikipedia.org/wiki/Software_testing?useskin=vector#Controversy).
@@MartinJosefssonFI What skills are that? How to serve a semi-warm microwaved burger on a semi-fresh bun? Dude, stop making a fool of yourself online. ;-)
Well said. A very good overview of how tackle a complex task like programming. I am an old (now retired ) EE who has had to write code for various projects throughout my career. I learned early that the best way to learn something new was to take on a job that was obviously too big for me to do. Then go ahead and do it, learning everything I needed as part of the doing. (I am retired, but still curious about things tech. I just subscribed to your channel to see what other stuff you have to say.)
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!
All are good points. Number five is the best. When I started software development, I hated mistakes. As I became a better Engineer, I learned to love mistakes. They were opportunities to review my thinking and solution skills. I found that being forced to review my work and find errors made me a better Engineer. It made me consider the re-useability and clarity of my software. It taught me how to design and implement better software. For me, it wasn't enough to build a project solution. It was just as important to provide a solution which was easy to understand by another engineer. Self-documenting code and methods no larger than one screen length became big considerations. I began to look at my design and translation to code to be an artistic endeavor. That there was no reason for engineering solutions to be terse and abrasive.
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). :)
I love the way you are telling the truth about doing ANYTHING, including learning something. By asking the "W-Questions" first, and once you have a good idea of "What" you want to do, "Why" you want to do it, "When" you should do it, and "Where" you should do it, (even "Who" should do it) then you can move on to the "How" to do it. Everybody is always asking "How do I do this, instead of What should I... When, Why, Where, Who...?? Great advice you are sharing here. Thank you.
100% agree with you. I didn't learn the syntax as my first step. The first thing I set is the problem I want to solve, e.g. trading automation. Then I went through learning how my brain make every single decision in this specific task, break it down into several steps, and then googling/youtube how to perform every step from completely scattered tutorials. Gather those puzzles, assemble them, and then voila I get 1 portfolio that I can revisit to create another one. Trust me, the learning curve is only steep at the beginning of our process. Thank you!
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.
The first 16 seconds of the intro explained exactly how I felt when I was going to university studying computer science at the age of 30. I had just gotten done with all of my required math (calc2, discreet mathematics and engineering statistics). I finished my first coding semester (Java) and felt pretty good. My second coding semester introduced linked and double linked lists, and I felt like I hadn't learned a thing about coding. Meanwhile, there were 18/19-year-old "coding geniuses" around me who understood the syntax and logic without issue. Some of them had been coding since middle school. I felt like I was too old, lacked years of coding experience and too stupid to catch up to their level. I quit university a semester after that. How wrong I was. They warned us of imposter syndrome in the coding field. I should have never given up. I am now relearning how to code at 32 years of age. I won't give up this time. Genius or not, I love using logic to put together and solve the complex problems that make up programs. I love coding. Don't give up guys!
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 : )
The most lucid and useful description I've seen in sone time. I don't write code, but I've hired dozens of people who do. I wish more applicants had taken this approach
The hard part when learning to code is that it's catch 22 situation a little bit. When I first started I made the huge mistake in believing I had to understand every little piece and parts of the code, know what every little keyword meant etc, before I could move on to learning the next thing, and that made the learning process so much more difficult. Everything seemed very abstract because I couldn't relate to any of it, it's just gibberish at that point. Eventually I realized I had to take some time to just learn the syntax by writing various types of code over and over until I knew exactly _how_ to write a constructor class or a setter class or whatever it was, even though I didn't really understand how it worked or what these characters really meant. Just learning the syntax "upfront" like this, was a massive help to me.
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
Excellent summary of my 30 year career as a software developer. These are the nuggets of advice I try to teach both junior colleagues and friends who want to get into programming. This video explains these 5 points much better than I ever managed to do.
"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".
Exactly! I'll build whatever it takes, but I don't even know what's worth it to build. There are basic projects, sure, but those have little correlation to what it seems people need coders for
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!
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.
🎯 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
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.
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.
Sister, I would usually skip short videos like this one but I am glad I watched. Learn to code before coding language was the biggest idea that helped me. Thank you so so so much!!
Prioritizing the understanding was huge one for me. At first it felt like I was learning at a slower pace than my peers, but after awhile it seemed like I had a more advanced understanding so I was more equipped to help myself and solve issues on my own. It also gave me a lot more room for creativity.
I personally believe those who refuse learning math and calling themselves programmers by writing some code to join a bunch of dependencies are the most prone to losing their jobs to AI, they should be scared far more than those who are comfortable thinking mathematically
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!
number four is everything for me right now. I'm hoping that gut abstract grasp of things you mention will come for me in time, because right now it feels like I am looking up a sheer cliff face, nevermind 'learning curves'.
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.
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.
I find Jackson Structured Programming (JSP) still valid and a great help. Also ”You don’t understand a problem until you can simplify it” Also “you don’t program programs, you BUILD programs” has influenced my thinking for the better.
It is certainly good to know those five things. I have always found programming interesting and although I did not officially work in that field, had times both at work and at home where a project required me to program. I can certainly say it is best to have a project/goal to work towards as this gives you the "doing" part where you can begin to learn from your mistakes. Once I got the program to actually work the way I wanted, I would review the program to see if I could use less lines of code for the same results, which I often could. The other thing I did was leave plenty of remarks in case I or someone else had to come back to it to make any modifications. I learned this after believing I could remember what I did only to come back to the program months later and not have a clue as to why I wrote certain lines of code. Because I don't do this as a career, I often have to refresh my memory on certain aspects, but luckily certain aspects seem to be etched into my brain. I have learned several different languages and I can only say that when you understand how to program and learn just one language, other languages become far easier to learn.
No matter what language you learn. For your first project learn how to build and search a database for your snippets. Use the same language you are learning to do it. Use notes and comments in the database. That is the best lesson you can give yourself and you will use it as long as you progpram.
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! :)
One other encouragement is to understand the coders in tutorial videos and classroom instruction are working with code they know very well because they have prepared by essentially memorizing much of the code. They appear to be wizards b we cause of this.
Remember that stack overflow doesn't allow questions, mainly cause everything has already been asked and you need to be very specific in how you ask or they will censur/edit your question so it no longer asks what you wanted to know. This happened to my twice, and ended up being ignored by the user base. Yes, my questions had been asked before but not for the language I needed to use in those specific projects. So the moderator generalized the question and removed important parts for my language and ... yeah... Stack overflow is still a great resource though. But don't expect to add anything new to it.
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 !
If you're trying to understand the underlying concepts of programming (and even computing in general) without being tied to a language, I recommend The Computer Programme from the BBC (1982). This will bring you back to first concepts and let you understand everything from a zoomed-out perspective, instead of being tied to a modern language.
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.
Programming is HARD and it's not for everyone, being good programmer is like being good at chess. Programming is harder than learn a new language. The majority of people only speak one language.
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.
Simple but spot on , 1 What , 2 How , 3 Why, logical evaluation and simple logical thinking what your doing ,and How are doing it [in real time] , and for why yor are doing it to , & if you have a time revaluation and think to yourself "what else" can be done better or just a step & sit back for what you done by yourself and appreciate it ,for that doing mistakes will be a new lesson to learn
Good points. To the 1st point (learn by doing), one sub-task is to learn how to *test* ideas, programs and experiments (TDD, test driven development). That will help setting the right context, answer the "why" questions and help focusing on the problem to solve. It might also help with the later packaging, deployment and production phases.
Understanding is key. I so agree with 2. the difference between programming and a programming language. If you have your algorithm worked out, you can go to any language and output your program.
Something I like to do when I'm learning how to do a task, like say an R script for training a random forest model for plant species Identification, is to take code written by someone else and 'reverse engineer' it (with permission). Where I can take each function in a loop, or each library being called, and search through the documentation to figure out what each of those functions are doing and puzzle out how they piece together to get the final product. It can actually be great fun if you have the time. If I'm coding from scratch, let's use the same example as before of a machine learning model for predicting plant species based on multispectral drone imagery. First off, we can research what kind of machine learning algorithms are out there, which will determine which programming language we will use, whether we want to make a deep learning model or a classic ML model. Do we want the advantage of GPU acceleration at the cost of a steeper learning curve, or do we use an easier to learn library like MLR3 in R or SciKit-Learn in Python? A bit of a rambley comment I suppose, but it basically, all comes back to that first rule you talked about, "Learn by Doing". Come up with a project, it could be as simple as printing "Hello World" in the console, or as complex as a LiDAR analysis pipeline. It's all about setting finding a goal that you want to accomplish, learning the steps that you need to take to reach that goal, and then accomplishing each step. If you don't have a goal or purpose however, you're never going to actually learn anything.
I can agree. Learning the core of programming is learning how to solve real-life problems with code. Abstraction is key. Notice patterns in your code. A lot of problems can be solved with relatively similar code. There are industry standards for solving certain problems. Learn them. Never use code from someone else wich you do not understand.
been a programmer for like 10 years now and i have told young programmers about understanding the program rather than the language but this is what you master as you progress most young people dont listen to such advise they want quick results until after some time they begine to understand. but this is Ouwsome > I would also recommend them a book for structure and interpretation of computer programms
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.
Implementing the math is the crazy part which is a crucial factor in devising an algorithm. The algorithm is meant to sort out the datastructures by performing functions like search, add, delete, etc. I use w3schools offline version
I learned when I was 12. I read some code, wrote it, ran it, and understood why it happened. Then I learned some more, rinse and repeat. When an error happened, I instantly knew where the mistake was. More learning, simultaneous with programming. I just had a comprehensive and easy to read book. No Internet back in 1985.
The fundamental problem with software and systems development is communication and the ability to see the big picture and as the same time dive into details is key. And rare.
This is such a good video. The great thing is you can apply this approach to many things in life, not just programming (I’m not a programmer). Well done!
Glad you made the distinction between learning to program and learning a language. I often use the analogy of writing a book. I know English (fairly well lol) , I know what the words mean , how to spell some of them etc.. I couldn't sit down and organize all those words into a good cohesive grammatically correct novel. Knowing why you're using certain words in a certain order is essential to understanding how to make everything work together.
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.
And nowadays chatgpt can be utilized especially with prioritizing understanding!! You can enter in the programming that didn't work, explain what you are trying to accomplish with it, and ask for a solution and explanation in "terms that a child (teenager, data professional, c-level manager) can understand."
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.
@@thefreshprince-t4m 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
.
As I was reading this comment, they said it like a second later in the video. ✨😆
Helpful for me too. but I'm planning on learning guitar. Still applies
@@ttownscott it applies to *everything*
"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!
I still have the printed listing of my first attempt to write a program around 1970. It was an optical marked card fortran program to add 2 numbers on an IBM 1130. I did not read the manual first, and quickly found the syntax was not "intuitive". Got a manual, and kept on going.... By the time I took my first computer course, I was writing complex programs and able to operate the IBM system with a full understanding of the console foo error codes, and restart procedures.
💯 agree. This applies to everything you encounter. Everyone pass this on to all the youngsters.
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
thanks
copied, saved 👍🏻
3. For example, array.filter is supppsed to work just like the iterative approach of building an array. However as the size of array increases, filter may not work always. In such cases, iterative approach is the way to build the filtered array. No one tells you this. You learn this by writing the same logic using different ways and finding what breaks the code.
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!
I agree with you!
There's nothing more permanent than a temporary solution...!!!
This young lady doesn't seem to have 30 years experience in programming. Still knew these five "secrets". ;-)
@@edunet-lk507 Apparently so!
This is how my brain works normally, i need to understand why things do the things they do. And it's frustrating when something doesn't work then manically works. I simple is year a leap year the logic killed my brain with if (year % 4 ==0 && year % 100 != 0 || (year % 400 ==0));{}
That single line of code is the whole thing but it works and it took me ages of asking chat gpt why and how to understand it
I've been programming for over 40 years and I was ready to dismiss this video ("not another video from a young person who thinks they have all the answers on learning to program"). But, I was happily surprised. Your advice is spot on. For me, the most important lesson is "Learning is doing" because you end up understanding anyway.
I’ve been a developer/DBA/Engineer for almost 25 years…..I agree 100%! This is very good advice for new developers.
Straight on. You're a good coach.
Most people run away from the work input, yet expect a max output.
This is something that sould be at the beginning of every programming tutorial on youtube. Well said, Elsa.
This is the best lecture on introductory programming I've ever heard. Bravo!
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.
When you first start learning programming, it may seem like language proficiency is the most important thing. But over time, you realize that the key isn’t which language you use, but how you approach problems. This moment of realization is when you truly enter 'god mode.' Being able to analyze problems correctly and discover solutions gives you a power far greater than just knowing the language itself.
I would not call it god mode; that's ego. Learning to write good code should be more personal. Coding well-done offers confidence to explore, learn, and move forward in your growth and career.
Hey...what or how does 1 get to this point. I'm in the failing stage where I am having to look up solutions after I generate my pseudocode or rendition of the logic.
Not sure when I will eventually cross the stage without looking up the solutions online or reviewing after. Takes a lot of pains really
Becoming familiar with the reserved words of the language you are using is as important as the logic. Using the words of the language properly, the way they're intended, will move you in the right direction. Errors will minimize when your syntax( or reserved words and punctuation) and logic become most familiar.
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
Learning to code can definitely be challenging, but resources like this make it so much easier to understand the basics! I’ve seen how Moonpreneur helps kids break down complex coding concepts in a way that’s super approachable.
A lot of developers feel they don't have the luxury of understanding how every code fix works when they have deadlines, but I completely agree that they need to know how it works in order to improve.
Great advice! I have been programming for 30+ years, and this is exactly what you need to do. Thank you! Cheers Dave
I started coding in approximately 1983. At that time everything was included in the hardware (Sinclair ZX81 and Sinclair ZX Spectrum). You turned on the computer which didn't have any software installed from elsewhere, and the first key you hit was a part of the number for your first line of code, usually "10". Something like that. Today you have to understand what IDE would be best, what language to choose, what framework would be suitable for your project, how different parts and versions are dependent of each other, how much disk space you will need in the long run and on what drive you should install the IDE, where and how to find the information you will need when coding (books, text sites, videos), and a few more things.
So you have to do very much research before you can start coding, or you have to be prepared to go back to the beginning if you did a bad choice. And when you start watching the first introduction video, someone will start throwing a lot of strange, technical words at you while scrolling through code and menus, for more than five minutes, before writing the first line of code.
What did we do wrong when we ended up here?! Nowadays, when you are coding, you will be rewarded much later in the working process. Today you really have to have patience if you want to get to the finish line in your project. You can't expect to say "Hello World!" in the first day of your programming career, like we did in the 1980s.
I am coding Python in Idle, which is almost as basic as your ZX81. What, exactly, is hard about print("Hello World!")??? You aren't making any sense whatsoever, Dude.
@@lepidoptera9337 Sure. You can start any kind of IDE and quite fast reach that stage when you can start writing code. But if you thought that that was the goal for all the research that I was mentioning, you missed my message and the bigger picture. My situation is that that I have made so many choices about languages, frameworks and other things, through the years, and seen my skills (and software) become more or less obsolete, that I nowadays prefer to think twice when making choices for a new project. By doing so, I will be rewarded when coding problems will get solved easier and when the software will live for a longer time. One of my better choices have been VBA in Access - a rather "closed environment" which rarely has been changed. The worst cases are from making site specific add-ons for a web browser and seeing the code on the web site being modified. But that problem is indeed about other kinds of choices.
In other words, don't take that sentence about "Hello Word!" too literally. The project doesn't stop at "Hello Word!", does it? Also remember that a bad choice or defect introduced early in the development process can have big consequences (se table at en.wikipedia.org/wiki/Software_testing?useskin=vector#Controversy).
Absolutely true. Commodore 64 'er here. Today is a chaos.
@@MartinJosefssonFI What skills are that? How to serve a semi-warm microwaved burger on a semi-fresh bun? Dude, stop making a fool of yourself online. ;-)
Well said. A very good overview of how tackle a complex task like programming. I am an old (now retired ) EE who has had to write code for various projects throughout my career. I learned early that the best way to learn something new was to take on a job that was obviously too big for me to do. Then go ahead and do it, learning everything I needed as part of the doing. (I am retired, but still curious about things tech. I just subscribed to your channel to see what other stuff you have to say.)
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!
All are good points. Number five is the best.
When I started software development, I hated mistakes. As I became a better Engineer, I learned to love mistakes. They were opportunities to review my thinking and solution skills. I found that being forced to review my work and find errors made me a better Engineer. It made me consider the re-useability and clarity of my software. It taught me how to design and implement better software.
For me, it wasn't enough to build a project solution. It was just as important to provide a solution which was easy to understand by another engineer. Self-documenting code and methods no larger than one screen length became big considerations.
I began to look at my design and translation to code to be an artistic endeavor. That there was no reason for engineering solutions to be terse and abrasive.
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 😂😂
new generations of kids learning coding: YT videos about "Master X programing language in 2 minutes" + chatGPT + ctrl-C + cntrl-V
😞😞😞Why say naked truth like that, I used that on my project writing on latex but one day I stopped and started learning.......
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). :)
I love the way you are telling the truth about doing ANYTHING, including learning something. By asking the "W-Questions" first, and once you have a good idea of "What" you want to do, "Why" you want to do it, "When" you should do it, and "Where" you should do it, (even "Who" should do it) then you can move on to the "How" to do it. Everybody is always asking "How do I do this, instead of What should I... When, Why, Where, Who...??
Great advice you are sharing here. Thank you.
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.
100% agree with you. I didn't learn the syntax as my first step. The first thing I set is the problem I want to solve, e.g. trading automation. Then I went through learning how my brain make every single decision in this specific task, break it down into several steps, and then googling/youtube how to perform every step from completely scattered tutorials. Gather those puzzles, assemble them, and then voila I get 1 portfolio that I can revisit to create another one. Trust me, the learning curve is only steep at the beginning of our process. Thank you!
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.
The first 16 seconds of the intro explained exactly how I felt when I was going to university studying computer science at the age of 30. I had just gotten done with all of my required math (calc2, discreet mathematics and engineering statistics). I finished my first coding semester (Java) and felt pretty good. My second coding semester introduced linked and double linked lists, and I felt like I hadn't learned a thing about coding. Meanwhile, there were 18/19-year-old "coding geniuses" around me who understood the syntax and logic without issue. Some of them had been coding since middle school. I felt like I was too old, lacked years of coding experience and too stupid to catch up to their level. I quit university a semester after that. How wrong I was. They warned us of imposter syndrome in the coding field. I should have never given up. I am now relearning how to code at 32 years of age. I won't give up this time. Genius or not, I love using logic to put together and solve the complex problems that make up programs. I love coding. Don't give up guys!
Well said. Coding is not programming. Programming solves problems; coding is merely structure. Both are needed but programming is the greater skill.
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 : )
The most lucid and useful description I've seen in sone time. I don't write code, but I've hired dozens of people who do. I wish more applicants had taken this approach
The hard part when learning to code is that it's catch 22 situation a little bit. When I first started I made the huge mistake in believing I had to understand every little piece and parts of the code, know what every little keyword meant etc, before I could move on to learning the next thing, and that made the learning process so much more difficult. Everything seemed very abstract because I couldn't relate to any of it, it's just gibberish at that point. Eventually I realized I had to take some time to just learn the syntax by writing various types of code over and over until I knew exactly _how_ to write a constructor class or a setter class or whatever it was, even though I didn't really understand how it worked or what these characters really meant. Just learning the syntax "upfront" like this, was a massive help to me.
This is awesome I would definitely recommend future programmers to this video!
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.
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!
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
As a developer for over 20 years, I have to say, these are good advises.
Excellent summary of my 30 year career as a software developer. These are the nuggets of advice I try to teach both junior colleagues and friends who want to get into programming. This video explains these 5 points much better than I ever managed to do.
"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".
Exactly! I'll build whatever it takes, but I don't even know what's worth it to build. There are basic projects, sure, but those have little correlation to what it seems people need coders for
Exactly!
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!
The algorithm today blessed me . Nice video
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.
🎯 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 ❤
After going through probably 20 videos you gave the best advice in the shortest amount of time. Thank you! Amazing.
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.
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.
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
Sister, I would usually skip short videos like this one but I am glad I watched. Learn to code before coding language was the biggest idea that helped me. Thank you so so so much!!
Lesson #1 Work hard. .....Alright, let me stop you right there. ✋🏼
Prioritizing the understanding was huge one for me. At first it felt like I was learning at a slower pace than my peers, but after awhile it seemed like I had a more advanced understanding so I was more equipped to help myself and solve issues on my own. It also gave me a lot more room for creativity.
I personally believe those who refuse learning math and calling themselves programmers by writing some code to join a bunch of dependencies are the most prone to losing their jobs to AI, they should be scared far more than those who are comfortable thinking mathematically
There’s a podcast that spoke about Ai and future of works on “talk with pecs “ channel ❤
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!
"No discomfort, no expansion." Ok2 noted!
number four is everything for me right now. I'm hoping that gut abstract grasp of things you mention will come for me in time, because right now it feels like I am looking up a sheer cliff face, nevermind 'learning curves'.
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.
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.
i agree with all (each has their own path and taste)
You are killing it!
Thank you, what a great work, keep going ❤️
I find Jackson Structured Programming (JSP) still valid and a great help.
Also ”You don’t understand a problem until you can simplify it”
Also “you don’t program programs, you BUILD programs” has influenced my thinking for the better.
[1:30] This is what the programmer Andy Harris recommends to avoid the programming language trap.
It is certainly good to know those five things. I have always found programming interesting and although I did not officially work in that field, had times both at work and at home where a project required me to program. I can certainly say it is best to have a project/goal to work towards as this gives you the "doing" part where you can begin to learn from your mistakes. Once I got the program to actually work the way I wanted, I would review the program to see if I could use less lines of code for the same results, which I often could. The other thing I did was leave plenty of remarks in case I or someone else had to come back to it to make any modifications. I learned this after believing I could remember what I did only to come back to the program months later and not have a clue as to why I wrote certain lines of code. Because I don't do this as a career, I often have to refresh my memory on certain aspects, but luckily certain aspects seem to be etched into my brain. I have learned several different languages and I can only say that when you understand how to program and learn just one language, other languages become far easier to learn.
No matter what language you learn. For your first project learn how to build and search a database for your snippets. Use the same language you are learning to do it. Use notes and comments in the database. That is the best lesson you can give yourself and you will use it as long as you progpram.
Great video!
Thank you Tim!
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! :)
One other encouragement is to understand the coders in tutorial videos and classroom instruction are working with code they know very well because they have prepared by essentially memorizing much of the code. They appear to be wizards b we cause of this.
Very Very Great And Useful. Thank You.
Glad it was helpful!
Remember that stack overflow doesn't allow questions, mainly cause everything has already been asked and you need to be very specific in how you ask or they will censur/edit your question so it no longer asks what you wanted to know. This happened to my twice, and ended up being ignored by the user base. Yes, my questions had been asked before but not for the language I needed to use in those specific projects. So the moderator generalized the question and removed important parts for my language and ... yeah... Stack overflow is still a great resource though. But don't expect to add anything new to it.
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 👊!
If you're trying to understand the underlying concepts of programming (and even computing in general) without being tied to a language, I recommend The Computer Programme from the BBC (1982). This will bring you back to first concepts and let you understand everything from a zoomed-out perspective, instead of being tied to a modern language.
Start seeking failure. Love it. Good tip. I have a lot of opportunities for this one. Its how I learned Rust which I did not think possible. 😅
I have been a developer for years, old school, and I am impressed by your maturity and deep understanding of the necessary pedagogy.
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.
Excellent content, solid advices, loved it! Thank you.
6:32 Back in the 90s beginner questions were replied with simply “RTFM” in forums. Which stands for Read The F*** Manual
You've used a simple English that makes me to understand what you are talking. Thank you God bless you.
Programming is HARD and it's not for everyone, being good programmer is like being good at chess. Programming is harder than learn a new language. The majority of people only speak one language.
programming is hard, but not impossible
Hahaha try lo learn an old language and you will notice that programmers are not the smartest people on earth
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.
First 😅
Good Job
Simple but spot on , 1 What , 2 How , 3 Why,
logical evaluation and simple logical thinking what your doing ,and How are doing it [in real time] , and for why yor are doing it to , & if you have a time revaluation and think to yourself "what else" can be done better
or just a step & sit back for what you done by yourself and appreciate it ,for that
doing mistakes will be a new lesson to learn
Good points. To the 1st point (learn by doing), one sub-task is to learn how to *test* ideas, programs and experiments (TDD, test driven development).
That will help setting the right context, answer the "why" questions and help focusing on the problem to solve. It might also help with the later packaging, deployment and production phases.
Understanding is key. I so agree with 2. the difference between programming and a programming language. If you have your algorithm worked out, you can go to any language and output your program.
Something I like to do when I'm learning how to do a task, like say an R script for training a random forest model for plant species Identification, is to take code written by someone else and 'reverse engineer' it (with permission). Where I can take each function in a loop, or each library being called, and search through the documentation to figure out what each of those functions are doing and puzzle out how they piece together to get the final product.
It can actually be great fun if you have the time.
If I'm coding from scratch, let's use the same example as before of a machine learning model for predicting plant species based on multispectral drone imagery. First off, we can research what kind of machine learning algorithms are out there, which will determine which programming language we will use, whether we want to make a deep learning model or a classic ML model. Do we want the advantage of GPU acceleration at the cost of a steeper learning curve, or do we use an easier to learn library like MLR3 in R or SciKit-Learn in Python?
A bit of a rambley comment I suppose, but it basically, all comes back to that first rule you talked about, "Learn by Doing". Come up with a project, it could be as simple as printing "Hello World" in the console, or as complex as a LiDAR analysis pipeline. It's all about setting finding a goal that you want to accomplish, learning the steps that you need to take to reach that goal, and then accomplishing each step. If you don't have a goal or purpose however, you're never going to actually learn anything.
Nice with a knowledeable woman who comfortable told these points. Thanks for uploading this video.
I can agree. Learning the core of programming is learning how to solve real-life problems with code. Abstraction is key. Notice patterns in your code. A lot of problems can be solved with relatively similar code. There are industry standards for solving certain problems. Learn them. Never use code from someone else wich you do not understand.
been a programmer for like 10 years now and i have told young programmers about understanding the program rather than the language but this is what you master as you progress most young people dont listen to such advise they want quick results until after some time they begine to understand. but this is Ouwsome > I would also recommend them a book for structure and interpretation of computer programms
"Hello World" is the usual quick result to feel energized by it.
Great advice. Thanks for posting.
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.
that first one is so true, i am now putting in the work and finally getting it, you have to get your hands dirty and just do it
Excellent advice. Thank-you
Implementing the math is the crazy part which is a crucial factor in devising an algorithm.
The algorithm is meant to sort out the datastructures by performing functions like search, add, delete, etc.
I use w3schools offline version
I learned when I was 12. I read some code, wrote it, ran it, and understood why it happened. Then I learned some more, rinse and repeat. When an error happened, I instantly knew where the mistake was. More learning, simultaneous with programming. I just had a comprehensive and easy to read book. No Internet back in 1985.
The fundamental problem with software and systems development is communication and the ability to see the big picture and as the same time dive into details is key. And rare.
This is such a good video. The great thing is you can apply this approach to many things in life, not just programming (I’m not a programmer). Well done!
Glad you made the distinction between learning to program and learning a language.
I often use the analogy of writing a book. I know English (fairly well lol) , I know what the words mean , how to spell some of them etc..
I couldn't sit down and organize all those words into a good cohesive grammatically correct novel.
Knowing why you're using certain words in a certain order is essential to understanding how to make everything work together.
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.
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
And nowadays chatgpt can be utilized especially with prioritizing understanding!! You can enter in the programming that didn't work, explain what you are trying to accomplish with it, and ask for a solution and explanation in "terms that a child (teenager, data professional, c-level manager) can understand."
Great video, great presentation. Yes, understanding is definitely the key. Thank you!
I agree. Very well explained.