There are three main reasons that I could sum up in three parts: instant-result, never-ending knowledge and creativity (and challenge).

Instant-result

Before I start to play with computer, a large part of my childhood was dedicated to imagining and building things (mainly with wood and screws). Some years later (around 10) I started to learn electronics and build my first integrated circuit. I don’t think that I really knew what I was doing at that time but it did work. I was always dismantling things and reassembling them in order to know how everything worked.

One day as I was assembling another integrated circuit (that I hadn’t designed ) everything fell apart, it didn't work. I knew that I wouldn't be able to find and fix the issue because it required more knowledge in mathematics and physics that the schoolboy I was had (and without doubt even now). Unlike dealing with wood and screws, in electronics, everything seemed complex. The learning curve was too high for me. From this day I decided to stop electronics and began to use a computer. That failure was the turning point.

Everything was instant, it took me less than a week to learn and setup my first website. I loved how web programming works, I just had to write or edit something, hit reload and immediately see the result of what I was doing. It recalls me why I enjoyed working with wood. Each modification on the structure had an aim and the feedback, good or bad, was instant !

But, unlike with wood, with computers I wasn't limited by the raw material quantity. This issue doesn't even exist in computing (or at least not as much) where the virtual world can have (theoretically) an infinite size. The only limitation to building something inside this world  is the knowledge and imagination of the developer. As a developer, I like building things that didn't exist before (or, if so, without all the features that I wanted), as well as finding how existing programs work. And when I'm not able to access to their source code. I try to imagine how it's done behind the scene (I like to see this activity as doing reverse-engineering). There are so many areas in computer science that I wish I would have known earlier in order to use them at the right time, in the right project, instead of doing things inefficiently.

The never-ending knowledge

Which leads us to the second part: the never-ending knowledge. The more I learn about computer science, the more I think the schoolboy I was a fool to believe he knew how to make a website. Even a little computing area like website creation or a more wider area like web-service consumption can become increasingly complex. On a daily basis, I browse the web and social networks to find relevant pieces of information related to my favorite domains. It allows me to discover each day new way of thinking (for example by using the power of partial and high order functions in functional programming languages), structuring projects development (with test/behaviour driven development (TDD) or even documentation driven development) or opening myself to new areas like machine learning and more recently distributed asynchronous computation.

Each time I learn something new, or when I discover a new library or framework or work-flow for building a specific type of program, if it's interesting enough I'll always try it by myself, and if it works, add it to my toolbox in order to be more precise and efficient in future work.

Every single day I do discover, learn, code, share or release something that I didn't know (or didn't know how to do) before. And this intellectual curiosity is in both way directly connected with the last part: creativity.

Creativity (and challenge)

Creativity is what cultivates this passion about computer science. I've never accepted a single project in which each of its components was already available somewhere (in the form of a library, a framework, or a tool). Don't get me wrong, I like to use them and often to study them (it's always fascinating to see how developers solve specific problem domains) but if the project is only about making these components fit together then the creativity required in the process will be too limited and even worst, there won’t be any challenge. In my point of view challenge comes in pair together with creativity.

For example, for the first assignment in Information Retrieval, I added unconsciously multiple challenges to the original requirements. I would have to do it in JavaScript (which may not seems the best language for this kind of exercise) in less than 2 hours, using an hand-made lexer (the goal here was to learn at the same time how to do a lexer because that was something I wanted to learn how to do since the first time I heard about it) and the program would have to be faster than it's Java equivalent. Each of these additional requirements brought us the last point: excitation.

In fact, while coding I added another requirement which was to do it with the minimum of lines of code. After 2 hours it worked. At that time, the feeling of accomplishment is what makes me want to learn more everyday. The lexer was parsing the Cranfield collection of 1400 documents in less than 500ms (8 times faster than the hand-made Java parser) and after a rewrite from scratch this number went down to 42ms. The final version with only 136 lines of code takes 4 secs to process and index all documents.

But what's important here isn't the result, it's the way I take to go to this result. It was all about using the functional tool and using the language weirdness to reduce the number of lines and improve the program's efficiency. This project was not about the architecture and the design of the code but about specific problem areas which may not be usually related: IR, language performance and code size. It was more an experiment than an assignment. In fact since the beginning I knew that it won't be the final program that I'll have to return. Simply because it doesn't respond to the initial requirements. But it allowed me to discover the Vector Space Model, TF-IDF and how to make a Lexer from another angle before re-writing it in the traditional way in another language.