For a variety of reasons, a mix of personal and professional, I am interested in a Lucene based search product. For a variety of reasons, if anything comes out of this, we will likely end up using a product that wraps the Lucene library and hides a great deal of its complexity, such as Solr or Solr's main competitor the name of which I cannot be arsed to go look up, even though I am writing this on an internet connected computer. But fortunately I have the time to try and learn the Lucene library itself before I am forced to learn how to do things the slightly easier way.
The first practical language I learned was PERL. I taught it to myself for work; I bought a couple of books and started writing really, really crappy code. But it was code that I had to put together for myself, writing it in a plain text editor (vi is awesome and I will brook no argument on the matter). I had to figure out all of the basics, from how to start a program to how to load outside libraries, to how to get the interpreter into my PATH and the libraries in my @INC. As I got into more complicated programming, I had to learn abut variable and their memory footprint, about file descriptors and their relationship to sockets and a host of other things that gave me a better understanding of how programs actually work. By comparison, when I have learned to do things with special tools or via IDE wizards, I have learned less about how the thing actually worked and was thus less able to deal with the inevitable failure of metaphors.
Programs are a lie: nothing a program does is real. I am "writing" this, but the words won't stay if the laptop dies. I can "send" a message over an email program, but the words aren't like a letter, stuffed in an envelope and waiting for delivery, no matter how long it takes. The important part of programming doesn't start until those lies are exposed, until the metaphors fail. Then you need someone who understands what the program is actually doing, not what the lies the metaphor tells you. If you learn form the ground up, if you learn the truth before the lie, you are better prepared for when the lie is found out.
This is not meant as diatribe against tools and IDEs: I have impure thoughts about Visual Studio and IntelliJ and tools make us more efficient programmers. But they don't make us better programmers: only understanding how programs actually do what they do, at the lower levels. Learning without efficiency tools like IDEs and wrappers for complicated libraries is one of doing that. Want to be a better programmer? Start with understanding the physics of computers, assembly programming, and a low level language learned in a text editor.