Reading a book cover to cover isn't going to buy you a damn thing in terms of knowledge unless you put what you read into actual, working software.
You could read an entire book about, say, algorithms, and be positive that you understood and can remember most of it. By the time you will need to actually sort a directed acyclic graph, though, chance are you won't have a clue about how to do it.
So yes, read as many books as you want, but implement what you read. Try things out, play with concepts that strike you as interesting. Granted, that doesn't mean you will remember everything, but you will be better at recognising patterns that get thrown at you in the guise of new problems. Which, if you ask me, is far more important than remembering exactly how to implement that particular sort.
You write that you feel like a small potato, and I can completely understand that. We all are, to some degree. We've been programming for only a few decades, and already there's so much stuff to learn that one can and will feel overwhelmed.
Look at it this way: there's a huge amount of interesting things to learn about in our field, and we live in an amazing era, where a good part of this knowledge is only a few clicks away. It's all yours for the taking.
But diving into a random subject you won't touch ever again in day-to-day programming is only useful as an exercise in acquiring knowledge, and arguably it won't make you a much better programmer.
As with most aspects of life, getting out of your comfort zone and seeing what you can do is a key thing. So, try to do it with programming. Try to write a program that needs to do something you never did, and then try to figure out how to do it. If you feel like you don't know what to look for with Google, just ask here on programmers; there's nothing wrong with it.
Let me draw on the directed acyclic graph example from before.
Say your software needs to figure out the exact sequence in which it has to execute some tasks, where each task has a "depends on" kind of relationship to other tasks (which is much what tools like make, ant or rake are all about).
If you are a "just give me that keyboard, I don't need to do no stinkin' up front design" kind of guy, odds are you will iterate through the tasks, possibly more than once and, with a series of ifs, brute-force your way to the solution.
Most probably, though, when you're halfway through, it will occur to you that what you're coding is really a suboptimal solution, and you're producing a large, smoking, stinking ball of unmaintainable code.
So you begin looking for an elegant solution; after all, somebody must have dealt with this before, no? That's where the "ask around" part comes in, especially because, if you don't know that a set of related tasks can really be thought of as a DAG in disguise, it won't be easy to realize that what you need is a topological sorting.
Does not knowing what a DAG is mean you're not a good programmer? I don't think so.
Does putting in the will to ask around for pointers and then trying to figure it all out on your own mean you're a good programmer? I definitely think it does.
Frankly, I don't think that a good programmer is the one that can do everything by knowing a lot of topics by heart (nothing bad with that, by the way). I would rather hire someone that knows where and how to look for when some exotic problem comes her way.
Good luck.
