Programming Self Improvement

7 Useful Tricks for Mastering a New Programming Language

Joel Lee 12-02-2015

Programming is hard. The only folks who say otherwise are the ones who have years of coding experience under their belts. It’s okay to be overwhelmed! There’s a lot to learn and you’ll probably forget things as quickly as you learn them. Trust me: that’s normal.


But just because it’s normal doesn’t mean that it isn’t frustrating. Truth be told, learning how to code How to Learn Programming Without All the Stress Maybe you've decided to pursue programming, whether for a career or just as a hobby. Great! But maybe you're starting to feel overwhelmed. Not so great. Here's help to ease your journey. Read More can be extremely stressful if you don’t approach it with the right mindset and attitude.

You want to learn that new language or library or framework as soon as possible, right? That’s understandable. Fortunately, there are a handful of tips that can help you to better retain all of that heavy programming information that keeps flying in one ear and right out the other.

No More Cram Sessions

Nobody wants to hear it, but cramming is the worst way to learn how to program. If you’re anything like me, cramming was your modus operandi all throughout school and university. It’s the only way you know how to study.

But learn from my mistakes: the more you try to cram, the less you’re going to remember. That’s pretty much true for any knowledge-based subject, but it’s especially true when it comes to programming.

The basis of this claim comes from a 2008 study by the University of California, San Diego:


“Students perform better when they space their study sessions rather than when they try to cram everything into their noggins during one sitting.”

Why? Most likely due to the serial position effect:

“Serial position effect is the tendency of a person to recall the first and last items in a series best, and the middle items worst.”

In other words: in any given study session, you’re more likely to retain the information that you learned near the beginning and the end of the session and more likely to forget the information from the middle of the session.

You want to maximize the number of beginnings and ends. That’s why it’s better to have multiple short sessions instead of a few long sessions when it comes to learning and absorbing new material.

The next time you sit down to learn code, take it one topic at a time and take a short break between each topic. (Just make sure to prevent your breaks from turning into procrastination!)


Review, Review, Review

Another reason, why cramming is antithetical to long-term knowledge retention is because memory fades over time. This isn’t always true — I’m sure we all have a few childhood memories that will never disappear — but it seems to be the general case for memories that aren’t tied to emotion.

There is some debate whether memory itself decays due to time (decay theory) or simply gets pushed out and replaced by new memories over time (interference theory). Whichever theory you subscribe to, the result is that older memories are more likely to fade away.

This is where review comes into play.



Think of it like walking through a forest of memories. Every time you want to access a memory, you have to trace the neural pathway in order to find it. Each time you trace that memory, the pathway gets etched in a little more — just like how a dirt pathway naturally forms when people walk the same path over and over. If you stop walking the pathway, it can fade away and the memory ends up lost somewhere in the forest.

Setting aside all of the pop psychology, here’s the takeaway: when it comes to programming, it’s not enough to learn a topic just once or twice. You have to revisit it dozens or even hundreds of times. Each review etches that topic into your brain a little bit deeper.

I know how hard this can be if you’re a natural crammer, but you’ll be surprised how fast you start retaining material once you make an effort to review it regularly.

Use Several Different Resources

The toughest aspect of programming — at least for brand new coders — is the sheer breadth of details and nuances that need to be internalized. Until that internalization happens, you’re going to be in a perpetual state of head-scratching.


Depending on the language, you’ll need to memorize hundreds of syntax rules (e.g. keywords, semicolons, whitespace). Some languages are stricter, others are less so, and still others have their own unique approaches to syntax that aren’t used anywhere else. All of this can be confusing if you have no prior coding experience.


Not to mention all of the conceptual information that transcends individual languages. Topics like object-oriented programming, entity-component systems, and observer patterns can really make your head spin the first time you try learning them.

I’ve shared this illustration before, but it’s so on-point that it bears repeating:

“Suppose someone showed you a photograph of a statue. It might provide enough of an image for you to get an adequate sense of the statue, but you wouldn’t get the whole picture. A zoomed-out photo would lose intricate details while a zoomed-in photo would lose a sense of perspective. However, with additional photographs taken from other angles, you can really start to see the fullness of the statue in texture, in size, in detail, from front-to-back, side-to-side, and top-to-bottom.”

Learning to program can be surprisingly arbitrary. Everyone might praise Resource A as being the best way to learn Language X, but maybe it makes no sense to you. Maybe everyone hates Resource B but you take one glance and it makes perfect sense! As for someone else, maybe they zone out when studying Resources A and B but benefit greatly from Resource C.

That’s why it’s so important for you to be willing to consume all kinds of resources out there. Everyone learns in a different way. If you’re having trouble with a particular topic, search around for another resource. Maybe that one will be more suitable for you. Maybe not.

Even if you think you understand certain topics, it’s possible that there’s more to learn about it. It’s also possible for someone else’s explanation to solidify the concept in your mind for good. You never know, so why not consume as many resources as you can?

Note that games can be a critically useful resource! Check out these fun and educational coding games The 9 Best Coding Games to Build Your Programming Skills Coding games help you learn faster with hands-on practice and experience. Plus, they're a fun way to test your programming skills! Read More .

Teach Concepts as You Learn Them

There’s a beautiful concept in programming called rubber duck debugging The Weirdest Programming Principles You've Never Heard Of The following principles will teach you to be wise with your code. Some are strange, and many are humorous, but they're all equally practical and important. Take heed! Read More , which describes the technique of explaining one’s code, line by line, to an inanimate rubber duck. It’s used when a particular segment of code is broken, but there’s no obvious reason for it.

Strangely enough, most programmers have a “Eureka!” moment in the middle of explaining the code as they suddenly see where the error in coding logic occurs. Verbalization triggers a different area of the brain, forcing you to see the problem from a new angle.

This concept can also be used to help you learn new material. You may have come across this popular quote that’s often attributed to Albert Einstein:

“If you can’t explain it simply, you don’t understand it well enough.”

With the exception of some fields that deal with advanced theoretical knowledge, this saying holds true. The more you understand a topic, the better equipped you are to explain it in such a way that someone who has no knowledge of said topic can still come to understand it.


The opposite of this is true as well. As you try to teach a topic, you’ll come across certain concepts that you can’t seem to explain in a clear manner. Not only is this an awesome way to diagnose weaknesses in your knowledge, the actual process of finding the proper explanation can help solidify the concept in your mind.

It’s called learning-by-teaching and it’s basically a twist on rubber duck debugging.

Now, I’m not saying that you should actually teach others; rather, every new programming topic that you learn, try teaching it to a rubber duck (or an invisible friend). It may feel silly at first, but you may find it incredibly fruitful when it comes to memory retention.

Deliberate Practice Makes Perfect

The notion of talent is complete rubbish. Nobody exits the womb as a world-class violinist, wrestler, or programmer. Sure, some people might be more inclined towards certain disciplines, but talent without experience is useless Don't Let Your Hidden Talents Die: 7 Ways To Go & Find Them Again The bad news is that you have to work hard with intention to polish your hidden talents. The good news is that there are more opportunities than ever to spit-shine your talents. Read More . Similarly, hard work is always more valuable than talent.

That being said, not all forms of hard work are equal. Malcolm Gladwell coined the infamous 10,000 Hour Rule, which says that you must invest at least 10,000 hours into a subject in order to become a master at it. While the sentiment may be true, many people misinterpret what he was trying to say.


Long story short, a 10,000 hour commitment doesn’t actually guarantee mastery. You know the saying: “Practice doesn’t make perfect. Perfect practice makes perfect.” In order for it to be meaningful, practice must be intentional Want To Become An Expert At Something? Try Deliberate Practice It's all too easy to feel crestfallen when you're arduously trying to improve a certain skill. Use the power of "deliberate practice" to get you over those infuriating plateaus. Read More . Mastery can only be attained through 10,000 hours of deliberate practice.

How you practice matters far more than how much time you spend practicing.

Reading is passive. Watching YouTube lessons is passive. Listening to podcasts is passive. As a newbie coder you might be tempted to flutter from tutorial to tutorial, tackling subject after subject without actually applying any of that knowledge in a practical way. Resist this temptation.

It’s one thing to understand an example before you, but it’s another to synthesize a solution from scratch. If you want to speed up the learning process, you must be willing to be active instead of passive. Active practice is the only kind that matters in the end.

Experiment With Personal Projects

For me, homework was the worst part of school. It just seemed like an elaborate ploy to kill fun and keep students busy — which, to be fair, was sometimes true. But now that I look back, the importance of homework finally makes sense. It forced me to apply newly acquired knowledge in an active way.

If you’re enrolled in programming courses and classes The 11 Best Sites for Free Online Computer Programming Courses Using these free online computer programming courses, you can become a great coder without a computer science degree. Read More , don’t underestimate the efficacy of homework. Take it seriously, always treating it as a chance to further cement what you’ve learned into long-term memory.

But many times, homework still isn’t enough. (And if you’re learning how to program on your own without an actual instructor, you probably don’t have any homework to begin with.)


What’s the solution? Create a couple of throwaway side projects!

Think of a few project ideas 5 Project Ideas To Help You Learn Programming Faster There are a few ways to ease the learning curve for programming. Get your hands dirty and learn faster with side projects you can start anytime. Play around with these five. Read More that you’d like to implement. For absolute newbies, you might consider a game of Tic-Tac-Toe or Hangman. For seasoned programmers trying to learn a new framework, try coding a simple mobile app or web game. As long as it interests you on a personal level, go for it!

The beauty of this approach is two-fold.

First, it’s more likely to hold your attention. Studies have shown that students learn better when they can pursue topics that interest them. That’s exactly what a personal project offers. You have an end goal that you actually want to achieve, thus you’re more likely to retain the information that’ll get you there.

Second, there’s no pressure for you to succeed. While success would be nice, the lack of formality allows you to be experimental and creative. You’re inevitably going to run into issues, but it’s more like playing with Lego than it is homework. It’s more fun and not as stressful.

Relax & Bookmark Everything

The truth is that no programmer remembers everything they’ve learned. Even after you’ve been working with a particular library or framework for a while, it’s not uncommon if you can’t recall every function or variable off the top of your head.

In fact, trying to memorize everything might just end up being a huge waste of time and effort. Reference sheets exist for a reason. Why commit an entire encyclopedia to memory when you can just flip it open whenever you need it?


So, when to memorize and when to reference?

When it comes to conceptual material, always internalize it to the best of your ability. By that I mean understanding the theory even if you can’t convert it into actual code (and theory should be clear enough to you for you to teach it clearly).

For everything else — such as specific function names, parameter lists, or even language quirks — I wouldn’t worry about committing to memory. Feel free to defer to a reference sheet. Sometimes you’ll reference something so often that you end up memorizing it. If that happens, fine. If not, that’s fine too.

Personally, I have hundreds of Internet bookmarks to various APIs, guides, and tutorials. If I need to implement some kind of pathfinding algorithm, I might reference a guide to help me get it coded before forgetting about it again. It helps to understand the underlying concepts, but I try not to fret about implementation details.

Final Thoughts

I’ll repeat it a million times if I have to: programming is hard and it’s okay if you struggle with it. I’ve been programming as a hobby for over a decade and I still find myself intimidated when I have new concepts to learn.

Don’t beat yourself up if you can’t remember everything right away. The above tips will hopefully prove helpful to you, and even if they don’t, you can always rely on bookmarked references as a last resort.

Do you find programming difficult? What kind of tricks and tips do you know that might be helpful to newbie coders? Share your wisdom with us in the comments below!

Image Credits: Binary Programmer Via Shutterstock, Memory Eraser Via Shutterstock, Obfuscated Code Via Shutterstock, Rubber Ducky Via Shutterstock, Keyboard Typist Via Shutterstock, PHP Source Code Via Shutterstock, File Folders Via Shutterstock

Affiliate Disclosure: By buying the products we recommend, you help keep the site alive. Read more.

Whatsapp Pinterest

Leave a Reply

Your email address will not be published. Required fields are marked *

  1. John
    March 22, 2018 at 1:23 pm

    Some of the tricks I do is watch a lot of tutorials on Youtube on how to learn a new language or build an app. I learn best by doing. I also go to Github and read other's codes. I think the key in programming is you must be a good reader to understand and follow the instructions.

  2. Duncan
    September 4, 2017 at 2:59 pm

    Memory doesn't decay or get replace. It becomes hard to access without context.

    Read " The Brain That Changes Itself' Norman Doidge.

    I remember coming back to my software dev diploma and finding certain parts of it alot easier to grasp and bring to the fore-front of my mind once I had a better understanding of object oriented programming with which to understand what I had been learning and to recall it later.

    Duncan A

  3. Moses
    October 26, 2016 at 2:24 pm

    Very nice article, I barely started learning to code and it's been driving me crazy on where to start. Not only that just retaining the information is very hard for me. I cram and cram, but I never get nothing out of it. I forget everything by the time my wife ask what I learned, I'm a person that learns by repetition, but I hate going over it and over it. Repetition is boring to me, so there's two obstacles I have to over come. I forget everything too, so through out life I find myself writing everything down and that helps me out a lot. I love this article and thank you for taking the time to write it. I think it will help in my process of learning to code!!!!

    God Bless!!!!

  4. Shivam Mantri
    October 14, 2016 at 8:21 am

    Thanks a lot for this article. It gonna help me learn better. :)

  5. Masih
    June 25, 2016 at 8:33 pm

    Thank you so much for sharing your great experience. I personally learned programming by myself, by debugging, by mistakes and Open source projects, They can be very useful.
    Another thing that you should add to the above list is Open source projects because as well as you know they can help a lot for learning new tips and improve programming process.

    • Joel Lee
      July 4, 2016 at 1:46 am

      Yes! Open source projects may not be great for absolute newbies, but for intermediates who are comfortable with the core of a language, open source projects can be a fantastic way to sharpen one's skills even further. Thanks Masih!

  6. mohnish
    June 22, 2016 at 10:10 am

    REally inspiring bro

    • Joel Lee
      June 24, 2016 at 2:03 am

      Thanks mohnish! Glad it was helpful to you. :)

  7. Tamara
    May 12, 2016 at 2:12 am

    Joel, *suPERB* summary of the best ways to learn a programming language! These apply to many other skills as well, of course, but teaching programming is my current love. This is a really well-written article I can share with them. Thank you!

    • Joel Lee
      May 23, 2016 at 3:43 am

      Wow, thanks for the kind words Tamara! I'm so glad to hear that and I hope it proves useful for your students. :)

  8. kuna
    April 16, 2016 at 3:37 pm

    Thanks a lot it's very useful

    • Joel Lee
      April 18, 2016 at 10:10 pm

      You're welcome! Glad to help, kuna. :)

  9. reka
    March 7, 2016 at 4:48 pm

    one of the best article I have ever read about learning to program..seriously!I have been trying to learn a few programming courses in the past few months and gave up ..this article really made me think about where I am going wrong..

    • Joel Lee
      March 14, 2016 at 8:19 pm

      Wow, thank you for the kind words! I'm glad it was helpful, reka. Hang in there and good luck! :)

  10. charlie
    March 6, 2016 at 2:19 am

    I want to become really good at my work especially in technology

  11. charlie
    March 6, 2016 at 2:17 am

    I feel so happy this was really helpful

    • Joel Lee
      March 14, 2016 at 8:19 pm

      Thank you, charlie. I'm glad I was able to help in some way. :)

  12. Anonymous
    November 9, 2015 at 1:45 pm

    I really loved the article , it cheered me up , cause for me , as a computer engineering student , when I see my mates doing such amazing things with their programs , and I can't event make good littles programs , I think that I'm really far behind , but after reading this , I saw that I was using these advices by instinct , so now , I know that I'm on the good road to be a good programmer.

    • Joel Lee
      November 11, 2015 at 3:15 am

      Nice! Keep it up, Amine. Programming is a hard road, and in the end, it's more about hard work and perseverance rather than natural talent. :)

  13. Anonymous
    November 9, 2015 at 12:36 pm

    feeling great, after reading this article. thanks

    • Joel Lee
      November 11, 2015 at 3:14 am

      Glad to hear it was helpful, Drill Plantan! :)

  14. Bill Droogendyk
    February 17, 2015 at 2:35 pm

    Best line in the article: "If you can’t explain it simply, you don’t understand it well enough".

    • Joel
      February 18, 2015 at 2:35 am

      I love it too. It's what I use to gauge my understanding of various topics and it really helps illuminate how much I still need to learn. :)

  15. Bill Droogendyk
    February 17, 2015 at 2:31 pm

    Best line in the article: "If you can’t explain it simply, you don’t understand it well enough".

  16. Anthony Butler
    February 14, 2015 at 9:24 am

    A very good article on a subject that is close to my heart, teaching programming. Programming came easily to me over 30 years ago as I understood set logic from maths class. As I've grown older, and as my career in IT has destroyed my interest in the art it has become more and more difficult. Reason? Because I'm not engaged properly with the subject anymore. Now I'm trying to learn again, this time with a computer device that does more tan scroll "hello world" endlessly, a Raspberry Pi. I knew all the ideas from this article, of course I did. But I'd forgotten them. So with this timely reminder, I shall fire up the old gret matter anew. Thank you for reminding me, I like programming, I'm actually quite good at it.

    • Joel
      February 18, 2015 at 2:34 am

      Awesome, Anthony! Rediscovering a lost love is always great. I'm sure the IT world has evolved a tremendous amount over the last 30 years but I think you'll do fine as far as catching up. Which languages and projects do you intend to learn and tackle? Let us know how it goes!

    • Anthony Butler
      February 18, 2015 at 8:08 am

      So far, Python and whatever language the Arduino uses (C#?). Unlike the `good old days` with these modern devices like a Raspberry Pi and Arduino, interfacing to the outside world of sensors, motors and actuator is a lot easier to understand. So far I wired two stepper motors to my Pi and set one to show the hours and the other to show the minutes. Took some doing to work out how to get the time data converted so I could use it, thanks to pythons very complicated 9-part data structure for date/times. I`m now constructing a simple GUI using pygame for simple control and adjustments.

  17. Joe
    February 14, 2015 at 5:25 am

    I like to accumulate code snippets and functions which do something I may need again. Then, all I have to do is find the snippet (hopefully commented!) and I'm good.

    I write a lot of tiny howto text files for things. I have at least 15 for dealing with package management issues using apt/dpkg. This way, I can remember what I just figured out.

    I have also experimented with writing text macros which expand into the basic syntax of a programming command, but haven't been too successful with getting them to work correctly in my text editor (Kate). I use AutoKey in Linux for this, but similar programs like AutoHotKey also exist for Windows. Macs have Automater, but I'm not a Mac guy.

    On the macro level, it's almost always more important to figure out "what" to program than "how" to do it. It doesn't help if you solve the wrong problem!

    • Joel
      February 18, 2015 at 12:26 am

      Thanks for sharing. I'm going to try applying your code snippets tip, which will probably be very handy for me. But I really like the last part about "what" to program rather than "how" to program. The right "how" can apply to many different "what" situations!

  18. MEZDAC
    February 14, 2015 at 12:06 am

    Very interesting article. I really like its content especially regarding memory.

    • Joel
      February 18, 2015 at 12:23 am

      Thank you. I'm glad you liked it! I hope it helps you. :D

  19. 35 years of coding
    February 13, 2015 at 3:47 pm

    Experts born by making a huge amount of errors and learning along those!

    • Joel
      February 13, 2015 at 7:54 pm

      Absolutely! Programming is all about fixing mistakes, day in and day out.

    • Abdul Quadir
      February 14, 2015 at 4:01 am

      Some great personality has said, "The sooner you make your first 5000 mistakes, the sooner you'll learn how to fix them". Don't you think it's right?

    • Joel
      February 18, 2015 at 12:21 am

      @Abdul: Absolutely, I agree 100%. There's something similar in the writing world: "Your first million words are going to suck, so you better get them out of the way." That mindset really helps with fear of failure.

  20. Hildy J
    February 12, 2015 at 11:50 pm

    Three suggestions from one who started on an IBM 1401.

    First, understand the philosophy and concepts of a language. For example, is it procedural, object oriented, etc. and how does the language think of those concepts.

    Second, learn a diagramming method that fits the language and use it before you code. Figure out where the unexpected can occur and change your diagram to accept to accept it. For example can you get in an infinite loop or try and divide something by zero.

    Third, understand your data and plan to verify it. I mean, seriously folks, I learned to avoid buffer overruns in my COBOL class in 1970. And yet, much malware uses such overruns to maliciously insert code. Even without evil intent, users are a perpetual problem - you ask them for Y or N and they enter X.

    • dragonmouth
      February 13, 2015 at 3:04 pm

      "And yet, much malware uses such overruns to maliciously insert code"
      Much of the blame for that has to go to the languages being used. As we have advanced through the language generations starting with machine language, commands became more imprecise because they began to represent more and more complex macros and subroutines. One "move" command in COBOL could require 4 or 5 Assembler commands (MVI, MVZ, MVO, MVC) to accomplish the same result. In COBOL you need to write a routine to edit the data type. In Assembler the command itself performs the edit.

    • Joel
      February 13, 2015 at 7:53 pm

      "First, understand the philosophy and concepts of a language. For example, is it procedural, object oriented, etc. and how does the language think of those concepts."

      Important and often overlooked. As an example, I've been learning Ruby recently but I have a hard time "thinking in Ruby" so to speak. It's way different than something like Java, and while I could write Ruby code using Java paradigms, it'd definitely be better to write Ruby using Ruby conventions.

  21. BvrOv399-0
    February 12, 2015 at 11:44 pm

    Hi, could someone (Matthew) explain what "Understand the difference between programming and coding." means? I just want stuff I type to do something.. I don't care if it's 'pseudocode', a programming language, or a table saw. I'm just confused.

    • Joel
      February 13, 2015 at 7:48 pm

      I think he may be talking about the nuances between "computer scientist" and "software engineer". One focuses more on the theoretical application of algorithms, patterns, etc. while the other is more hands-on with the code and bringing those ideas to life.

      The best programmers are BOTH, but most newbie programmers tend to focus on the code itself and not as much on the thought behind the code, which is a mistake.

  22. Matthew
    February 12, 2015 at 10:54 pm

    Understand the difference between programming and coding.

    The high level overview, flowchart, pseudocode are (mostly) independent of the actual programming language - though may be influenced by the availability or ease of certain language features.

    You should have that overview before you put a single thing down in code, pre-documenting what you want the code to do, rather than post-documenting what it does.

    Longform COBOL is somewhat self-documenting, but when I learned COBOL, I generally wrote shortform, missing out all the optional words.

    Also learned Rapidgen RPL - and found the option to look at generated assembler code interesting, as certain language construct coded a lot more efficiently than others

    • Joel
      February 13, 2015 at 7:51 pm

      "You should have that overview before you put a single thing down in code, pre-documenting what you want the code to do, rather than post-documenting what it does."

      This is something I agree with in theory, but it's a lot easier said than done. Most of the time, I'm just so eager to jump into the code and I end up regretting it somewhere down the line.

      Every architect needs blueprints. Programmers could learn something from them!

  23. dragonmouth
    February 12, 2015 at 10:21 pm

    " I’ve been programming as a hobby for over a decade and I still find myself intimidated when I have new concepts to learn."
    Therein lies your problem. There has to be an imediacy to your learning. Hobbies always take longer to master than work.

    When I got my Apple II, I tried to learn 6502 Assembler. There was no need for me to know it, it would have been a hobby to know how to use it. OTOH, it took me about 6 months to become proficient in IBM Assembler. I HAD to learn it for my new job as a System Programmer.

    • Ike
      February 13, 2015 at 10:10 am

      I am totally agree with you. There is a big different doing it for a living then doing it as a hobby.

    • Joel
      February 13, 2015 at 7:45 pm

      Very very true. Some combination of practical use + a deadline is necessary if you REALLY want to learn something quickly.

  24. Leopardmask
    February 12, 2015 at 9:02 pm

    I haven't done any coding in a while, but for basically everything else the rubber duck method works great! Usually I talk to my mom if she's around. I explain what I'm doing and then I get it. Sometimes I talk to the cat, a stuffed animal, or just to thin air, but thin air doesn't help as often as a physical thing.

    • Joel
      February 13, 2015 at 7:46 pm

      Haha, it's the same for me: thin air just isn't as useful as an object (whether animate or inanimate). I wonder why that is? Anyway, rubber ducking is indispensable as a programmer.

    • prince
      February 18, 2015 at 7:36 pm

      perhaps thats why programmers are regarded as nerdy and antisocial because they find comfort in their "Eureka" or should i say rubber duck. i often do that, however, programmers must be able to put this in check as it can become a behavior and shut ones door to social life and experiences.

    • Joel
      February 22, 2015 at 4:10 am

      Yeah, "rubber ducking" in the wrong context (e.g. when you aren't looking at code) is not something I'd recommend. There's a right time and place for everything!

  25. Von Adam Martinez
    February 12, 2015 at 8:30 pm

    After all, its the errors that makes a programmer the best programmer he could be. We learn from all of those errors.

    • Joel
      February 13, 2015 at 7:43 pm

      I agree 100%. As they say, programming is 10% coding and 90% debugging. It's all about fixing our mistakes!

    • Abdul Quadir
      February 14, 2015 at 3:57 am

      Well said!
      To err is human and we learn a lot more from our mistakes than we do from study.
      Moreover, it's also good to review the basics once in a while.