Why do newbie programmers seem to shy away from libraries?

Question

I've noticed many questions on here from new programmers that can be solved using libraries. When a library is suggested, often times they respond "I don't want to use X library" Is it the learning curve? or ? Just curious!

Answer 1

It's the learning curve.

Answer 2

Almost always it's because their professor has told them that they can't.

Sometimes it's just because they want to learn it themselves, but I'd say that's rare.

Answer 3

I always have this urge to do it myself, but sometimes I can see my own limitations. Just recently downloaded a library to create PDF documents, but thats pretty much the only time I can remember.

At least for me, (trying to) do things myself, is my way of learning.

My impression is that many newbie programmers wouldn't consider it their own work if they were to use someone elses libraries.

Answer 4

I don't think that this is necessarily a bad thing. Using libraries is great; it saves time, effort, bugs, etc. However, you learn very little in the process, and for new programmers, learning is the goal. To answer the question, I think that they tend to shy way from libraries simply because they are not used to using them and perhaps they don't know that they exist.

Answer 5

I think the professors want them to stick to the basics. When I graduated from under-grad school, I knew C++, Java and some other languages but had no clue about libraries and frameworks being used in companies. It was like do you know java..yes..can you write a servlet..no.

Answer 6

When you're still learning the ins and outs of a new language, also having to learn how to use a 3rd party library can look like too much work. Also, libraries tend to be badly documented - or at least have documentation that seems totally opaque to a new(er) programmer.

So, faced with trying to solve problem X, saying "use a library" can sound a lot like "solve problem Y THEN problem x".

(Also, their professors told them not to. I managed to get all the way though my undergrad in C++ without learning the STL existed. Boy, did THAT cook my noodle.)

Answer 7

Because part of maturing as a developer is learning to quickly identify problems which can be solved by a library or existing solution and which need personal attention.

Answer 8

For many poorly documented libraries that are either implemented loosely or in languages that don't allow you to control containment and visibility very well, it can be quite difficult to guess just how the library is supposed to be used.

After you've used it for a while, you've gotten used to the quirks or read other source code that taught you the right way; but until then it can be pretty irritating to use a poorly put-together/designed library. (or even a well designed one that isn't terribly well documented).

If you don't have the source code to the library, that's another problem--you have no control over the ability to keep your program working. This is much more rare these days, but still happens in the case of a purchased library.

Answer 9

I think there's a lot of time that needs to be invested in understanding the library's purpose - yes, a learning curve, but it's more that newbie programmers probably don't know what they need until they have a lot more experience.

Answer 10

For speed demons they rarely use 3rd party libraries and new programmers are usually looking to squeeze every once of speed of of their code. I think if they don't have control over their code they can't get the performance that they are looking for. At least thats why i avoided libraries when I first started to program.

I remember programing my first DAL and avoided all the other free libraries out on the web because I wanted my code to perform at top speed. Later, I discovered that usually its not the code thats the bttleneck its actually the database.

Answer 11

I'm a programmer, not a psychologist! :)

It was a long, long time ago for me, but it was because I wanted to learn and experience. I didn't want to use something I did not understand, so if I didn't think I understood the library and could program it myself, I tried not to use it. There might have been a bit of fear too; programming gives you a feeling of control, and using a library is like giving away this control.

Answer 12

When you're trying to learn how to do things, anytime something is accomplished "magically" by calling AwesomeClass.doAwesomeStuff(), you end up giving away a portion of control. When you are "new" and don't know what you're giving away or why it can be unsettling. This was my primary knock against Rails when I was first learning it. So many things just "worked" and I didn't know why without digging through lots of Rails source (which I generally didn't have time to do).

At least, that's my take on it.

Answer 13

Some open source libraries are buggy or not as efficient as others.

Answer 14

A lot of new programmers are still working at a very low level of abstraction, learning the trade. That's something everyone has to go through. It takes a while to "move up the stack" so to speak.

Once programmers realise that they spend most of the time solving the same problems as someone else already did, and the goal is to realise "business value", then they can really appreciate the value a good library brings.

Answer 15

Some people, when confronted with a problem, think “I know, I'll use a library.” Now they have two problems.

Seriously - this is a reasonable way for a newbie, already overwhelmed by new language, programming environment, paradigms, keystrokes, etc. to react to the suggestion to use a library. If you've got a solution, but it's not working, there are many potential sources of error; sorting through them is a challenge. Adding to them can seem irrational.

"Use a library" means find the library, download it, install it in your project, and call the necessary function. Not hard, if you're used to it (and there aren't corporate policies against it, and you have reason to trust the vendor, and the library itself has minimal dependencies, etc.). But if it's all new to you, when you ask a programming question and get back a system configuration answer, it can seem unhelpful (even if it is not, in fact).

Answer 16

More libraries = less billable hours.

Answer 17

Because it's fun.

Answer 18

I remember shying away from several libraries simply because I wanted to see if I could create my own algorithm. I didn't want to just give up and let someone do the work for me but rather I wanted to learn from my mistakes. Once I had come up with a solution I was happy with, I looked into the libraries.

So for me it was simply wanting to see if I could do it.

Answer 19

Most of the points covered off (for me the main one is the learning curve) but one other I think plays a part:

Because learning about a library is less exciting than coding the same functionality yourself.

Answer 20

The same reason that more experienced developers do -

Because it can often be as difficult to learn how to use a library as to write the part of it you need yourself. And at least then you can understand how it works when it doesn't do what you expect.

An experienced developer just has experience at understanding how to use libraries so more likely to consider it. An inexperienced developer it's one more thing to learn...

Answer 21

In my eyes another factor is that additional libraries add complexity. Programs tend to get harder to understand, harder to maintain and buggier when getting more complex. I think what makes especially new programmers shy away from libraries is that adding library code increases complexity more than adding your own code - simply because understanding how the library works is still out of their grasp. So it seems to be a problem of both skill and psychology.

Answer 22

• newbie programmers not only means guys who just started learning programming, there are cases including people just started learning new languages.

  • learning curve is acceptably the most preferred one, apart from that, people learning new language often don't have that luxury to go to the frameworks suggested.

It's not always easy to compromise your managers to go ahead with the new framework. It requires lot of testing and have to study how this should fit in to your needs.

See my case, I am basically a c# programmer and started learning javascript for my work. Some time ago here in stack I have asked a question about the javascript puplisher/subscriber pattern. Most guys responded telling me it's already been implemented in frameworks like JQuery and prototype and you can easily reuse them.

Cheers

Ramesh Vel

Answer 23

I think more fundamental issues can be recognized as a deterrant to using existing libraries.

1. Part of this as "newbie programmers" is a lack of exposure to libraries. If you don't know they exist, how do you know to use them?
2. Number Of Options Available. Let's say I'm really interested in learning more about MVC, but if I have to choose between cakephp and smarty and zend and ... well you can quickly see the gears work to discover a way to achieve the goal without investing the time experimenting. Take a look at Freshmeat or SourceForge to get a better understanding at the daunting selection of libraries available.
3. Questionable support combined with sketchy/outdated documentation for the libraries. Do I want to use this tool that may no longer work or may be abandoned in the future? It is likely that a project will evolve, and so it will for the project of a library too. Will its usefulness last the lifetime of my project or will I be required to re-do this work again?

Answer 24

Libraries often come with the overhead of learning some API and it's paradigm. It can get complex fairly quickly, and I could easily understand that beginners would prefer something a bit more in their comfort zone. From my experience, I found most libraries & frameworks seem to do a great job abstracting some tedious routine, but when I need to either extend this functionality, or use it in a way that's not intended, it can be a handful.

I think it's one of those things where "practice makes perfect".

Answer 25

Using a library requires you to understand the relatively complex design of the library, something that new programmers might not have mastered because all they've ever written is simple/procedural/single-purpose code. For example, to an experienced programmer standard design patterns like template method, observer and command seem pretty obvious, but to a newbie it all just seems like magic and/or unnecessary complexity. For me the turning point was when I got good enough to grok design patterns and write some basic reusable code.

Answer 26

It's been a long time now, but when I came out of college, I knew nothing of libraries. This was in the days of mainframes and mini-computers. Our college had a VAX and the managers were paranoid about students hacking the system, so didn't allow us to even see the library manuals. So, when I first came out of college, I didn't even think of libraries being available.

Answer 27

Well, the newbie's purpose might be more solving the problem than implementing a solution. Perhaps what they really want to do is figure out how to solve the problem. I mean, if they're still heavily in the learning phase, it's quite possible they don't want easy answers handed to them.

Answer 28

I am sure there are a lot of reasons why the newbie doesn't want to use the new library. But wouldn't this be a good opportunity, if you have enough time, to show them what the advantage of using the library is? With the people I work with, I will usually provide an example of why something is better than their approach. It helps them learn and mature as a programmer.

Answer 29

Happens that noobs use Libs without knowing, but when they must import/add one that is fairly less documented, there is a fear of unknow. That happens mostly for compiled langs!

In the interpreted, (or compiled IRT), mainly when there is a console, such fear is almost non-existent; since you can require and see if it fails, call a method and see what it returns.

Consoles are tools of bravery !

Answer 30

I consider myself a mid-level programmer, mostly self-taught, almost exclusively working on my own. I've started to use libraries, but fairly recently.

A major barrier to this was a lack of understanding of different design patterns - or even of the concept. I would determine an approach to solving the problem my own way, starting coding along the way. If I did look at a library, I would often think "Hey, that looks handy, but it won't fit my design."

It took a fair bit of reading and experience trying to apply new ideas to realize two things:

1. My designs were poor and did not keep things properly separated.
2. If I consider existing libraries early, the remaining bits often fall into place easier!

Answer 31

Using libraries is probably one of the worst things a learning programmer can do. Instead of learning how to code, they're learning how to use specific APIs that other people implemented. I'm not saying that every programmer has to understand every single thing that they use, but programmers who know the ins and outs of a computer (digital logic, assembling op-codes, etc) usually have an edge over people who've started with something like Java Swing and are just throwing together libraries.

In production, this is a different matter of course. But I think the best course of education is to 'make everything' once, at least. Writing my own PHP framework from the ground up really improved my programming skills and abstract abilities. Doesn't mean I'll use that framework if someone hires me to build them an application, but I know the strengths, weaknesses, and reasons behind the things that the 'giant' frameworks use, and it can help me choose a particular framework for a particular situation.

Answer 32

Maybe I'm still a beginner, I sometimes still avoid using certain libraries. Some libraries introduces too many abstractions, forcing you to put in more effort to get around it or forcing you to do things in a certain way and I think that's bad. When I'm doing Javascript I'm used to not relying on any libraries. I do, however, copy and paste bits and pieces of code from them and construct my own "mini" commonly-used functions. One of my argument is because some libraries introduces too much "bulk" making web pages load slower. However when doing C/C++ I tend to not afraid of using libraries. But still, when having a choice between a leaner, smaller library to a huge complex library that does almost the same thing, I would choose the former.

Answer 33

I'm not entirely a newbie programmer, but a lot of times I like to implement something myself first, so I understand at least one way of how it works. Then when I have to use it for client work I would go ahead and use a library's implementation of whatever needs to be done.

Answer 34

I'm probably close enough to a new programmer to be able to comment, and personally at least, I have to say I don't like using libraries because I'd rather get the experience doing it myself for now. I'm not doing anything to a schedule, so the time's not a problem. I'll use libraries when I know I understand an area completely, and can't get anything out of using someone else's code.

Answer 35

Well, as perhaps the most 'newbie' person to respond, I can answer what my hesitation is...I'm trying to learn the very basics of programming, and so I feel like even though I "can" use a library, I feel like I need to still have a better understanding before I can even dive into those.

I'm not sure if that makes sense, but imagine that a library is...well...like a physical library. It is full of information and anything I can want to learn is easy to find...right?

But if you don't yet know how to read-or more accurately-comprehend the sentences you are reading, then a library is useless.

I'm still learning how to read. :-D

Answer 36

Answer from a noob - "I am not sure how to use the libraries or even how to access them or how it works"

Answer 37

Some newbies feel that if they use libraries they'd be missing on some kind of fun. They have this IWIIOMO (I-want-to-implement-it-on-my-own) syndrome.

Answer 38

I'd say they find them sort of intimidating. And if they're new to a language diving into more libraries may seem like bitting off more than they can chew. Not to mention more steps involved in getting the environment to work with the library. D:

And from my education experience, (assuming most of these newbies are students) they really don't get much exposure to them.

I sure didn't (while in the classroom). :/

Answer 39

A few potential reasons (as a newbie):

• You're not sure exactly what the library is doing. It may be unsuitable for the platform or have unintended consequences and researching this to the required rigour may be seen as a waste of time. Doubly so if the documentation is poor, which open source often is.

• If code you wrote is bugged, you stand a good chance of making a quick fix when it's noticed. If a library is bugged, you can either i) work around the bug ii) complain to the library's owner or iii) remove it and write your own implementation. Since including the library reference in the first place was your decision, you're responsible for the fix. A slow fix for the above reasons makes you look like a poor programmer.

• You may have to justify your decision to use a library you know, but your mentor doesn't. With a suspicious type looking over your shoulder it often isn't worth the effort.

• The code you might potentially include the library in isn't portable enough to make use of libraries as an efficient means of getting things done. A pro may write neat, elegant, portable code which can happily accept the results of library calls. A novice may not. Shoehorning the library into a naive architecture built by a novice may be more trouble than it's worth.