How can programmers achieve "fast programming speed and few bugs"?

[[131966]]

A netizen asked on Quora: How can I train myself to be a fast programmer with few bugs? The following is a very interesting reply from Glyn Williams, with 4.5k likes.

Three programmers were asked to cross a field and reach a house on the other side.

The rookie programmer estimated the short distance and said, "Not far! It only takes me ten minutes."

The senior programmer took one look at the field, thought for a moment, and said, "I should be able to get there in a day." The novice programmer was surprised.

The great programmer took one look at the field and said, "It looks like it will take ten minutes, but I think fifteen should be enough." The senior programmer sneered.

The rookie programmer set out, but after a while, the mine exploded, creating a huge hole. He had to deviate from the planned route and backtrack, repeatedly trying to cross the field. It took him two days to reach his destination, and he arrived shaken and injured.

The senior programmer started out on his hands and knees, carefully patting the ground for mines and moving forward only when it was safe. He crawled slowly and carefully through the field over the course of a day, setting off only a few mines.

The programmer set out and crossed the field directly, very decisively. It took him only ten minutes to reach the other side.

"How did you do it?" the other two asked. "How come those mines didn't hurt you?"

"That's simple," he replied, "I didn't plant the mine in the first place."

Programming becomes difficult when we encounter logic bombs that we (or others) have planted for ourselves. We write logic bombs every day. They sit quietly beneath the surface, waiting to explode. When they do, they often have serious and unpredictable consequences.

As new code modules are added to the project, the complexity of the project will increase. This increase is not linear, but rather exponential.

Programmer energy is a limited resource, so this explosion of complexity will eventually overwhelm the programmer. Your brain will eventually become overwhelmed, and that's a tipping point.

This is when the bombs start going off. There are all kinds of bombs: modifying an array while iterating, array indexes accidentally going negative, another thread changing the state of an object halfway between the start and end of your function execution. Boom, boom, boom…

I believe that the fastest and most reliable programming requires developing a style that avoids these problems.

Write code that clearly expresses behavior. Choose meaningful, accurate, and unambiguous symbol names. Be strict with naming schemes and don't use different words to describe the same thing.

If so, go with the simplest solution. Don't optimize for speed, optimize for readability and transparency.

If you didn't write your code with reusability in mind initially, don't fool yourself into believing that your code can magically be reused. Instead, start with one scenario and keep your code specific. If it's worthwhile to modify the code to make it more general, be prepared to rewrite it from the ground up.