Many beginning coders have the feeling there's one right or best way to compute a piece of data they need. To simplify a bit, this is not so. Style isn't all surface: the way you tend to think and approach things, the way the language works, the way you and others remember or refresh their memory. By and large, you cannot easily tell which angle of attack will be the fastest for the machine. To be blunt, most of the time you will not know; you will guess and occasionally run spot measurements like the (other?) professionals, knowing these are only limited snapshots. When you write code, as when you write math or speak, you're constantly balancing factors, not the least of which is how clear what you're writing is to you, and by extension to others.

As coders, we like parsimony, we like clarity, we like correctness, we like maintainability (meaning best practices for the future and an invitation to other coders to fix and help), we like efficiency, we like fluency (ie, of both writing and reading), and, of course, we like both reliability in general and the power of raw cycles. Most people stick with coding because they like the ever-morphing jigsaw of inventing little gizmos and sculpting and honing and combining them. Like authors, we may enjoy the ideal of "le seul mot juste" (Gustav Flaubert's name for the single best word in context, the one you love and hate searching for), but we recognize that's partly subjective, and often a word that fits well is worth as much or perhaps even more than an ideal word, once you take into account the time and energy demands.

In short, coding, like writing the languages we speak, is both sculpting and engineering; but unlike spoken language, it's pretty easy to check the logic and run some numbers for a rough comparison of efficiency and effectiveness.

To generalize very broadly, the best way to write the chunk of code you need is the way you write it so that it's up and running. After that, improve as much as you need. I've found that in coding, the idea of a first draft is even more important and powerful than in English. There's a saying to go along with that insight, but it takes quite a bit of experience to appreciate how and why it makes sense: "Premature optimization is the root of all evil," said Don Knuth. It's inefficient and even crippling to spin your wheels trying to get code working perfectly before it's working at all. Get something working first, then iterate.

This is critical because of the nature of logic in human minds. Our craniums don't really much distinguish between a) little efficiencies that come from cutting corners, sadly introducing massive logical flaws; b) little efficiencies that preserve correctness only locally, causing problems when generalized or exapted; and c) little efficiencies that are totally correct in a wider context. Computers crash; humans don't even notice a difference. Iterate. Use the power of the compiler and empirical results. It's astonishingly more than kinda useful for some people; it's a deep principle.

I'm not saying per se don't try to get it right. Spend a few minutes—maybe a few hours on a big piece—working out your strategy, if you feel from experience that will help. But sometimes you will find an enormous benefit to giving up on getting it right, especially after those few minutes, and getting started. This seems almost too obvious to say, except it's truer in this domain than in many others for the reasons I've tried to present above, though at best I've only hinted at them.

Think of evolution: if the atmosphere needed to invent you before even getting started on life, none of us would be here today. Life proceeded, and proceeds still, by little perhaps totally blind steps, followed by a filter on results. In the case of evolution, the filter is as beautiful as what's already there: the atmosphere, the biosphere. In code, your little almost blind steps will be filtered by the compiler and the other code you're interfacing with—not to mention other humans who use it all.

I'm afraid I've written something too simple to be worth recording, but I'll hedge that bet by sharing it. It will not be equally apparent to everyone at all times.