How often do experienced programmers have trouble getting their code to perform its intended purpose?

Question

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?

Answer 1

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, or 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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

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.

http://agiletoolkit.org/blog/how-to-solve-error-in-my-program/

Answer 12

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.

Answer 13

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.