What to love about coding?

A few years ago, when I started studying Systems Engeneering I knew I was doing it because I liked coding. I tought I loved making programs, but the thing is, I loved coding, just for the pleasure of it. Now, five years later, and about to graduate I can say I still do, I still like to code.

Due to this attitude towards coding I chose software development as an area to develop my undergraduate's thesis on. The thing is that now, when the thesis is on it's final stage I don't really think that the area where you can enjoy coding the most is software development.

The software industry has been trying to turn the software development into a repeatable process. In order to do so it has been filled with guidelines, diagrams and documentation. Even as this happens, I have not seen the first piece of software that can be thorougly understood in it's current state without looking at the code or, at least, at traces from the code. (Javadoc documentation is a good example of what I refer to as "traces" from the code, in opposition to, let's say, a Class diagram).

I don't know if it is a problem on the tool or on the engineer, but I still think that the process of producing detailed diagrams and documentation for a piece of software takes a lot more time and effort than it is worth. It is true that a great understanding of the problem at hand, but if the same time that was spent on the diagrams is spent on looking at the code the understanding can be much deeper.

I am not saying that we have to stop documenting, much on the contrary, documentation is an absolute must of a software development process, but the documentation must be produced in a way that it is not a burden to maintain, because if it is, then it will eventually not be maintained due to time constraints. Because you can always say "the code is working, so don't worry, docs will be there next week". This is the problem that arises when documents are conceived in a development cycle different from that of code.

In a word, I'd rather spend an hour looking at a well built piece of code, that can almost document itself than look through a myriad of diagrams that cannot be assured to be consistent with the working version of the software.

I don't mean to abolish diagrams or artifacts like that completely, I'm just saying they are tools used to approach a problem. You draw a diagram on a napkin, it helps you understand a key part of a problem, you throw it away. It might be important to maintain component diagrams or physical diagrams, but not much more, if the code is well written, that is.

Take the example from Linux's kernel. It has no diagrams and it hardly contains any comments, but a lot of people have worked on it and it fullfills it's job perfectly