I know a guy; a developer specifically. One of his mottos is "Don't reinvent the wheel." He believes that Apple and Windows are superior to GNU/Linux and *BSD because "You get what you pay for." He's got a real hard-on for test-driven development, and will adopt a condescending tone if you arrive at a solution without going through a lengthy formalized testing procedure, even if your mental model of the problem is thorough and reasonable, your solution is elegant and logical, the problem ceases to occur for your end users, and to top it all off the problem was not reproducible on the devices you have access to.
It's tempting to demonize the character I'm describing, or to dismiss him as just one particularly frustrating individual, but I've seen symptoms of the same attitude in other developers, and it's abundantly clear that there is a lot of bad and misunderstood advice floating around newcomers to the IT industry.
Don't Reinvent the Wheel, Unless You're in the Business of Wheel Design
I read an interesting article this morning: How the Internet, Dopamine and Your Brain are Working Together to Screw Your Potential. It distinguished between two types of creators: Replication Creators (RCs) and Skilled Creators (SCs).
RCs are resourceful; SCs are innovative. RCs are more keen to look up the correct answer on Google, SCs are more inclined to lock themselves into a room and tinker until they find their own strategy. As someone who has been writing PHP scripts as my primary hobby for nearly 12 years, I've visited both camps and belong to neither.
"Don't reinvent the wheel" is an almost-textbook example of a RC mentality. It assumes that the correct solution is out there, and your time is better spent copying and pasting someone else's regurgitation of a solution they heard from a friend and don't fully understand than trying to understand the problem and develop a solution to the problem that fits your own needs.
Sometimes they're right. Effective time management is one of the many responsibilities that burdens any skilled programmer, and with so many companies going open source, it is in many cases much easier to meet your deadline if you copy and paste someone else's work and read the volunteer-generated documentation than starting from scratch.
Unless, of course, you are tasked with innovation. The trick with being cutting-edge is that the path ahead is not already cleared for you. You have to invent your own wheels, even if inferior wheels already exist and are widely deployed.
Innovation is where regular programming turns into hacking and actually becomes fun. There isn't always a standard to follow; rarely will "industry best practices" be present to direct your planning. You have a problem and often a guideline ("Make it simple"), and ultimately creative freedom. The training wheels are off. This is real SC territory, and people locked into the RC mentality will not thrive under these conditions without breaking down the door.
You Get What You Pay For
This one is actually true, but not in the sense that most people understand it. This is a common criticism of free software. "If it's free, it must not be as good as software that has a monetary cost!" Then they go and drop thousands of dollars on "Enterprise" software. Meanwhile, a 17 year-old hobbyist with a $5/month VPS in the Netherlands just wrote her first database abstraction layer that's faster, simpler, and more secure than the one your Enterprise product uses. Oops.
The currency of free and open source software is time, not money. You don't have to pay Linus Torvalds or the other kernel developers if you want to run Linux on your webserver. You either hire someone who uses Linux, or you give your development team time to learn the ins and outs.
An investment of time is more worthwhile for the individuals involved than throwing money at a problem. Whether or not you stick to Linux, your team gains valuable experience and becomes exposed to greater technological diversity, and may take away many useful lessons for problem solving to apply in other paradigms. Most of my favorite batch scripting tricks were learned trying to recreate shell scripts' functionality in Windows.
An investment of money, by comparison, is rather short-sighted. Obligating one or more of the vendor's employees to hold your hand while providing no visibility of the inner workings of their product isn't conducive to fostering a good development environment. It's great for checking items off a list and skirting responsibility, and sometimes it's the right answer (e.g. when you don't have the available bandwidth to invest in re-educating your entire IT department).
At the end of the day, it comes down to which resource is in shorter supply. But to say that, with Linux or *BSD, you aren't getting what you pay for, is the same as admitting that you don't understand technology or business.
Well, How About Some Good Advice, Then?
Earlier I mentioned an article that established a contrast between SCs and RCs. I recommend reading it if you haven't, because it makes great points about how peoples' brains reward them for discovering a prior art solution in a similar (but not as long-lasting) manner as if they were the first to solve the problem. It's clear from the article that the author holds SCs in higher esteem than RCs.
My opinion is that the best developers are the ones who feel at home in both camps. Confession: Sometimes, I reinvent the wheel; not because I have this arrogant notion that I'm a superior wheel designer, but because I want to know how it feels to invent one, to understand what level of effort went into its design, and to see the brilliance of the wheel-designers who came before me. Confession: I also read a lot of threads on Stack Overflow; sometimes to learn, sometimes because I think I know the answer and want to see what has already been suggested, but usually because I have a specific problem and want to know what has been tried before.
Am I counting myself among "the best developers"? Certainly, and the only reason I can say that with a straight face is precisely because I'm balanced between the two extremes. By that, I'm not claiming to be able to out-perform anyone in their field of expertise; rather, I believe that both resourcefulness and creativity are necessary to excel in technology.
Don't be afraid to write a wrong or ugly solution. Even if it's crypto code (but you probably shouldn't publish it for any reason beyond getting feedback, or use it in a production system). I do it all the time.
It is only through staying abreast of other peoples' efforts and making our own learning mistakes that we can make leaps and bounds in the iterative march towards excellence in programming.