Source: CS major with 10 years experience in enterprise development, support and systems architecture consulting. While it's always possible to be a developme

Source: CS major with 10 years experience in enterprise development, support and systems architecture consulting. While it's always possible to be a development autodidact, and in fact to be quite productive this way, there's a reason why the theory and practice underpinning good software have been codified in the study of algorithms. Shortly said they are knowing your tools, knowing when to use them, knowing why to use them, and recognizing their strengths and weaknesses. And finally knowing these things instinctively, not just casually, so you can diganose complex issues in terms of understanding their larger moving parts, and not just the low level details. Knowing your tools: Anyone who has debugged code where some critical component is based on nested arrays or other representation with similarly poor scaling characteristics, and banged their head on the desk on reading the code, will understand this one. If you aren't even aware of a possible range of workable, if not optimal, solutions for a given problem space, then you are unlikely to come up with a stable and high performing solution. Knowing when to use them: On a practical level, it's important to know the proper use of the tools available to you (and how to recognize when one is not well suited to the task at hand). Having a clear picture of the applications where X versus Y representation or approach will perform better is critical to being able to accomplish the 'big picture" task effectively (whatever that may be). Recall that nearly all mathematical and CS proofs will refer to other, more well-known concepts in establishing newer concepts; in the general case the proof of any given algorithm's workability can be expressed in terms of its reduction to another well known, well understood solution. The same is true of your code using a well known library that implements any one of these. Knowing why: Similar to "when", but a little more nuanced. On a philosophical level, it's useful to separate the problem-solving aspect of the job from the creative aspect, and avoiding re-inventing-the-wheel when it's not needed to solve your unique problem (hint: it's probably not that unique). In other words, if you have a finite budget of mental effort to expend upon a given programming task, you'd be better served by ensuring you meet the low level requirements of its implementation with an algorithm that you understand intimately, than laboring through a hand made solution for a problem whose details you might not know anyhow. (Of course, see also "if your only tool is a hammer" -- laziness is useful, but only to a point.) Instinct: Experience goes further than simple knowledge, because the units in which you "think" are constantly changing. In the same way that a chess master sees more possibilities and nuances in the opening moves of a chess game than a novice can see in individual pieces, a novice or even skilled autodidact can not bring to bear the same skills as an experienced programmer with intimate working knowledge (if not extreme detail) of a wide range of possible approaches to a given solution. Finally, consider that nothing I've written above precludes "creativity" -- it simply provides you a tool kit that moves the bulk of mental effort to a higher level of execution.