What I learned from reading The Clean Coder

I'd like to know how everyone else came to grips with his arguments against the Zone (flow). I find that state to be an important part of the quality of my life, as well as the only way I can stay employable—without it, I trudge through coding painfully slowly and procrastinate like crazy.

As an alternative view, I suggest <a href="http://www.paulgraham.com/opensource.html" rel="nofollow">http://www.paulgraham.com/opensource.html</a>: <i>Inconceivable as it would have seemed in, say, 1970, I think professionalism was largely a fashion, driven by conditions that happened to exist in the twentieth century.</i><p>Rather than read Robert C. Martin (also known as "Uncle Bob"), read <i>Coders at Work</i> <a href="http://www.codersatwork.com/" rel="nofollow">http://www.codersatwork.com/</a>. These are programmers who have built interesting things.

It would seems that all good and bad advice sound blindly obvious and one would easily come up with reasoning that sound goods.<p>It is obvious that some advice are plain wrong and some advice are good but they all have the mark of authority and confidence. How do we distinguish them?

I find it interesting that many of these points are actively discussed on <i>The Passionate Programmer</i>[1]<p>[1] <a href="http://pragprog.com/book/cfcar2/the-passionate-programmer" rel="nofollow">http://pragprog.com/book/cfcar2/the-passionate-programmer</a>

I like #1. domain knowledge.<p>how many bad programmers i've seen sit down to vomit up code without having no idea which problem they were trying to solve.<p>but that happens on any area.

This book change my view and thoughts on professional software developers too. One of the most inspiring I have ever read.