Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm kind of inexperienced with programming (ie less than a year) and I have recently been getting discouraged, mostly from not being able to solve problems with my own code (Not forgetting parentheses or syntax issues but more logic based problems).

I just wanted to know, is this something that will dissipate with practice and time or does it only get worse as my programs become more complex?

share|improve this question
To me the title describing "get errors in their code" and your statement "not being able to solve problems with my own code" sound like different issues. You're new to programming so it's important to grasp that the term "problem solving" generally means something conceptually different from sweeping up compiler errors or buffer overflows or whatever. – jhocking Apr 8 '12 at 1:54
My advice - get good at using the debugger in your IDE; both to track where your program is "up to", and what's in all the variables at each point. One thing that experienced programmers do well is to use the debugger to find out exactly what's going on, whenever a program isn't doing what they expect. The sooner you get used to doing this, the better you'll get at solving code problems. – David Wallace Apr 8 '12 at 3:44
To underline the fact that even experienced programmers make mistakes, Donald Knuth, already one of the most famous programmers in the world in the 1970s, kept a bug log for the program TeX. He was still fixing bugs in it twenty years later:… – James Youngman Apr 8 '12 at 8:24
Some things will get easier, but if you are constantly challenging yourself, you will always have problems. Persistence will help you solve them eventually. – JeffO Apr 8 '12 at 15:17
The most important part is to figure out what the question is. There's no point in solving a problem if it's the wrong problem. StackOverflow is great for solving very small niche or quirks. If it's something bigger, take the time to step back and conceptualize what you're trying to accomplish. That's why programming is considered 'creative work'. You start off primitive concepts (ex stick figures) and grow to being able to build much larger more powerful models. – Evan Plaice Apr 8 '12 at 19:21

16 Answers 16

While experienced programmers make fewer errors than beginners, all programmers make mistakes. I've heard it said that since debugging is the process of removing bugs from the code, then writing the code in the first place should be called bugging, because it is the process in which bugs are added.

As a beginner, you're writing small programs now and making errors that will seem elementary to you in a year. If you have any aptitude for programming, you will quickly learn not to make those mistakes anymore, at least not if you've had enough coffee. This will allow you to write bigger, more complicated programs.... and in the process, make a variety of bigger, more complicated mistakes. This will continue, if you enter the profession, throughout your career.

It is possible, in theory, to master one domain of programming and rarely write bugs in that domain, but there are always new things to be learning, so you will always be a beginner at something, and therefore always writing bugs.

For example, each new programming language you learn gives you a number of unique ways to shoot yourself (and others) in the foot, in addition to the ways you're already familiar with. So when you need to learn a new language, you'll learn that the first things you should Google are <language-name> pitfalls and <language-name> best practices.

Only a relatively small fraction of software development, maybe a third, is actually about writing code. The rest (process, tools, etc.) is, in whole or in part, about preventing, detecting, recovering from, and fixing mistakes made by programmers (and, to be fair, by others involved in the development process). These are skills you should cultivate, as much as you cultivate facility with a particular programming language.

share|improve this answer
I really liked your last paragraph as you could have a whole career built around bug fixing. In fact, about 90% of my job right now is fixing bugs written by others, a/k/a legacy application support. – TomJ Apr 8 '12 at 1:51
A great answer, but it makes me worry that I don't have the aptitude for this. – ironcyclone Apr 8 '12 at 2:00
I didn't know about Googling pitfalls or best practice. Learned something new today, thanks. – Mahm00d Apr 8 '12 at 6:35
@Chris2021 stick with it! Rome wasn't built in a day. – Scott Wilson Apr 8 '12 at 11:16
+1 on programmers being automata transforming caffeine into code. :) – TC1 Apr 8 '12 at 18:46

In light of your edit, since the question is more related to basic logic problems, the answer is: It largely depends on you.

Humans that write code write bugs: that's a fact of life. However, there's a lot you can do to refine the way you write your code in order to drastically reduce the number of bugs, and make it much easier to find the source of bugs when they appear. You can decide whether you're willing to just keep plodding along or whether you want to use techniques that will make your code less error-prone.

If you want to improve the quality and bug-findability of your code, here are some ideas:

  • Break your logic into small enough chunks that anyone with a little programming experience should be able to look at any given method and understand what it does within twenty seconds or so (even if they may not understand how it fits into the big picture).
  • Draw models of how your code will work and interact with other modules on a piece of paper before writing code.
  • Talk with another programmer about how you intend to solve a problem before writing code. Listen to their suggestions.
  • Write unit tests for how you expect a method to behave before you write the method. Take time to think about how your method should respond to unusual inputs.
  • Write fail-fast code.
  • Have another developer review all your code after you have written it. Listen to their suggestions.
  • Make logging a priority.
  • Don't Repeat Yourself.

Take a moment to look back at the code you wrote a year ago. If you don't cringe and think, "Holy cow, I could totally do a better job on this today," it means you're not learning enough.

One more thing: I don't want to discourage you because I doubt you fall into this category, but it must be said: some people's brains are just not made for programming. If you find that you aren't learning, you aren't continually improving, and you aren't enjoying yourself, it may be better for everyone involved if you start looking for a career change.

But everyone writes bugs. Don't get discouraged just because you keep making mistakes. That's normal.

share|improve this answer
+1 for writing code that is easy to debug. In my learning years I was rewriting a lot of my code, because the original was hard to debug. the saying goes: "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." – Brian W. Kernighan – hidralisk Apr 9 '12 at 13:38
Debugging will never get less annoying, but it will quickly become more familiar. If you are uncertain whether it is for you, IMHO the most important question is: do you enjoy programming? If so, then the practice and learning will follow. – comingstorm Apr 9 '12 at 17:21

The more complex your code is the more complex your problems will be:-)

With experience you'll stop making some more trivial mistakes, and will easily find those trivial mistakes you still make (and everyone forgets a pair of parenthesis here or there occasionally).

But the more complex is your code, the more complex are your bugs. You'll start chasing synchronization issues, driver interactions, integration or architectural design issues... There's always something to fix.

share|improve this answer
Just want to add, I have only been programming professionally for a little over a year, and most of the bugs I get are architectural. Even these seem to get easier with experience. – Chris Apr 8 '12 at 5:06
Generally a good answer, but I'd suggest that everybody spend a few minutes, on finding a bug, trying to figure out why that bug came to be written. Sometimes they're typos, cut-and-paste errors, off-by-one errors, etc. But by identifying the cause of the bug, you can figure out how to avoid it next time. – James Youngman Apr 8 '12 at 8:10
You will also learn to achieve the same thing with less complex code, with less complex bugs :-) – gnasher729 May 31 at 16:11

Lots of great answers already here. I just wanted to point one thing out: If you're brand new, then of course you're making dumb mistakes. You're a beginner. If you were just starting to learn a musical instrument, or playing baseball for the first time, or any other skill, you'd be pretty clumsy at that too. It's a normal, expected part of the learning process, and everyone goes through it. As the old joke goes, you do things right by experience, and you gain experience by doing things wrong.

To become truly good at any skill generally requires about ten years or 10,000 hours of serious practice in which you're constantly pushing yourself to learn and grow. If you're willing to put in the time and effort, you'll come out the other side as a good programmer.

I think the difference is that in programming, the basic tools are freely available to anyone these days (pretty much everyone has a computer an an Internet connection) and that and a few Google searches is all you need to get started writing very simple code that doesn't accomplish anything useful. It's the moral equivalent of learning to play "Hot Cross Buns" on a flute, but to do that, you need to actually go out of your way to obtain a flute, get the music, and memorize a bunch of finger positions to make the notes. But for programming, you've already got a computer, and all you need is to download a compiler, copy and paste some code that someone else wrote, and you've got a working program! No actual understanding required! So people think "Oh, wow, this programming stuff is easy!" And then when they run into their first real problem, they have no idea how to solve it and they get discouraged.

When you get down to it, programming is really only two basic skills: breaking down a large problem into smaller problems, and expressing small problems correctly in formal logic. A lot of the experience that goes into making someone a good coder lies in learning to recognize and solve a wide variety of small problems.

Today, I can get a request to implement a new feature, and I look at it and say "OK, this involves sorting a list, this part is an associative mapping, I'll need recursion for this part over here, and storing it to the database will require two tables with a foreign-key relationship." Those are all things I've learned how to do over the years, and I've learned how to recognize which techniques are appropriate for which types of problems.

If you study coding with a conscious effort to learning new ways to break down problems into smaller problems and new techniques for solving different types of small problems, you'll find that it becomes more interesting and more rewarding. And you'll find that your problems with logic-based issues go away as you learn to deal with them. (But you'll also find that you get asked to solve harder problems. It'll always be a challenge, and if it's not, you're doing it wrong.) :)

And when you run across something that stumps you, ask on StackOverflow. There are thousands of programmers who have already put in their ten years and then some, and we're willing to help out and lend a hand, especially to those who are serious about learning.

share|improve this answer
I really liked your analogy, a great answer overall. One thing I have found with SO though, is that I write some code and can't find the issue with it. I ask for help on SO and get bashed for wanting other people to do the work for me. It's frustrating, but I guess I just need to develop some debugging skills – ironcyclone Apr 8 '12 at 20:05
@Chris: If you don't want that to happen, make it clear that you've put some effort into it already. If you explain "I tried X and I had this problem with it, and I tried Y and it didn't work because this other thing happened instead," you'll be a lot more likely to get some help. – Mason Wheeler Apr 9 '12 at 15:12

You will continue making mistakes, they will just be harder to find. With sufficient practice, you will quickly stop making simple-to-spot mistakes, but logical and design mistakes that are harder to find will continue cropping up. Essentially, you will stop making "old" mistakes, but will continue making "new" ones.

share|improve this answer
But at the same time, hopefully, your problem-solving skills will improve. You'll be solving really hard problems, but it won't be as hard as it used to be, and it'll feel really good. – Kevin Krumwiede Jun 13 at 4:01

Anybody who isn't making mistakes at least once in a while isn't challenging themselves, so it's nearly certain they're no longer learning. In other words, they're stagnating.

As you gain experience, your mistakes tend to get bigger and more complex, largely because you (at least we'll hope) tackle problems that are bigger and more complex. You do, however, (again, we'll hope) learn to recognize your mistakes a little sooner, and generally learn to design (and code) for the fact that you will make mistakes, so you learn leave a little more "looseness" in the code, that makes it a little easier to recover from mistakes.

share|improve this answer

Getting the code to do what you intended is the easy part - at some point you can construct the whole program in your head in a cool animation before even opening the editor.

Figuring out your actual intentions is the hard one. And oh yes I do have problems with that. Like any other human, I guess. It usually takes a few hours and/or a chat with a colleague to understand if you're going in the wrong direction, but sometimes only after a few weeks of hard, devoted work you can look at the result and realize that the whole thing works as intended... and sucks hard, is ugly and should be thrown away. And trust me, it's much more depressing than any unintentional bug you can possibly make.

So yeah, it gets worse. And, of course, the more abstract the goal, the harder to conceive the path to it. Which is why you never start a project without a very detailed spec, even if you have full freedom.

share|improve this answer

Several answers here give some great advice and, I believe, dispell some of the myths that experienced programmers are always perfect. I just want to add that it's important to remember that some entire development methodologies are specifically structured so that you can "fail fast".

Agile, for example, not only accounts for failures in thought and execution processes (among other things) but in some ways assumes them. It's ok to fail, is the point; the next step is to figure out what went wrong and to iterate through fixes, quickly, but there isn't (or shouldn't be) an assumption of perfection right out of the gate.

What is implied in an iterative process is that you learn from your mistakes so as not to make them again -- or if you make them again, you make them differently and learn something new.

As you are a relative newcomer to the field, I would suggest that you worry less about making mistakes -- because everyone does -- and worry more about learning from them and not repeating them, while shoring up your understanding and use of best practices over time.

share|improve this answer
Good point. I have many more asserts and error checks now than 10 years ago. I always assume the worst and code defensively, because sooner or later, things will fail, and its real sweet to have that error caught by code I wrote the first time around. – Macke Apr 8 '12 at 19:46

Here's how I rate whether a learner has a chance of continuing in the subject; ask yourself, "did I make less mistakes this month than I did last month?"

If the answer is yes, even by a small margin, then you're good to go as you're way, way ahead of the curve. If your answer is that it's roughly the same amount but you kept facing different ones, then you're doing well, because as you improved yourself, the problems you're facing also get more and more complex because of your personal expectation and the intrinsic complexity of the problem, which increases the number of potential bugs -- most of which you will already be familiar from previous experience and know how to avoid -- and the rest are the bugs you haven't learned to "feel". Finally, if you think you keep making the same mistakes over and over, then it's time to reconsider another career.

When you started learning, it doesn't really matter how many bugs you created, what matters is that you're improving as you're learning.

share|improve this answer

Experienced programmers have trouble with problems and creating solutions. Over time, you do get a pretty good sense of what systems to place and how they will solve problems. As you go, you'll discover all sorts of aestetic, personel related, platform related and language related limitations or dynamics that will ruin what you thought would work great. Eventually you get a handle on some of all of these things and the prize is... Way more sophisticated, highly paid projects! Downside - difficulty; upside - be more the boss and craft more interesting solutions or products.

Sometimes I wish every programmer I worked with would work for a little while as bug-tracker. I had the benefit (curse) of working at a lower tier for a few years with an application with significant legacy code issues.

Why is this relevant? Because working on problems is often the best way to understand problems.

Mostly, as you work and become more experienced, your capacity to correlate apparent symptoms with unexpected causes will improve. Unfortunately, so will more sophisticated problems in more sophisticated systems.

Expect to constantly be running into situations that test your patience. Focus on good practices, highly iterative, concise methods and build up from scratch (don't use other people's code so much) to develop good habits. Also, you may find yourself making love and thinking about how a variable or data element is manipulated through some application. This is your debug system developing, you are becoming a robot.

To get really good, you're going to have to get into the dirt. It can be really overwhelming to have tons of information packed into your brain whilst attempting to debug something seemingly without source. Over time I've found that the benefits of willingness to do so is what separates the decent from the exceptional.

share|improve this answer

I've been programming a very long time, and yesterday had the experience of reading some code and my first thought being that it was too complex for my abilities. Interestingly enough, the code was an algorithm designed and written by me two weeks ago. The reason behind this paradox is that I could understand very small parts of the algorithm, just enough to get me to the next step, but it was too complex to comprehend the entire thing at once.

What you should learn from this is not to get discouraged when you don't understand something. Break it down into smaller and smaller pieces until you do.

share|improve this answer

After 15 years programming I still run into problems. Rarely. But then it takes hours to find the problem and it's usually a really tricky one. Other than that, everything is piece of cake. I've wrote a blog post about looking for problems in the code.

share|improve this answer

One brief comment: you will always make bugs but some of them come to represent less of a problem over time. Consider the following C snippet:

int c;
scanf("%d", c);

This is an erroneous version of,

int c;
scanf("%d", &c);

and scanf in the second (correct) paragraph is given the address of c; in the first one it is given the value of c, assumes it is the address of c, and crashes and burns.

The first time a C student does this, this could easily be hours' debugging; the first example reads straightforwardly and makes sense (compare to complex code where bugs don't jump out). And it's a blood boiling experience. But over time, you develop a (perhaps subconscious) list of "usual suspects", and if your debugger or output statements localize the problem to a scanf, you will naturally check to see that each variable has or does not have an & before it in a way that makes sense. The bug still happens, occasionally, but it is much less severe.

Fast forward a bit to Java, with the philosophy of "Prefer compile time errors to runtime errors." References as used in Java eliminate a whole subtle class of pointer error bugs, which in C can be a time sink. (Goto statements are the F-bomb of programming language constructs, and pointers are the goto statement of data structures.) The "prefer compile time errors" is kindness in disguise, because the compiler points very specifically at one line of code, thus dramatically reducing head-scratching in figuring out, "Yes, I know the computer is mad at me, but why is the computer mad at me?"

And other languages have developed since. Python does not follow the "prefer compile time errors" philosophy, but the overriding concern in the most obscure design features is programmer productivity, and it shows.

Will you debug as long as you program?

Probably you will, but it may matter less than you think.

share|improve this answer
Both scanf('%d', c); and scanf(%d', &c); are incorrect. Should be 1) scanf("%d", &c); " vs ' 2) Need 2, not just 1 as in %d' – chux Apr 19 '15 at 14:07
I really like the analogy of pointers being the "goto" of data structures. Spot on! – Thomas Carlisle May 19 at 2:16
It will teach you to turn all reasonable warnings on that your compiler can provide, and turn warnings into errors. – gnasher729 May 31 at 16:15

Software development is a trade like any other, except that building effective software is many times harder than building other things, like say a deck.

When a carpenter builds a deck there might be 10-15 variables that he or she needs to keep in mind in the process. What wood do I use? What size is the deck? How many people do I need to get it done quickly?

On the other hand, when a software developer or engineer builds a complex software system there is an immense number of variables involved. What is it that I'm actually building? (that alone is often separated out into the role of business analysis) What language am I using? Am I proficient with the language? What should my UI look like? How should I structure my server side code so it doesn't break? What testing framework should I use? And on and on and on and on.

Personally, I've been coding for about 5 years and the amount I've learned about the trade in that time is enormous, and I'm still not done. I know I'm a pretty smart guy, but in my first year of development I was clueless. My programs were awful, and I made elementary mistakes all the time. But the more I did it the more I learned, the less frequently I made mistakes, and the more my ability grew. The process was quite organic.

So the key difference between development and other trades, is that development has a much longer learning curve than most other fields. It can take years just to reach the junior level, and years more to become an intermediate.

And so I'd suggest if you're less than a year in and you're feeling lost, that's normal. Keep learning earnestly whenever you can, and you'll get there.

share|improve this answer
The software vs deck comparison is inappropriate. A deck can be as simple or as complicated as the buyer wants, depending on geometry and what kind of finishing and architectural details should be present. Have you ever even built a deck or any structure that has to be capable of safely supporting people? It's not as simple as you might think. – whatsisname May 31 at 21:26

Programming is almost as any other activity/profression you may know. To become a good professional or to reach some grade of "excelency" is matter of 3 things: practice, curiosity and will.

The best thing that can happen to you is just what you are worried about. You need to do lot of mistakes and see even more from other programmers. The important thing is to learn something from them.

You know how it should not be done. Now lets do it as it should be.

As many people already commented. Error (progressively) will go from mere logic errors (relatively easy to fix) to architectural issues. Some will be a challenge. Redesign, refactor, migration, upgrades, concurrency, performance,...

From my point of view, programming is the "solving-problems" profression. The harder is the problem the better. Challenges does this profression fun and interesting. Errors are like a little window opened to keep learning and improving. No too many jobs out there can say so..

Many of us had not as many resources as beginners have thesedays. There are countless pages, sites, forums, blogs, guides, books to look for solutions, opinions, advices, ...

Make your own toolcase. These resources that helps you most. Be curious and do investigate by your own, practice at home or during extra hours at job.

Get ready, the journey just started.

Answering your main question... I still do errors. I guess everybody does.

That's why we set a test phases in every project. And that's why there're also garantee periods. Like many other product on the market.

share|improve this answer

An experienced programmer is different from a mere mortal, by their behavior not to give up, but try again and again, until the program works. The key experience is: trying something, failing, then jumping back on your feet and trying again... fuck sleep (more coffee, please).

Possibly your muscle memory will also get better with time. You'll become more focused, and less tolerant for interruptions while working, (try calling me on the phone while I'm in the middle of debugging some buggy piece... not a nice experience) and will realize you missed a parentheses right while typing, or become more knowledgeable about common mistakes, so when you look at 1000s of pages of code, you have a good guess where to look for the error, or what tool (IDE or whatever) to use and how, to be better in finding such errors. Also, experience with specific technologies will give you the knowledge of the common pitfalls using that tech, and have the crucial experience that you have already got it to work before at least once, so you know there must be a solution (helps with keeping your sanity sometimes). It also often happens, that you have been using the "bleeding edge" and something was not working the way you expected it to work. Or, things have changed: the library you used last year got upgraded since, and the new version works a bit differently, but not well for your purposes. Happens. Takes time, but if you keep trying you will get it to work eventually. (alright, sleeping can help, sometimes... don't overdo it)

Regarding your programs becoming more complex with time. The greatest skill of a good developer is not how many programming languages she knows, or how many fancy technologies, but having the awareness not to walk into the trap of complexity, but to avoid it like a plague. You can read some quotes on my profile page related to this subject ;)

What is important is never to be discouraged if something is not working on first try. Try again and again, google for it, search for it on stackoverflow, or ask someone to help you out (colleagues, or even IRC). It is definitely a good reason to upgrade your communication skills, to be better in persuading other detail-oriented (possibly very busy) developers around you, to help you out by giving you a "second pair of eyes". Most common mistake from newcomers, is not doing their research before asking others for help... be able to show that you have put in some sweat-and-tears, trying to find the solution yourself.

What I found teaching non-programmers how to program (in courses, meetups, or at home), is that it's extremely hard, because they give up too early when facing something themselves alone, that is not working. They give it up, and they never get to experience the lovely feeling when you spent hours and hours on looking for a solution, with no result, then more hours, and still no result... hours and hours more, days and days and days... no result, until one day there is a breakthrough! My main point is, it's normal. Part of the game, "No pain, no gain".

Genius is one percent inspiration and ninety-nine percent perspiration - Edison

That's why great developers / sysadmins are rare. Believe me, being a good developer doesn't depend on which university you came from. It's the battle hardened experience of knowing how to react, when something is not working the way you wanted it to work. When you feel that nothing you do seem to be working, and it feels there is no worth in trying it again, it's just not working, then have a coffee, and try one more time. And most importantly, avoid complexity ;)


Quite in line with all the shit I wrote above, possibly these are the details what you are really looking for:

Self-Awareness -> Self-Efficiency

theory of self-efficacy builds on our varying degrees of self-awareness. It is "the belief in one’s capabilities to organize and execute the courses of action required to manage prospective situations." A person’s belief in their ability to succeed sets the stage to how they think, behave and feel. Someone with a strong self-efficacy, for example, views challenges as mere tasks that must be overcome, and are not easily discouraged by setbacks. They are aware of their flaws and abilities and choose to utilize these qualities to the best of their ability. Someone with a weak sense of self-efficacy evades challenges and quickly feels discouraged by setbacks. They may not be aware of these negative reactions, and therefore do not always change their attitude.

share|improve this answer
Don't take the sleeping parts too seriously. It's actually 3am now, and even I am thinking to leave fixing my emacs config for tomorrow :P – Daniel Dinnyes May 19 at 1:56

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.