I mean, there are really useful libs that can solve problems when you are stuck and do not know how to solve this or that with your knowledge of programming language you use... For example, Boost for C++ or JQuery for JavaScript or Spring for Java... They solve problems in seconds and you do not really care how they did it (despite that they are written in the very same language you are programming in)... So I wonder am I alone in using libs while not being capable to write solutions for my problems from scratch or is it standard practice?

  • They don't solve problems of individuals, they are just a solution for common problems in the related areas. Jan 31, 2011 at 5:25
  • so is it OK not to know how to solve common problems in the related area and say "just use ***(your favorite lib here)" it would fix it not getting into how they actually did it?
    – Kabumbus
    Jan 31, 2011 at 5:28
  • 1
    Have you ever programmed scalable programs? Honestly, no library is perfect 100% of the time, and bugs are bound to happen. Now if that bug happens to reside in one of the many external libraries you're using, and 2 years down the cycle of development you start running into problems, and what do you know? It's one of those libraries you're using! So to be frank: no it makes no sense to use libraries as quick fix (at least not for enterprise-level software, etc) because they become somewhat of a limitation the further down the line you go.
    – jerluc
    Jan 31, 2011 at 7:32
  • 5
    @jerluc: standard libraries are often far better developed and supported than any one organisation's code. For example, boost's shared_ptr is considered a "must have" by everyone in industry that I've come into contact with and various other pieces of code provided by boost have allowed the project I work on to focus on the details of the problem and not spend time working on some less important stuff that's already been done. You can experience problems down the line, so you should be selective of the libraries you pick, but generally they're good. "Not developed here" syndrome is bad though.
    – TZHX
    Jan 31, 2011 at 9:00
  • @TZHX I suppose I should be more definitive in saying that what I stated applies mostly to libraries which may do such things as wrapping what could be considered "boiler-plate" code. It makes sense to trust the "invented wheel" by not writing IO wrappers (when libraries are available for such wrappers), but it doesn't make sense to trust a "somewhat round wheel", or in other words, a library that does some sort of black-box magic and works for what you need it for at that moment.
    – jerluc
    Jan 31, 2011 at 9:19

12 Answers 12


Is it ok not to understand how to solve the problems yourself, and use libraries instead?

In the general, no, it's not.

A library can save you the (hard!) work of figuring out how to solve a problem, and then debugging the solution, and then, maintaining it. But, if you're going to use it, you'd better make sure you understand how it works - why the solution actually solves the problem. You don't have to know how to invent cars, and engines, and robots that build car engines, if you're working as a mechanic - but you'd better understand how the parts work, what they all do, and how they fit together!

This is the reason why you will see many people become very specialized - many times only learning how to work with a single language, a single platform, a single framework and set of libraries.

That being said, there's only so much you will have time to learn. Sometimes you've got to take shortcuts - take them, but know they are shortcuts. Maybe you only read enough about a library to know you could figure it out, if you had the time. Or maybe you only figure out the two functions that you actually need to call, and only enough to make the calls correctly. That's a shortcut, which will come at a price - usually later, when someone (maybe an older, and more experienced, you) has to fix the code.


Yes - and we all do it!

Let's take, for instance, a very simple bug I was fixing in some Mac-related graphics code. The code around the bug involved several steps:

  1. First, an Objective C method allocates a pixel buffer using malloc(), and attaches that to its Objective C object.
  2. Later, something happens, and a C routine sends a message to the Objective C object and retrieves the pixel buffer.
  3. The C routine compresses the pixel buffer contents using jpeglib, and sends it out over a TCP/IP connection.

There's an awful lot going on there! Here are a few things:

  • A dynamic memory allocator to implement malloc(), which assumes memory is physically contiguous and linearly addressable.
  • The underlying Darwin kernel virtual memory system to map both fragmented physical RAM, and disk space (which is a different physical device from the RAM), into something that appears to the dynamic memory allocator like it's physically contiguous and linearly addressable RAM.
  • Objective C's object system
  • The Mac OS runtime messaging system, and the way it interacts with Objective C objects
  • The jpeglib library's implementation of the JPEG lossy raster image compression standard, which uses a discrete cosine transform algorithm
  • The userspace networking routine for sending out the data, which calls through the various TCP and IP protocol implementations, which in turn calls into the OS kernel. Then depending on what you've got turned on for your networking, it may call a driver for the Ethernet port, a wi-fi chip, or more unusually a USB or Firewire driver.

Do you understand all the details of how all those things are actually implemented? I sure don't! I doubt there are very many people on the planet who do - maybe even none. So I just don't worry about it.

But it's a good thing to be curious, and to learn at least a little bit about the libraries and tools you use. When I first started programming, I knew compilers and operating systems couldn't be magic, but they sure seemed that way to me. By indulging my curiosity about those things, I've learned an awful lot and had a great career so far.

  • 1
    If I were to understand all the code I use routinely, I'd need to understand data compression including JPEGs, geometrical data representation including everything in <i>The Nurbs Book</i>, the intricacies of the PDF and U3D formats, and much more. I've got references on everything, but I'm never going to have all of this down pat. Jan 31, 2011 at 18:17
  • I must admit that I do not always understand in detail every building blocks I am using to write working code, but I feel unhappy when this happens. Understanding, or at least knowing that if I need to, I can understand the base components, makes the life much easier. I am glad I know how an allocator works, what principles are used to compress a JPEG image, how TCP/IP works, how virtual memory might be implemented, how a CPU does its work, etc. Having all these low level details abstracted away is good, but not having access to the details feels really bad... Jan 31, 2011 at 20:02

Once computerworld.com.au asked Bjarne Stroustrup "Do you have any advice for up-and-coming programmers?"
And he answered "Know the foundations of computer science: algorithms, machine architectures, data structures, etc. Don't just blindly copy techniques from application to application. Know what you are doing, that it works, and why it works. Don't think you know what the industry will be in five years time or what you'll be doing then, so gather a portfolio of general and useful skills. Try to write better, more principled code. Work to make "programming" more of a professional activity and less of a low-level "hacking" activity (programming is also a craft, but not just a craft). Learn from the classics in the field and the better advanced textbooks; don't be satisfied with the easily digested "how to" guides and online documentation - it's shallow."
Hope it will clarify your doubts about what is required for a True Programmer and what is Necessary for anyone to be one.

  • 5
    +1 - I think it's important to note that -- while I 100% agree with Stroustrup -- the OP shouldn't get the idea that this means he should reinvent the wheel on every single thing he does. The main reason why Computer Science education involves implementing the String class and MergeSort and other algorithms is so that when we use the libraries available in our language of choice, we'll understand what goes on under the hood. Deal with enough libraries with a good understanding of the foundations, and one can pretty much predict what is under the hood of library X, Y, or Z.
    – jmort253
    Jan 31, 2011 at 7:42
  • Coming form the man who needs several dozens of paragraphs to thoroughly analyze, justify and explain why the particular brand and flavor of tea piqued his interest, whilst completely forgoing the point of the initial question. BUT, I still love him! Jan 31, 2011 at 18:15
  • 1
    Frankly, I know a whole lot about algorithms, machine architectures, data structures, and lots of other things. This doesn't mean I understand what each of our third-party libraries does precisely, or even all the theory behind it. I think this is all good advice, but it doesn't translate into having to know everything about your app. Jan 31, 2011 at 18:21

I find the main reason we use libraries is to not "reinvent the wheel" all the time, abstracting the problems they intend to solve. You could try to solve the problems yourself, but that would take longer time.

However I do feel that we also need to know or guess how the problem is solved by the library. This is usually documented in the library´s user documentation and with open source software, you could always look at the code yourself.

Also we usually solve problems by abstracting the difficult parts anyway, so why isn't it ok?


The libraries are there to provide solutions to common problems. You need decide if they solve the particular problem that you are solving. They are NOT a substitute for not knowing how to solve a problem. For example, suppose your application requires a hash table, you should have enough knowledge to understand what problem a hash table is solving. You should be able evaluate the performance of the library you are using to decide whether or not it will work in your application. I believe using a library to cover for inadequate technical knowledge is not the correct use case. The decision to use a library should revolve around whether or not using library will speed up development and provide a tested and reliable solution. The decision to use a library should not revolve around the programmers inability to solve a given problem.

  • That would mean that, for my current project, I'd have to know the details of the PDF and U3D specs. For a certain grad school project, I'd have had to know a lot about certain linear programming algorithms (simplex would have been hopeless for my case). If it were necessary to understand exactly what a library is doing in order to use it, I'd never get anything done. Feb 1, 2011 at 19:30
  • I am not claiming that you need understand all the details of the implementation. But should know what to expect from the result. Take the hash table example again. If you are seeing poor performance then how do start evaluating the reason. The first thing I would start thinking about is the collision rates amongst my keys. If you have no idea how something works then how can you even start hypothesizing about reasons something is not doing or not performing the way you expect?
    – Pemdas
    Feb 2, 2011 at 1:20

Up to you, really.

The best you understand the tools you are working with the better you can take advantage of them.

For example, I rarely use jQuery, but when I have to I know what to take advantage from it, and how can I make it coexist with other frameworks like Mootools.

Also, soon I'll adventure into gamedev with UDK, and I'm sure the more I understand about it the more I will be able to bend it to my evil will, but I could also just follow no-brainer tutorials. I choose the first, just a little extra time and brain cycles and I'll get better and easier results.


It's important to know your realm, and your part of the process.

For example, say you are using an image processing library. Do you really need to know all about gaussian blurs, transformations, and color spaces? No. But you do need to know why you are using the library in the first place. Or a framework's sorting function. Do you need to know the actual sorting algorithm used? In most cases, no. But you do need to know why you need the data sorted.

On the other hand, if you are writing a compiler, you darn well better know how a compiler works, since thats your part in the process.

Certain frameworks like jQuery abstract away a lot. Do you need to know how exactly they are working? No. But having a strong, fundamental understanding of what the library is doing will be very beneficial to you as you write code because you will understand better why the framework is made the way it is, and be able to use it to its full potential.


Upon my experience: since you can't eliminate the library-dependence, you and your team should know enough to solve the problem.

As programmers, we have little time, so we must choose the one which has highest priority. The problem must be solved, as fast and gentle as possible. Only this reason makes "learning all about things work" somewhat redundant.

The things I want to add here is "dependence". As a community, we are all dependent to others. We stands on the Giants to build our application: Java, .NET, API... And we trust the Giants about their work; because it works for so many people. If you have a problem about the framework, or API, there's a good chance that others have faced it somewhere, and there's a solution/work around.

The only problem here: maybe, somewhere, in a restricted criteria the Giants collapsed. For example, flash is not supported in some OS, and there's many things we couldn't do without it. This possibility is more than zero, but in this case we have little things that we can do. Only in these cases, the knowledge about "what is behind the hoods" proves useful, as it point out where the problem truly is and may create a big work-around; but I am not sure the time we invest really worth it.

To cope that possibility, I think there's a solution: because most of programmers can easily catch the "surface working" of a library, and only sometimes we really in need someone who is very well-understanding: let divide the team to do that. Trying to comprises a team that each one has experted about 1,2 useful libraries/tools/"skill set" that involved: one has good experience about jQuery, one has specialize with database, ... This will help much in minimizing risks.


Another point of view is security. When you use a library of which you don't know the exact inner workings, then you make assumptions about what's exactly happening. Each failed assumption may open an attack vector for a malicious attacker.

When calling a Quicksort, then you should be aware about the worst case behaviour. Else an attacker may be able to inject worst case data and to perform a DoS.

When calling a compression library, then you should be aware that when some data compresses to less bytes, then there must be data that "compresses" to more bytes than the original. So when your assumption is that the output buffer only needs the size of the input data because it compresses [to less bytes], then there is a buffer overflow waiting to happen.

You should know enough fundamentals about the things you're going to do, to be able to prove your assumptions true. Else the library should explicitely take care for this, e.g. throwing an exception when the provided output buffer is not large enough.

  • 1
    Allocating fixed-size buffers for anything is a buffer overflow waiting to happen. Much better to use a language that supports dynamic arrays and let the callee manage its own buffers. Jan 31, 2011 at 17:37

It's OK to not understand everything you use as long as you are sure it works. Once you are bitten by a bug in the lib then there's time to see how it works, why it works and why it doesn't. Of course you are always welcomed and encouraged to look under the hood even if you don't have to.

One of the hard things in programming is overcoming temptation to solve all the problems by yourself.


It is ok but it is dangerous. As general practice, one should know working of what he has developed.



It's fine as long as you get the general gist of what the library or framework is trying to do. As for the internal parts and what not then, no. Take the pragmatic approach. It works, it did what I want it to do, alright.

The point is to not get boggle down with bunch of small details and just implement your damn idea already.

I guess, the point is, you ain't going to know everything. Seriously, you have so little time to investigate everything, because it'll distract you from your main goal of creating that idea of yours. Little by little, perhaps, you can set a side some free time on the weekend to read up a chapter or so on the subject.

But don't try to figure everything out, unless you have lots of free time... Look at it this way. The reason for programming languages is the shield us from doing assembly code, the reason for assembly code is to shield us from doing 1's and 0's. I don't think you need to know every fine details of the mechanism behind it, but just know the general gist of it. Like a garbage collector, I know it going to deal with my pointers/memory, I don't care what magically neat algorithm it uses, I just know it works (for what I need) and it doesn't do any else. Maybe the con of it but meh. Unless of course you're in the field where you have to deal with it. Then you wouldn't be asking this question anyway cause it's part of your job haha.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.