Answer by A Quora admin:
Experience will train you if you let it, if you have an open mind, and actively look for ways to improve yourself.
I would say the most important aspect in this regard is making sure you fully understand the problem you are writing code for before even getting started. You should be able to completely visualize the problem space in your head. Once you have that, you are far less likely to create bugs.
Bugs come in a few varieties:
- Slip of the fingers.
Perhaps you meant to type a '+' when you hit the '-' key. Or you forgot to add a parameter to a function/method call, and it went with its default parameter. Or maybe tripped over an even more subtle nuance of the language you are using.
- Trying out new programming constructs or patterns.
If you are trying some new construct, you might want to play around with it first in test code before you put it in production code.
- Race conditions.
This one can bite you hard in our world of concurrency. They are some of the most trickiest bugs to track down.
- Architectural / Design errors
This should be less of an issue using SCRUM approaches, but can still bite. Especially bedeviling since you can go pretty far down the development path before it becomes apparent you've been coding yourselves into a corner.
- Scalability issues
The code you wrote might work fine at small scale, but break at larger scales. This could entail race conditions, but also entail performance bottlenecks and the like.
- Environmental Issues
If the environment is not carefully controlled for, you might run into the problem of "well it compiles and runs on my machine!" but not the production servers, etc.
- Changes in the underlying libraries
This is related to "Environmental Issues". In today's world, it should be less of a problem if you are working in an environment that uses package management with strict version control, but it can still bite you if you're not careful. I am a big fan of semantic versioning.Religiously adhere to those practices and you should be fine.
- Branching and Merging bugs
If you and others are working on branches off the same trunk, and later decide to merge the branches, you could wind up with unexpected issues as a result of the merge. The solution here is good communication and understanding of who is doing what and how, etc.
There may be more to add, and feel free to do so. But I think I've covered most of the avenues bugs can slip in. There are approaches to avoid everyone of the above, though some are trickier than others. Particularly bedeviling are scalability issues, and in our rapid turnaround pace this will always be a danger. Architecting solutions with scalability in mind up front can be incredibly important. However, too much concern for that up front can also be crippling, so striking the right balance is key here.
Alas, there is no substitute for experience. Do the best you can a priori with the time, knowledge, and resources at your disposal, and the go for it. You will make mistakes, you will run into pitfalls. It is important to fully understand your mistakes and what you need to avoid making them again.
And Google is not always your friend here. It's great for common issues, not so great if the issue is more obscure and esoteric. And half the battle is in knowing what search terms to use anyway.