Geek Answers Handbook

Why do I spend 20% of my time fixing bugs? This is normal?

I just started writing code in C, C ++, Java, ASP.NET, C #, Objective-C, I-Phone, etc.

But I do not understand why I should spend 20% of my time correcting errors.

I studied these programming languages ​​as they are. Most programmers face this type of problem?

+4
source share
7 answers

You do not have to spend 20% of the time correcting litteraly errors, but - yes - most programmers have to deal with the problem of fixing errors. I hope you can spend less than 20% on fixing time errors, if you are not careful, it may take more time.

No matter how good a programmer you are, it is very likely that you will present a few bugs for some time. If you have undergone unit testing , you can hope to avoid mistakes. I highly recommend that you study Test Driven Development (TDD) if you want to do everything you can to avoid errors.

There are a few questions about unit testing and TDD in StackOverflow if you need help getting started. Here are a few of them:

+17
source

No, most programmers have it worse than 20%.

If you want to get ahead of the game, you will start writing tests to go along with your code. Google for:

  • check first programming
  • drive driven design
  • behavioral design
+12
source

Errors will always occur and should always be resolved as soon as possible, thus, the code will be fresh in your mind.

+4
source

For example, you can write, but there are some “errors” in your message: a space after a comma, a space before a comma, a space after a period, “programmers” is not someone’s name, therefore it’s better “programmers”. Now you can use 20% of your time to fix them.

+4
source

This is some strange question. If I allow myself to rephrase it ...

Why do I spend so much time fixing my own mistakes?

Focus your energy on not creating them first. There are many things you can do to minimize errors:

  • Stay up to date with the ins and outs and side effects of your methods.
  • Divide your problem into small, write-friendly functions and methods.
  • Write a lot of tests.
  • Write test methods.
  • Correct the code before clicking this compile / run button.
  • Ask someone to check.

As you gain experience, you will find that simple errors become less frequent, and hard ones (usually due to poor design or unknown library behavior) start to consume more of your time.

+2
source

Bug fixes are part of the programming, whether you like it or not, it will always be there.

He was there until programming was around, and it will be there until we program more.

It is so common that you can find it in many common programming jokes.

And, like Wayne, most people spend a lot more than 20% of their time debugging.

Personally, I believe that debugging is what makes programming fun, not because it is fun in itself, but because you need to fix it for so long, and once you fix it, you get this overwhelming feeling: " WOOHOO! I did it! "

Again, I agree with Wayne that you are trying to use these programming methods, but they are addicted to programming.

One thing that I found useful when debugging is to take a break and then return to your code in a few minutes, preferably after a short conversation with a friend or a phone call, you will be amazed at how quickly you can spotty mistakes, the hardest part is getting the will to stop programming and take a break.

0
source

No, you should NOT spend 20% of your time fixing your own mistakes.

Nobody mentioned anything about the PSP / TSP, but reducing the time it takes to fix errors is what the PSP (Personal Software Process) is. Usually this allows you to reduce the time to correct errors to less than 10% from the very beginning, formalize your project documents and view them in accordance with the checklist; standardize your code, review it in accordance with the code review checklist; and then start compiling and testing.

In the end, you will reduce the time to fix errors to almost zero percent, as you will better see your projects and code. The basic idea is that it takes too much time to fix errors in the project document or to check the code; than the time required to find and fix errors in unit tests, and more than integration tests.

If you use good design reviews, code reviews, and unit testing, your bug fix time should be below 10% almost every time, I'm below 7% on average (according to my statistics).

0
source

More articles:


All Articles