When the architect designs a building he is not thinking about the bugs the building will have someday. He deals with the designing part.

The construction agency then works on a building. First bugs in architecture can lead to construction workers adding more bugs in laying materials.

Now that you have the building, you will want to put properties inside of it. You will make bugs choosing appliances.

What i mean by that metaphor, is as you have said, there will be bugs in everything a person does.  Yes, you can try to foresee, plan the structure to the point where it is unproductive to do so.

Most productive is not to try and think about the upcoming bugs, but to have your first releases and working prototypes, and only then deal with the bugs. 

It's like in life, dealing with problems. You can't simply oversee every variable in life ?  ❤️ 

You can't really avoid the bugs, it's like "measure twice and then cut", it's just that trying to resolve all the upcoming bugs is like measuring many times the same thing you have, and what you have is nothing, because you haven't coded anything trying to think about avoiding the bugs. 

Well the best way to avoid the bugs is not to code Other than that, you have to just do it and resolve them in the way

A few points to share based on having worked in QA full time for the better part of a decade now:

1. Code can only ever tell you what the code Is doing - Use documentation to clearly detail what it is supposed do to, and why you want it to do that.

Teams that embrace detailed understanding of the what and why of their codebase have shown a far lower bug rate and overall long running productivity levels than teams who focus purely on 'productivity' and getting more code done faster.

One of the biggest things I've come across that seemed to reduce bugs during a project's lifetime: Record WHY you decided to do something, and WHY you make changes. Assume that you're an idiot who will forget things, because if you're a human then honestly you are. And if you don't think you are an idiot who can forget things as a programmer, then you probably really are an actual idiot who will contribute loads of bugs to projects over the years.

If you think you are too busy to take five minutes out of your day to write out some detailed thoughts about the what and the why of the code you're working on, then think about the five hours, or days, you're likely to spend trying to unravel things and track down a bug because you've misunderstood something. 

2. Code small, code carefully, code only what you actually need, and analyse how a section of code might fail to do what you intend. 

Poke at things from different angles, do not assume they will always function the way you expect at first glance. 

3. Have other people USE your software as early as possible. 

- You cannot fix what you don't realize is broken. Other people will break things in fun, new, and unique ways that you never dreamed of. Embrace it, and learn to address it. 

My philosophy is: "Bugs will happen, so make sure you mitigate them".

Make each bug as easy as possible to detect and find.

•  Write automatic System Tests. (ex: Write an automatic test for the AI to play your game)
  • Make sure you have satisfactory code coverage
• Make small commits, so that you can later browse through them and see which one introduced the bug.
• Try not to use untyped languages or data. Python, Javascript, etc... will ensure that you will only find bugs at run time.
• When using C++ try to avoid using pointers whenever possible:
  • Can a function use a const reference instead?
  • Can I use a smart-pointer without hurting performance too much?
    • This pays off 100x  when you are multi threading
• Make sure you use logging as much as possible (when it doesn't cause performance problems). That way you can investigate a sporadic bug when it happens.
• Make sure you have the option for IDE debugging. (this can sometimes require defensive coding, as not all languages are IDE friendly)
• Write small functions: If a function does not fit on a screen, you should probably break it down. That way, bugs remain contained
• etc...

Basically: Bugs will happen. You cannot do much against that, However, just make sure that you have favourable conditions to:

1. Understand that you have a bug as soon as possible

2. Isolate the bug (find out what is causing the bug and what is effected by it )

3. Have the right tools to fix it quickly. 

Bugs are to programmers what fires are to firemen - we just have to do our best to prevent and deal with them.  Fire departments set aside regular time for training, equipment checks and maintenance...

In between your long coding sessions, spend 15-30 minutes doing nothing but just making your code more readable.  If theres nothing to clean up on your current project then take a look at previous projects and update them instead.  Then, when you return to your more creative, longer sessions you will find the code easier to work with and debug. This is not only because of the improved code but because you are better prepared to deal with bugs as you find them.

This is also very useful if you are not in the mood for programming but still want to at least get something done.