A week ago I started reading Uncle Bob's book "Clean Code". Although I'm still not yet half way through the book, I want to recommend this book to anyone who has not read it yet. One of the many things that impressed me during the reading was this:
In in the book, Robert Martin makes several times the point that the bad code, such as one with long functions, many indentation levels, cryptic names and complicated conditional expressions inside those functions is simply hard to read. This may be an astonishing this to hear from a professional, at a first glance. Indeed, through our education and early professional work we become used to the notion that "real professional" is able to decypher really complicated code without a hitch. We are also often impressed by our colleagues who through years of dedicated work have become fluent in understanding of extremely bad written and uncomprehensible modules.
Martin tells us that this is not the right way to look at things. Although it is not said strictly in the book, it almost reads like: hey, look, even I, with all my years of experience and proficiency in computer languages, am not feeling comfortable when I look at a bad-written module and it takes me a lot of time to even vaguely decypher what it does and how it does it.
We should not base our professional value system on how comlicated and badly-written code one is able to comprehend.