Notes to self

I read Java Concurrency in Practice (Brian Goetz) and it taught me something important. It showed me a whole new "dimension" (I can't explain it any further than that - words fail me) of reasoning about code. This was not the intent of the book, but rather a side-effect of the examples in it and its approach and focus on correctness.

I now write all my code with this same focus and attention to correctness, and I always reason about my code through this new dimension that I have discovered, and I am always concious about the thread-safety of my code.

Then I read Release It! (Michael T. Nygaard) and it showed me that my newfound attention to correctness could, and should, be extrapolated to a much higher inter-system scale. The appraoch is now less about fundamental reasoning, and instead more about making concious design decisions.

The situations where I need to apply this knowledge are fewer and farther between, but their effects are equally profound and, I dare say, even more noticable and visible to the people who surround the systems I work on, and my fellow programmers.

Then I read Java Management Extensions (J. Steven Perry) and it sucked. Moving on.

Then I read Facts and Fallacies of Software Engineering (Robert L. Glass) and while my code is unaffected, I still learned something important. Actually, I learned many things from this book. But the book itself is like a window through which, if you care to look, sense something called experience.

Here's a guy who at the time of writing (2002) had been a software practitioner for 45 years. He has seen things, tried things, evaluated things, researched things and written a ton of code. He does not use the word "fact" because he is pompous. When he says "fact," he implies anectdotal evidence and research papers (that he has actually read and understood).

Where was I going with this? Oh, yes. The facts and fallacies are worth remembering. And that's about it. This stuff is good to know, because, it just is. Okay?

Now I'm reading Clean Code (Robert C. Martin) and I have only just made it past the introduction, but already sense something. I get this weird feeling. You'd think that any reasonably experienced programmer knows what clean code is, knows it when he sees it, knows how to write it and knows how to change bad code into clean code.

Do you know what clean code is? Can you tell me? If you think "yes" to these questions, then try to imagine yourself in the classical elevator-pitch situation and tell me, right to my face, what clean code is. Do you still know what clean code is? Can you even point to an example that you are certain is clean code?

I have just made it through the introduction and just realized that I can't do any of those things. And what's more: clean code is more important than I thought before I started on this book.

I can see my horizon expanding but I have no idea how far it will go - that's the feeling I have about that book, right now.

I wonder what I'll read next

This means that the book site actually has some content now.. or, supposedly at least - I haven't seen it myself because the server is completely floored with load, but when it gets back on its feet, you can check it out here: http://book.realworldhaskell.org/.