Whether to build or to reuse is a classic dilemma for most programmers. If you choose build, then you would have to spend a lot of effort designing, coding, testing and debugging your creation. If you choose to reuse, then you would have to pour over all the documentation which would be typically outdated or inadequate in many places.
Initially, most programmers start out as cowboys. They are fearless and fiercely independent. They believe that they can build anything and need not waste time struggling to understand somebody else’s horrible piece of code. It works for a while because they have the skill of programming and we all can program our way out of anything, right? Wrong.
There are many things a beginner programmer cannot do because of the sheer lack of understanding of the domain. Notice that I did not use the word ‘Experience’. You might be able to write a search engine from scratch but it would takes years to return even remotely relevant results for all use-cases (say, something like Google does). You might be able to create a Sudoku solver but a Chess solver is out of the league even for the most experienced programmers.
As you gain experience, you realise that reading code is a skill as important or rather more important than the skill to write it. Similar to any work of literature, you need to understand the classics and read works of legends to become a better practitioner. Extending the analogy a bit further, it would take quite some time before you assimilate all these ‘influences’ and become ready to write in your own distinctive ‘style’. This might take several years.
Even though the industry is slowing recognising the fact that it might take longer to become an experienced programmer, the career path they offer for successful programmers is indeed unfortunate. A successful programmer is generally required to become a manager in order to pursue a successful career. Even if he/she chooses to become an architect, they would be far removed from being a practioner and would be asked to make plans or designs in thin air instead.
In the extremely rare case of a programmer continuing to pursue this domain and excel in it, he/she rediscovers the art of building simpler code. The simplicity aspect must be emphasised here. Great programmers identify simplicity and minimalism with beauty and continue to focus on it.
This explains the almost cult following of LISP among experienced hackers. The lure of Apple products among geeks is not in its shininess but rather in its simplicity. Most software geeks love to tinker with simple microprocessor boards like Arduino or PIC as a hobby project. Possibly with the highest number of computer scientists in its payroll, Google is virtually an ecosystem of multiple small and large projects, each mostly focussed on a singular functionality.
The experienced programmer is not trying to built an impressively complex system that solves many problems here. Instead he is trying to solve a simple problem with simple tools. Why would someone with so much experience do something so counter-intuitive? Younger programmers often use much more complicated tools (such as graphical IDEs) or languages (such as Java or Perl) to attack a problem.
This is not (just) because they are lazy. This has to do mostly with the fact that their goals have changed. They do not find the task of creating something as an end to itself. They would like their creations become a means to achieve some purpose or solve a unique problem. The more simpler the tool they use, the more focussed they are at trying different approaches.
Rather than learning several tools to attack the problem, they employ the most elementary tool possible and try approaches that have never been tried before. Indeed, the solution might be underwhelmingly simple and it might even be obvious. But only when the problem was reduced to its core that such an innovative solution was possible. It might have been obvious all along but the answer was hidden in all those multiple layers of abstraction.
So here is a piece of advice, in case you are looking for one, to anyone who is embarking on a simple project - Choose the simplest possible implementation and build it yourself. If you fail, you can alteast iterate quickly. If you succeed early on, you haven’t tried hard enough ;)
