This will be, in a sense, a meta-guide. I was going to ramble on about how much errors, and dealing with them, are such a large part of programming and how exactly to engage help in this task but I thought it might be better to let other, more articulate, authors give their perspectives. So below is a list of different ideas and the associated links:
Please do also refer to this Guide for Posting Questions in an Online Discussion Forum: http://www.sethi.org/tutorials/faq.shtml#Q&A
REFERENCE: http://users.csc.calpoly.edu/~phatalsk/references/howToFixCompilerErrors.html
Compiler errors happen! The following approach should help you get through them with a minimum of fuss and frustration when they do occur.
Don't write very much code! Well, not all at once anyway. Develop incrementally. Write a little, compile, test (if appropriate), repeat until done. By writing a small amount of code at a time you know any compiler errors you encounter were introduced recently - if you didn't write very much you'll have a better idea where to focus your attention.
ALWAYS ALWAYS ALWAYS fix the first compiler error first (by this I mean the one the compiler spit out first). The first error is almost always a real error. Subsequent errors can simply be the result of the compiler being confused by the first error. It makes an attempt to tell you everything that is wrong but it is not very good at it. As you become more experienced with compiler errors you can dive down the list, ignoring the appropriate ones, and fixing the valid ones. Until then, and especially when you feel dazed, confused, angry, frustrated (fill in your favorite compiler-error emotion here), et cetera, you should fix the first error first, if the second error makes little or no sense, just compile and fix the new first compiler error, if any, repeat until done.
If you can't figure the error out, try commenting out the code you have most recently written until it goes away. Then, reintroduce the commented out code, a bit at a time, until the error reappears. Make sure you understand what specific code caused the error and commit it to memory so that you can avoid that error in the future. This is called learning from experience - very important to a programmer's sanity and success! Maybe everyone's sanity and success for that matter.
Take regular breaks. Especially when you are feeling stuck and frustrated. You'll be amazed how much more fun programming can be if you approach it as an interesting challenge when you are feeling fresh. I, and many others I know, have solved many-a-problem by simple moving away from the computer. Some unconscious part of your mind continues to puzzle over the problem and often solves it for you with little or no apparent effort at all.
REFERENCE: http://www.makeuseof.com/tag/learn-programming-without-stress/
As with most things, you must have the right mindset before learning how to code. Sure, you could make do with a poor attitude and it would still possible to learn stuff here and there, but the process will take longer and you’ll hate it the whole way through.
Programming is hard, there’s no doubt about that. Even the smartest programmers are stumped on a regular basis by bugs and errors in their own code. It might feel as if everyone else knows what they’re doing and you’re the only one who’s struggling, but that’s nowhere near the truth.
Take solace in the fact that everyone has trouble with programming at the start. You are not alone in your struggle. Not only is it normal to be confused and frustrated, but even expected. There’s nothing wrong with you if you find it difficult, so don’t feel discouraged or stressed. It takes time.
And that’s the mindset you need to have if you want to learn programming: it’s going to take a long time. We’re talking on the scale of years. The quickest way to be stressed as a programmer-in-training is to expect instant understanding, instant improvement, and instant results. We’ll see in a later section that it just doesn’t work that way.
Make peace with the fact that the journey before you will be long and arduous.
Like spoken languages, programming languages are vast topics of study that must be learned from the ground up. Consider the process of learning a foreign language like Spanish, German, or Korean.
Start with the fundamentals. The most basic units of any language begin with letters, then words, then sentences. For programming, you have to start with keywords, syntax, and overall program flow.
Don’t worry about advanced material until you first master the basics. It wouldn’t make sense to try writing poetry before you understood the basic rules of grammar, would it? Postpone the advanced stuff until you truly have a grasp on the foundations.
In other words, don’t rush it. Focus on one topic at a time before moving onto the next. By limiting your scope of study like this, you can keep yourself from being overwhelmed. It’s one of the rules of setting effective goals: to eat an elephant, take your bites one by one.
Last word of advice: programming is more practical than theoretical. Not that there aren’t any theoretical aspects (because there are) and not that programming isn’t a cerebral exercise (because it is), but no amount of study will matter if you never put it into practice.
I can’t tell you how many times I’ve spent countless hours reading documentation on a code library that I couldn’t understand, yet within an hour of launching a terminal and playing around with the code itself, it all became clear.
Don’t be afraid to practice by playing around. Launch a blank project and start messing with the code. Fiddle with it, break it, and repair it. None of this is wasted time. You may not be writing code that ends up in a final product somewhere, but you’ll end up saving yourself a lot of learning time down the road.
Programming is not something that can be learned passively. You have to get your hands dirty.Instead of fearing bugs and errors, embrace them. Learn how to fix them or work around them. Practice builds experience, experience builds confidence, and confidence keeps you from feeling overwhelmed or stressed.
For you beginner coders out there, I hope some of this helps. Feel free to ask questions down below. Experts, share your advice with us in the comments! How do you stay stress-free while learning how to program?
REFERENCE: https://www.scotthyoung.com/blog/2012/09/09/learn-to-program/
The key barrier in any learning effort is to surpass the frustration barrier. If you do any programming, a lot of time will be spent debugging. The wrong way to approach this is to get frustrated and quit. The right way is to use debugging as an essential part of the learning process.
I’ve found there are two main types of bugs for programs that aren’t of significant complexity. There’s simple errors, the kind where you misspell a variable name or put parameters in the wrong order. These also tend to be the easiest to fix.
The second type are caused because your model of how the computer works isn’t the same as reality. And while these can be the most frustrating, they are also the greatest opportunity to learn.
My biggest mistake I made in my early days of programming was to only try to get the program working. I would try different approaches and when one worked, I would stick with it, even if I didn’t understand why my previous approach had failed.
Understanding every error can be beyond the ability of a beginner programmer. However, if you endeavor to understand why certain expressions won’t work, or certain algorithms run afoul, you’ll learn much more about the language than the band-aid method I had used in my early days.
Doing this means when you get an error, search for it online and chances are you’ll find a forum posting where someone made the same mistake. Look for the explanations given as follow-up and you can usually see an explanation into the nature of the error.
If the explanation references computing concepts which are new to you, then you can begin trying to learn about those new concepts. This way you can slowly build up your vocabulary of programming problems and designs so that you can avoid such problems in the future.
Much of this advice is programming-specific, but the basic ideas are true for learning any technical skill, be it calculus, statistics, mechanics, chemistry, drafting or design:
Programming has to be one of the best skills I’ve learned, not only because it’s fun and rewarding, but because it teaches a lot of life lessons as well. It taught me how to build things, organize projects and set goals for myself. And, as computers become more integrated into our lives, it’s nice to know a little of the language they speak.
REFERENCE: http://www.programmingforbeginnersbook.com/blog/when_you_know_the_basics_but_you_still_cant_code/
In a recent reddit thread about difficulties faced by beginner programmers, the most common difficulty was getting beyond the basics. People express this problem in a few different ways, such as:
Usually the student completes some kind of online programming course, but feels lost once the course is over.
One contributing factor to this problem is the artificial environment that online courses provide to students. Students are usually typing code into a web page that contains instructions and hints. This is not how real programming gets done. So when the course is over and it’s time to use a real programming environment, students feel lost without the environment that they are accustomed to.
There is a good reason why online courses provide this artificial environment – it’s because setting up a real programming environment is often complicated and frustrating for beginners.
I’m not trying to say that artificial programming environments are a bad! They allow you to gain programming experience without the pain of setting up your own environment. Unfortunately, that pain has not been avoided, it has just been delayed until the course is over.
When you’re completing an online course, or following a book, or even being instructed in real life, you’re being provided lots of hints and prompts that allow you to progress. You might even just be given the answers from the start, or told exactly what to type in. When you try to make a program by yourself, however, you’re just looking at a blank text file – no instructions, no hints, nobody telling you what to type. It’s natural to feel lost when you suddenly jump from one environment to the other.
One consequence of excessive guidance is that students learn syntax without learning programming concepts. Syntax is just the text that you type in for a particular programming language, like if and while. Syntax is different for every language. What you really want to learn are the concepts, like branching and iteration. Concepts allow you understand what the code will actually do, and they can be written in lots of different languages. When someone says that they know about while loops but they don’t know when to use them, that indicates to me that they have learnt the syntax but they don’t really understand the concept of iteration.
Again, I’m not saying that guidance is bad! When you’re just starting to learn, you definitely need someone to guide you. You will need people to guide you at every stage of your programming career. However, receiving too much guidance as a beginner can give you the false impression that programming is easy, leading you to feel disappointed when you can’t write a program on your own.
This is the part of the article where I give you a bit of tough love. Prepare yourself. If you feel that you know the basics but you can’t write a program without guidance, then I’m afraid that you probably don’t understand the basics yet.
You’re standing on what the Viking Code School refers to as The Cliff of Confusion:
The Cliff of Confusion is the painful realization that it’s a lot harder when the hand-holding ends and it feels like you can’t actually do anything on your own yet. Your primary challenges are constant debugging and not quite knowing how to ask the right questions as you fight your way towards any kind of momentum.
If your studies have been challenging up to this point, then this won’t come as a shock to you. If, however, you’ve been breezing through a programming course and got the impression that programming isn’t that hard, then this might feel like a punch in the gut.
It sucks, but you’re not alone. Everyone has to go through this stage if they want to become a programmer.
It’s going to be frustrating at times, but let’s look at some strategies to push through this phase.
Now is the time to go through the pain of installing and configuring a real programming environment. Each programming language requires a different environment.
First, you need a text editor or an IDE (integrated development environment). Find out what the most popular editor is for the language you are learning, and install it. You should be able to find one that is free.
Secondly, you need to work out how to run a file that contains code.
If you’re using an IDE as your text editor – like Visual Studio, Xcode, or Eclipse – then this functionality will be built into the IDE. Discover how to make a new project, and what buttons to click to run the code.
If you are not using an IDE, you will probably need to learn how to run your code from the command line. The command line will take a while to get comfortable with. Look for “getting started” instructions for your programming language, and also check YouTube for instructional videos that you can follow.
Once you can write code, save it to a file, and run the file, then you are ready to rock. This is how professional programmers write code every day.
You have to start writing your own code, without instruction. Start with an empty file, and type every line of code yourself.
This is going to be really difficult at first. You will spend a lot of time debugging, and trying to understand error messages, but that is the point. Every time you investigate and fix an error, you are gaining real programming experience. This is how you learn and grow.
You can look at other peoples’ code, but don’t copy and paste it. If you paste in the code and it works, you haven’t learnt anything. If you paste in the code and it’s broken, you won’t be able to fix it. Analyse other people’s code, learn a little bit about how it works, then write it yourself.
It’s fairly common to try to make something well beyond your skill level. This isn’t necessarily a bad thing. If you find it interesting and motivating then it will force you to learn a lot, including the fact that your MMORPG project is going to take many years to finish. It doesn’t matter whether you finish, as long as you’re learning along the way.
On the other hand, if you’re demotivated, confused, and making no progress, then you need to start with a much smaller project. At the beginning, you will usually be writing text-based programs because they are easier than everything else. All you need to know to make a text-based program is how to display a string on the screen, and how get a string that the user types in.
I know, I know, text-based programs are not as cool as 3D graphics. You know how everyone says that you don’t need to know math to program? Well that’s not true for 3D graphics programming. You will need a decent understanding of geometry, linear algebra, and a bit of differential calculus.
Even a normal GUI with buttons and text boxes can be difficult, depending on what programming language you’re learning. It doesn’t really require any math, but it will likely require a solid understanding of object-oriented programming and complicated object graphs.
My advice for beginners is to make text-based games for a while. Make a few games like “guess the number,” a multi-choice quiz, and tic-tac-toe. Try to make a text adventure.
Alternatively, make something that would be useful in real life. That could be a time tracker, or something to automate calculations you need for work or school.
Use these projects to learn all of the features of your chosen programming language.
Programming isn’t a purely theoretical exercise. You can’t read books, watch videos, and answer quizzes, then expect to be able to create complicated programs. To learn how to write code, you have to write lots of code.
It’s a bit like carpentry. You can read all you like about carpentry, but reading alone won’t give you the skill to make a table. If you really want to learn how to make a table, you need to get some wood, a saw, and some glue, and actually attempt to make a table. The first table you make will probably be terrible. So you read a bit of theory, or get some advice from a real carpenter, and try to make another one. The second table is still no masterpiece, but it’s better than your first attempt. If you keep making tables, and applying the theory that you’re reading, eventually you will have a decent table.
Programming is the same, in that you have to make software to gain skill. The first program you make will not do much, and it will probably have messy code, but that doesn’t matter. Read some theory, get some advice, and make a new program. Each program you make should be bigger and better than the last. Repeat these steps for long enough, and you will become an expert.
You are going to hit errors that feel unsolvable. That’s just part of learning to program. If you’ve tried to solve your problem for over an hour, it might to be time to ask for help.
Some students immediately ask for help without attempting to solve the problem themselves. This is generally frowned upon in the programming community. People might tell you to visit WhatHaveYouTried.com. Always try to google your problem first.
Other students refuse to ask for help, ever. This is probably slowing down their learning. If you’ve tried to fix your problem but nothing has worked, it’s OK to ask for help.
Don’t copy and paste someone’s answer to your question, though! Analyse the answer and learn the cause behind your error. That way, when you encounter the same error again, you will already know how to fix it.
If you’re constantly hitting unsolvable problems, that probably means that your project is too ambitious. Scale it back, and make something smaller until your skills improve.
Beginners often don’t want to ask questions because of their experiences dealing with the intimidating or unfriendly members of the programming community. If you ask your question in the right way, you will have a better experience.
Paste in your exact error message. This is the most important peice of information. People often won’t try to answer the question unless they can see the exact error message.
If there is no error message, explain what you expected to happen, and what actually happened. Some something like “I expect it to output 5, but it actually outputs 7”. Often, the problem isn’t in your code, it’s in your expectations. If you don’t explain what you expected, you will get answers like “the code looks fine” and “what is the problem?”
Paste in your broken code. It’s very difficult to debug a problem without seeing the code. Paste it all in, if it’s not too big, because people will run your code to investigate the problem. If there is too much code, paste it into a Github Gist or Pastebin.com, then put the link into your question.
Format your code correctly. Don’t just paste in your code like normal text. Learn how to format your code nicely so it is easy to read. It should look like this:
def foobar
puts 1 + 2 / 3
end
Not like this:
def foobar
puts 1 + 2 / 3
end
Mention what you have already tried. This tells people that you’ve already put in some effort.
Try to use correct terminology. This isn’t always possible, because you are still learning all the terminology, but give it your best shot. Make an effort to learn the common terms, and use them correctly.
A small, but vocal, percentage of programmers are condescending towards beginners. It is true. Professional programmers often forget how difficult it was to learn their first language. But we’re not all like that! If you write your question according to the guidelines above, it will help to attract the nice programmers, and keep the grumpy ones away.
Programming is hard. Really hard. And if you’ve just breezed through an online course, this might come as an unpleasant surprise.
Set up a real programming environment, with an IDE or a text editor. Write little text-based programs to learn all the features of your chosen programming language, before moving on to bigger, complicated projects. Write all the code yourself. Don’t copy and paste other people’s code without understanding it first.
Write lots of code. Read theory, but make sure to apply the theory to your code. Read, code, read, code, read, and so on, and eventually you will master it.
When you get stuck, try to fix the problem yourself, but don’t be afraid to ask for help. You will learn faster if you ask questions. For a more pleasant experience, Learn how to ask questions the right way, because the programming community has a few grumpy bums in it.
Most importantly, have fun and keep going!
REFERENCE: http://cscircles.cemc.uwaterloo.ca/1e-errors/
As you do more and more programming, you will naturally encounter a lot of errors (or bugs). Causing, understanding, and fixing errors is an important part of programming. Python will do its best to run anything that you tell it to run, but if it can't understand what you're asking, then it won't run the program. All the same, Python will try to tell you a little bit of information about what went wrong, in order to help you try to fix it.
A syntax error happens when Python can't understand what you are saying. A run-time error happens when Python understands what you are saying, but runs into trouble when following your instructions.
In English, a syntax error would be like the sentence
Please cat dog monkey.
The grammar of this sentence does not make sense. From the perspective of English grammar, it is missing a verb(action). You cannot understand what you are being asked to do. Syntax means the same thing as grammar.
In English, a run-time error would be like the sentence
Please eat the piano.
The sentence makes sense from a grammatical perspective — there is a verb and noun in the right place — so you know what you are being asked to do. But, you will encounter problems once you start trying to eat the piano (except maybe if you are a termite). This is called a run-time error because it occurs after the program starts running.
We also will talk about logic errors at the end, which means that your program runs without crashing, but still produces the wrong result. An example would be
Please close the back door so that the bugs don't come in.
This would be a logic error if the front door is also open: even though the command makes sense and you can close the back door, this doesn't actually accomplish the goal of keeping the bugs out since they'll still come in the front door.
REFERENCE: https://news.ycombinator.com/item?id=9894234
Ah, the thing they never tell you when you learn to program... computers are the source of all frustration.
I have spent all day editing a backup copy of a file, wondering why nothing I changed fixed the bug. I've spent a whole day chasing a missing character. I've spent a week, under deadline pressure, only to discover a bug in the compiler. I've lost the source code for a whole project because I nuked the directory by accident. I have to reboot my MacBook every two weeks because it starts paging and is so lagged I can out-type it.
I did a self-study and found out that I have a 3% error rate in everything I do... and found out that 1/2 of those errors are caused by copy/paste (which I stopped doing). Errors at every level, from typing to syntax to semantics to design to thinking...and every one of them is a source of frustration.
I have to laugh when I hear people suggest that we require students to learn to program. Learning to program is the easy part. Dealing with the continuous, painful, and ever-present frustration is the hard part. All day, every day, every year of my 44 years of programming have included creating, fixing, and bleeding over programming and its frustrations.
You ask "What do you do to deal with this?"... I guess it is like trying to be a really good musician, you just study, work, and bleed at it. Most people give up on music; most programmers "retire into management". Some of us program because, like a musician, "it is not what we do, it is who we are". We program because we must. Frustration just makes that rare success that much sweeter.
"its now been 3 hours when this should have taken you 10 minutes."
The magic word is should. Strike that from your vocabulary.
Who said it should take 10 minutes? Who specifically? What was the factual basis for their claim?
If you've done in 3 times before, and each time you were close to 10 minutes, you have a rational basis for a should.
If you've never done it before, saying should is only setting yourself up for failure. You should stop using should today.
Getting frustrated is bad, but it happens to all of us. I've got it going on right now, in fact. That's why I'm taking a break and answering this question.
The programmer's goal is "flow". It's this zen-like, peaceful state of immense productivity, where literally hours pass by. It's not bug-free programming, but a state where you've got the entire system in your head and bugs are dealt with smoothly. They may take a while, but the methodical elimination of the possibilities seems to go by without frustration and without damage to the ego.
Many things can kick programmers out of the flow. Unexplainable bugs are among them. Eventually, you'll learn to deal with the kinds of bugs you're seeing now: an experienced programmer is one who has already made all of the common mistakes and knows how to handle them. That just means you find more new kinds of mistakes to make.
As a novice, recognize that the mistakes are part of the process. If you start to lose your cool, stop working and go away. You can browse the web or play a game, or even better get up out of your chair. You'll find that a background process in your mind works on it anyway, and you may even find the problem solved by the time you sit down again.