I finally started reading one of the biggest modern classics of software development and software craftmanship, Robert C. Martin's Clean Code. I've read only about one third of it but have started to form some kind of opinion about it already. And my main feeling is that I'm slightly underwhelmed by it so far.

Now, this first impression is unfair and I know it. I've mostly felt like I know the stuff in the book already which is why I haven't gotten many "wow" moments reading it. But I realize that's mostly because the book is already 15 years old, and has had a huge impact on the whole software development trade since it was first published. So, even though it took me this long to actually start reading it, it has influenced a lot of people I've talked to and thus had a big effect on many of the conversations about software development I've had. It would actually be quite surprising if it managed to surprise me with some fundamental new knowledge that hasn't come up in talks with colleagues and friends yet.

One thing that slightly disturbs me reading it is how heavily it seems to concentrate on object-oriented programming and Java. I know Java and OOP so it doesn't make it in any way hard to understand, but some of the expressed opinions almost seem wrong nowadays as I've become more accustomed to functional programming. E.g. I nodded in agreement as I read about functions and how they shouldn't have side effects, but then felt it was most almost at odds with the expressed idea that optimally functions or methods should have no parameters at all; I believe it was suggested that methods should use an object's internal state as much as possible instead of taking parameters in. As nowadays I'm quite an advocate for pure functions, this preference for using state for logic makes me slightly uncomfortable. But as stated, the book is quite clearly written from an OOP viewpoint and using objects' internal state is totally fine there, so this is more about me adjusting my expectations or preferences to the right context.

There has also been one of those very positive moments when I believe I've started thinking about something in a somewhat new light.

The book says a developer should try and tell a story with their code. For decades already I've considered readability to be the most important aspect of quality code, and sometimes I may have thought about it being read almost as prose. (Hey, I've even tried writing a piece of code in Shakespeare, so I believe I have a pretty strong case here!) But I think actually stopping to look at one's code and asking oneself whether it tells a story or not sounds like something I should do more often.

It's an interesting approach to sharing information in general. When I think about all the books and blog posts I've read, I think I've enjoyed most the ones that read like a story and not like an academic article. Don't get me wrong; there's definitely a need for academic articles also and they may need to be as exact and precise as possible to convey a particular finding efficiently and with no room for misinterpretation. But for many other things, a more story-like approach may be more pleasant to read and simpler to understand, and even be easier to remember later.

I've even considered several times starting to write these blog posts in a story-like format to make these nicer to read. I don't know if it would work for the topics I write about, but I just might try it out some day — as an experiment if nothing else.