Using libraries instead of reinventing the wheel: Great! That’s how everybody should do it. You don’t get paid to do what’s already done.

Using snippets: As long as you understand what you copy-paste, and as long as you invest the time to make it all consistent (instead of a patchwork of different styles and approaches), there is nothing wrong with it.

Coding is the lowest level of programming in fact. The higher level of abstraction you can get to, the better programmer you are. Choosing right libraries (not necessarily open-source ones), properly connecting them together and maintaining the construct is much harder yet more efficient and time- and cost-saving, than writing everything yourself.

good programmers write good code;
great programmers steal great code.

I love to write my own libraries. I also love to get my projects done on time. I think over time, most good programmers build up a collection of useful and re-usable bits. I don’t know about you, but I get a great feeling every time I use a library that I wrote five years ago.

There is absolutely nothing wrong with using library code that has been tested and loved over time. You know how it works, you can count on its complexity and you can implement it quickly.

That being said, I’m assuming that you understand the code in the library. I’m assuming that, if given sufficient time, you could implement something of similar quality.

I know some really good C programmers who could implement the standard C library, a few of them that have simply as a learning / sharpening exercise. Some of the most fun I’ve had during hobby time was working on the C library in HelenOS.

So, there’s nothing wrong with using library code, as long as you continue to be curious and learn. It goes without saying that you should not use code that you don’t understand, unless your use of it is an effort to understand how it works.

I’ll go one better than some others in this question: I don’t even think the “client” developer of a library needs to “understand” the code in that library.

I’m a (compared to some) relatively new iPhone developer. There are LOTS of libraries that I use every day that I could never have generated on my own, and the code of which is way over my head. Doesn’t matter in the slightest PROVIDED:

1) I fully understand the interface to those libraries (I’m an ASIHTTPRequest ninja!)
2) I’m picking libraries that are in general, broad use, so I can be sure they’ve been well gone over and explored for problems (eg: ASIHTTP, Stig Brautaset’s JSON library, Facebook’s obj-c library, etc.)
3) Failing #2, it’s simple enough that I could pick my way through it and find/fix/customize anything that needs finding/fixing/customizing.

That #2 is going to be the contentious part of this, I’m betting. The fact is, I am relying on the open source community, a community of developers that is certainly more experienced and quite likely smarter than I am. But that’s the whole point of open source. So, there you go.

I’d like to throw in a warning for using libraries. As a frequent user of scientific libraries in Perl an R (and some in Java), I often had to hack into a library to avoid hideous overhead cost. Using libraries is great, but more and more libraries are themselves dependent on other libraries, which calls a third library that uses the standard library to do a rather common task. And each step in the process requires some checks of input and output. Quite a lot of those checks are completely redundant, but they weigh on the application nonetheless. And when used in a loop, then can start to weigh quite heavily.

Next to that, you can’t be sure that libraries always keep back-compatibility, or do not contain bugs. In fact, all libraries contain a few bugs, that’s the nature of code. Hence, the more dependent you are on libraries, the more potential bugs you enter in your code. And those bugs you can’t solve yourself that easily without hacking into the libraries again.

Using libraries is a very smart decision, but if and only if you know the libraries and their behaviour pretty well.

I know, thinking hurts and computers are cheap, but still. Not thinking can hurt more.

Usually, copying large amounts of source code is poor practice. If the code was developed for another application at your company, then you should reuse the code by extracting it into a library to be used by both applications. You should not copy the code. Copying the code will force you to maintain two copies instead of one common copy.

Code reuse is a very good idea. It reduces redundancy and promotes maintainability.

The title suggests you are using the code as a library, but the text of your question implies you might be copying the source code into a new project. I’d stick to using other developers’ code as a library as much as possible.

There is a problem if the code is bad or somehow broken or based on a model that doesn’t fit your application very well. In that case it might be simpler to scrap some or all of the code and start from scratch than trying to understand why it was written in a given way. Keep the other code around for reference, though; you may come across an issue that you aren’t sure how to solve. Chances are the other developer probably came across the same issue, and it’s worthwhile to see how they solved it.

That’s generally a good idea, so long no legal issues exist.

However, make sure you take the time to understand what the library does and how it does it. Using a “magic” library to take care of things you don’t understand is a good way to have some part of it blow up on you because you used it wrong, and then you have no idea how to fix it.

Legally reusing code has almost no downsides and two huge upsides:

1. It gets the job done. This is the more important one for professional development. Ultimately, you have a well-paying job because you know how to make things happen that would stump most non-programmers; reuse allows you reach that goal faster, so you become more valuable in your job.
2. You learn stuff. This is the more important reason for self-improvement. There is no better way to improve coding than to read good code written by others. Even bad code written by others usually teaches you something! And there is no better way to understand how a library, API, language, or domain works than reading and improving solutions already written by others. Both things usually happen when you reuse existing code, because no pre-existing solution will ever do quite what you need – and the ensuing tinkering with the source is where the knowledge boost comes from.

Does heavy library and code snippet usage make you a bad programmer?

If you use libraries and code snippets in appropriate places, then ‘No’, it does not mean you’re a bad programmer. It means that you’re a smart programmer who can apply the wisdom of others in appropriate places.

However…

It takes time to find libraries and code snippets, so if you can’t write code on your own, and you need to spend hours to find libraries and code snippets to implement trivial tasks, then ‘Yes’, you are a bad programmer.

For completion purposes, allow a counter argument:
http://web.archive.org/web/20150326134617/https://michaelochurch.wordpress.com/2015/03/25/never-invent-here-the-even-worse-sibling-of-not-invented-here/

a mentality that I call “Never Invent Here” (NeIH). With that
mentality, external assets are overvalued and often implicitly
trusted, leaving engineers to spend more time adapting to the quirks
of off-the-shelf assets, and less time building assets of their own.

There is always a balance.

No. Programmers should use libraries which are already out there. No re-inventing the wheel. If you have a better method, you can go for it, else what does it really do in writing the same code. The only thing is you should know what the code is (and only if it matters).

In addition to the reasons in the other answers, not using the code (as long as it’s a good fit for your problem) can be considered unethical because:

1. You might be intentionally wasting your employers time OR
2. You might be intentionally delivering a lesser product

Keep in mind, both of those are hard to determine beforehand.

Also, look at Not Invented Here, which commonly referred to as an anit-pattern.

I am for not using libraries unless absolutely necessary. Dependencies limit portability and lifespan. I have 34 years in software development and would like to have at least 1 of my programs last longer than 3 years without being destroyed by erosion (change).

COM (Component Object Model), the answer 17 years ago, in theory great, in practice questionable, reusable components not really, I will only use the very basic components and only if I have to.

APIs and SDKs not much use. If I break down the number of lines of code that I actual use out of a library, the time I spend getting them to work vs. writing them, I think it’s a wash. I quit using SDKs completely the overhead is extreme.

Frameworks: Zend, Silverlight, WCF, .NET, the layered systems, yes they can speed initial development, but when I hit their limits, the time I spend fixing the cracks, just isn’t worth the effort. How old are they and are they impervious to erosion?

I have gone to JavaScript and HTML with only my libraries. I have stripped JavaScript down by using only the most common statement types. I hope in 10 years I can write something that will last.

It all depends. If you are coding a game then it makes since to use a library (ex. Allegro) but you can’t really be considered a programmer if you’re copying/stealing/borrowing (whatever) other people’s code. I say no reinventing the wheel but to a reasonable point. Don’t make your entire program of snippets that other people wrote. Sit at you computer and do it yourself…stop stealing code. People have gotten too lazy these days and just copy and paste.