There are two sides to this medal.
On one hand, while there is a lot of code already around, there are also lots of bugs in this code. It may have been tested only on very small data sets, and once you run it on much larger data it becomes incredibly slow. Or it is closely tied to 2 dimensional data, to a particular data type, whatever. So when reusing existing code, you may end up discovering that it is incorrect, slow, or needs rewriting to work with your data.
On the other hand, you are likely to also make some errors or decisions that limit your codes performance. These issues may already have been fixed in the existing code. Using existing libraries may also give you functionality that you didn't deem necessary in the beginning, but find very valueable at the end. Plus, it may give you access to comparing it with other methods, visualization, debugging, evaluation etc.
My recommendation is as follows:
Do look for existing codes. But check them if they are actually written and designed for extensibility and reuse. There are some good examples: libSVM is the de facto standard for support vector machines, and it's used almost everywhere. There must be bindings for 20+ languages. Instead of rewriting SVM, this one is definitely code to reuse. Or ELKI, of which i'm quite a fan, is a Java framework for clustering and outlier detection (doesn't have machine learning yet, though). It takes a bit to get used to it, because of its mixture of object orientation and weaved-in optimization. But this makes it surprisingly fast (definitely outperforms R for me) and a lot of the stuff can be implemented in a few lines and then will still benefit from these optimizations. What makes this reusable is the modular architecture. I've written a customized distance function, and can use it it all the algorithms, and written an algorithm where you can plug in arbitrary distance functions. I've tried these things in R before, but either the module was limited to Euclidean distances and such, or it would need a distance matrix in memory, which takes $\mathcal{O}(n^2)$ memory and time. Plus, in the end I can do thousands of combinations distance+algorithm+index for comparison to see if my new stuff is good for anything. For example I learned this way that Canberra distance works surprisingly well across a number of scenarios, and would often be a much better choice than Euclidean distance.
On the other hand, there is a lot of code on the interwebs that is crap. I was looking for the OPTICS clustering algorithm. I found Matlab and Python versions: http://chemometria.us.edu.pl/download/optics.py but both of them were crap. Slow, and the result was essentially a DBSCAN result. OPTICS in Weka has a nice plot view, but doesn't really cluster, and it's incredibly slow. The ELKI version of OPTICS was a completely different league! I figure that someone just dumped whatever they had arrived with, but the code was never reviewed or even properly tested. The python version apparently is based on the Matlab version, which maybe was transscribed from the incomplete Weka version. Ouch!
