When you were in school ... at least (koff, koff) when I was in school ... you had to do a lot of stupid things. Such as, "implement a linked list." Or, "build a fully-functional B-tree implementation from scratch."

Today, I still see far too many intrepid programmers trying to be Christopher Columbus: sailing away as though they were embarking on a voyage to an unknown world. Fully prepared to start with a blank text-editor screen and an empty directory.

"Okay, school's out!"

Today, no matter what it is that you are setting out to do, "it has already been done (to death)." Therefore, your project should be seen as a continuous re-play of this decision: "Build, Beg, Borrow, or Steal?"

Fortunately, you don't have to beg, you don't have to borrow, and it's perfectly okay (hey, I'm not speaking literally here ...) to steal. There is a vast amount of "contributed code" that is readily available for whatever programming language you are using. For instance, at this particular moment, Perl's CPAN library contains 122496 Uploads, 35981 Distributions, 194527 Modules, 13336 Uploaders, and by the time you read this there will probably be more. Complete applications can be found at places like GitHub. "Web frameworks" abound at every possible level of sophistication. Elegant pre-existing solutions exist to almost every conceivable obstacle, in every language.

Thus, the first step in any project ... and, at every turn thereafter ... should be: research.
"Stuck in existing-application hell, but tasked to create a new feature?" You can still go to these resources for source-code examples of good ideas.

- - -
And, in the same vein, when you think that you have to "write a bash script" in order to implement "a new command," think again. If you take a look at the source-code of most of "the scripts that you know and love," you will discover that most of them are not "bash scripts!" They're programs written in some high-level programming language or another, prefixed by a #!shebang line which causes bash to silently invoke the specified language to carry it out.

This, of course, means that we have come full-circle: if we don't have to use bash's primitive built-in scripting language to actually construct our new script, we can leverage(!) great quantities of existing software to let us get the job done ... quickly.

- - -
Therefore, "now that school's out," re-arrange your mindset to presume that, "whatever-it-is that you are faced with now, you are not the first." (Nor will you be the last.) You should begin – not with "coding" but – with research. Thousands of generous people have created things for you, and they don't mind in the slightest if you "steal" what they did.

Whatever you do: "Don't ... start ... from ... scratch."

To the degree that you seem to emphasize research to mean search for existing code, I disagree with this premise as a general rule to be followed (although I think there may be a special use case for it*).

The first rule should always be to understand the problem at hand, and then to model both the problem and potential solution(s) - even when it seems trivial. Doing both of these things may involve research, but that should be the search for knowledge and understanding, not code!

If you don't understand the problem then you won't be able to make good use of the code others have written to solve it. In fact, as happens very often and is repeatedly demonstrated in fora such as this, by looking for available code solutions too early you can end up spending vastly more time (your own and other's) troubleshooting code you do not understand and which may not, in the end, be appropriate to your real problem! This is the very seed from which X-Y problems often sprout!

On the other hand, once you understand both the problem and one or more potential solution models, only then are you prepared to look for available code. You can then evaluate the applicability of a given piece of code to your problem by determining whether or not it fits the model, or whether either model or code can be adapted to make a good fit.

Once you have a working model, you have already eliminated a fair number of lines of useless or inappropriate code you would have otherwise written, or borrowed (i.e. most problems become simpler). Without it, you can never really know the full effect of any code and today's quick solution often becomes tomorrow's obscure problem.

*Special case: When you tend to use a limited tool set for most problems (perl for example), you will expect to become very familiar with the language AND with the libs, modules and contributed code base available for that language. You may then more quickly go to the code search phase for many use cases, primarily because you come to more quickly see the models by virtue of close familiarity with the tool set.

@sundial
Well for a beginner my advice is always Do Not Just Learn how to program, figure out how it works and you'll learn in the process.

But yes you do have a point, every programmer should have/has his favorite functions that he uses cross-application so he doesn't reinvent the wheel. But a programmer HAS to know exactly what's going on in that code he just copied.

return 0;