Programming more skillfully is primarily about making decisions on which feedback loops you pay attention to, and not getting stuck on ideas about feedback that seem momentarily fashionable or convenient, but lead to bad outcomes later.

Write prototyping code that solves an existing problem as nearly as you can manage, and then figure out how to improve it on one or more metrics:

* smaller SLOC (automatic programming, data abstractions, etc)

* better portability, fewer dependencies, simpler build processes

* better throughput, latency, or resource usage(memory, storage, bandwidth, energy)

* eliminate one or more classes of errors(e.g. off by ones, null dereferences)

* better user interfaces, better documentation and accessibility

* more efficient development of the prototype

* better working environment (workflow, tools and knowledge of the tools, automations for convenience)

Oftentimes, you can make one change and improve several metrics. Other times you sacrifice one to get others. There are bad tradeoffs like code golfing or premature optimization. Having the prototype already in hand is crucial in all cases since it gives you a spec to bump up against when you're at risk of falling off track. If you're more daring this can take the form of an existing shipping codebase.