I am novice developer.

While development is going on, we come across different error issues. However for the novice of programming, it is always hard to directly understand them & solve them.

I believe, errors are generally related to typing error OR data structure error OR run-time memory error - which is related to hardware OR else.

How to elaborate and solve those errors very fast ?

  • 9
    Haha good one - if we could all do this "very fast" we'd be all out of a job
    – billy.bob
    Dec 24, 2010 at 12:26
  • I think your question could do with a rework. It's meaning is not very clear.
    – Gaurav
    Dec 24, 2010 at 13:17
  • 1
    /[I Believe/] First rule of debugging, don't believe anything.
    – Manoj R
    Dec 24, 2010 at 14:33
  • To do this fast & cheap, outsource your job to a less developed country.
    – Job
    Dec 24, 2010 at 19:12
  • possible duplicate of How to reduce the number of bugs when coding?
    – gnat
    Mar 30, 2015 at 20:20

5 Answers 5


My thoughts:

I don't think many errors are related to typing errors. Typos will generally not produce stuff that will compile so rarely produces anything that gets even as far as unit testing, let alone beyond that. Those few that do are generally very easy to spot.

In 16 years in development the only issues that I've seen which were caused by a hardware fault were so major (i.e. system / sub-system down) that it was instantly obvious and was picked up by the sysadmins. Once it makes it as far as the programmer I'd suggest that you remove the possibility of hardware error from your mind until you see some very very strong evidence to suggest that that's the case as generally it's so unlikely you shouldn't waste time thinking about it.

Errors fall into three categories:

1) Misunderstandings - that is the system is working correctly but someone has misunderstood what it's meant to do. The best way to find out if this is the case is to get as much information as possible, ideally by speaking to someone who has actually seen the error and ask what they saw and what they expected to see.

2) Configuration Errors - while there are very few errors which are caused by hardware errors, there are plenty caused by machines being set up differently as far as software configuration goes. This is particularly likely if you can't reproduce the error on your development set up which is likely to be pretty non-standard because of the assorted tools you've got installed and changes you've made to be productive. The best thing to do here is to have a development test environment which is a clone of production and try and reproduce the error on there. Once you have you can start comparing that environment to the ones where it works and see what the differences are.

3) Code Errors - the code is out and out wrong. There are common problems (not checking return values or badly handled errors, incorrect loops and checks - for instance not checking the final record in an array or collection because the developer got confused about whether it ended at i or i-1) but exactly how common they are varies from project to project and in any case, they're easy enough to spot by walking the code. The main things I'd say here are make sure you can reproduce the error (this may involved getting details of a specific record where the error occurs from the user) and walk the code line by line.

Broadly speaking I'd suggest the following hints:

1) Own the problem. It's your problem and you need to fix it regardless of what it is or who originally caused it. This may involve you looking into things that aren't your area of specialisation but it that's what it takes, that's what you do.

2) Speak to the user. The thing which slows down problem resolution the most in my experience is bad information so cut that out by going straight to the user and find out what's happening. Have them walk you through it, what they did, what they saw, what they expected to see. Ask if it happens all the time or just some of the time. If it's just some of the time ask them about patterns, get details of specific records where it occurs. Question everything and assume nothing. And when I say speak to them, I mean speak to them - you'll find out more than through some e-mail conversation and you'll do so far far faster.

3) Reproduce the problem. Don't guess at the solution, reproduce it, it's the only way of knowing you've really found what's happening. Walk the code step by step and see what's actually happening. This may involve reproducing the environment or getting a copy of the database - if you have to, that's what you do.

4) Be realistic. It's not a hardware problem and you've not found a problem with the compiler. Once you've worked out it's a real problem (that is that the user is not mistaken about what it's meant to be doing) and you've reproduced it, by far the most likely issue is that the code is wrong so don't kid yourself otherwise.

5) Fix the root problem, not the symptom. If they say everything is out by 1, don't just subtract 1 from everything, find out WHY it was out by 1 and fix that. If you only fix the symptom, you will see the problem again.

  • "Typing errors" may not necessarily refer to typos
    – vijrox
    Jun 19, 2016 at 23:00

A lot, rather most of what you do as a programmer is debugging. You are either debugging your code or someone else's. As a novice, you don't want to focus on faster. You need to focus on detail, organization, and correctness:

  • Study the details. Don't just debug, seek to know why something isn't working.
  • Well-organized code makes maintenance and debugging much easier.
  • Be correct in usage: just throwing code together to save time never does.

Additionally, ask questions...ask, ask, ask. The speed at which you debug is not near as important as your skill at resolving the bug once found. Speed will come over time; however, accuracy should be your primary concern.

  • 1
    +1 - You need to think about faster in the long term - that is fixing the problem so it never comes back, even if that takes more effort right now. Faster in the short term is almost always longer in the long term. Dec 24, 2010 at 14:19

Having an intelligent IDE and learning how to use a debugger, I'd say. Without these basic things, you are probably either hopelessly executing code in your head and seeing if it works, or inserting trace statements all over the place. This can make debugging simple mistakes take forever, when, in a better environment, it would be pointed out to you in glowing red before you even ran the project (or shortly thereafter).


Since this is a question asked in general terms, I will try to make my answer as broad as possible.

Solving an error involves answering two questions assuming you are familiar with the development language/platform/technology

  1. What does the code do ?

The answer to this can be found both from the top first by code comprehension (either manually or using tools) and from the bottom by good old debugging. What is more important is to religiously document any incrementally knowledge thus gained in a easy to understand format and gradually construct a model in your mind.

  1. What should the code do ?

The answer to this can be found from the existing documentation of the product as well that of technology, platform and language , discussion with colleagues and the end users, and from the knowledge gained and model constructed in the first step.

Solving error is a matter of aligning 1. with 2.


I have to disagree with the need or usefulness of a debugger. In any multi-threaded environment a debugger is next to useless especially in an embedded platform. printf FTW!! For a novice programmer my suggestion would be start keeping a list of common mistakes you make.

For example: Are you checking all your return values? Are you checking for boundary conditions? Are you initializing all your variables? Are you checking for NULL before dereferencing a pointer? Are you validating all you input parameters? Are your linked list insertions and deletions correct? Do you have the correct protection mechanisms around shared data/resources.

After you gain more experience knowing where to start looking for problems become more intuitive. I think the hardest part about being a novice program is lack of knowledge/experience with the platform they start working on. I used to be amazed when a more senior developer would look at a bug that I was working on and solve it 10mins after I had worked on it for 2 days. They were not any smarter than me, but the knowledge of how the system worked including how different subsystems interacted allowed them to make an educated hypothesis about what was going on based on the behavior of the bug. I can not stress enough how helpful it is to know as much about the platform that you are working as you can. Know your limits and do not be afraid to ask the more senior people for help. Also, if they do happen to help you make SURE that you have them explain exactly what was going on and make SURE that YOU understand what was causing the bug. Each bug is another opportunity to learn more about the platform that you are working on. The more you know the easy it is to debug.