
What I learned from reading The Clean Coder - jemeshsu
http://blog.christoffer.me/2011/11/9-things-i-learned-from-reading-clean.html
======
prodigal_erik
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.

~~~
lemming
That's interesting - can you summarise his objections here briefly? I haven't
read this book (yet) but I find it hard to see how anyone could make a
coherent argument _against_ flow for programmers. In fact, there's all sorts
of literature showing that concentration is incredibly important (c.f.
Peopleware).

~~~
KevinEldon
From page 62: "[The Zone] is the highly focused, tunnel-vision state of
consciousness that programmers can get into while they write code. In this
state they feel productive. In this stat they feel infallible... Let me be
clear about this. You will write more code in the Zone. If you are practicing
TDD, you will go around the red/green/refactor loop more quickly. And you will
feel a mild euphoria or a sense of conquest. The problem is that you lose some
of the big picture while you are in the Zone, so you will likely make
decisions that you will later have to go back and reverse. Code written in the
Zone may come out faster, but you'll be going back to visit it more."

------
wglb
As an alternative view, I suggest <http://www.paulgraham.com/opensource.html>:
_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._

Rather than read Robert C. Martin (also known as "Uncle Bob"), read _Coders at
Work_ <http://www.codersatwork.com/>. These are programmers who have built
interesting things.

~~~
hello_moto
Why not read both?

What is this "read these programmers who have build interesting things"
street-cred has anything to do with Robert C. Martin?

Are you saying we should not listen to instructors and don't bother reading
books that are being written by someone who haven't "produced" anything in its
respective industry?

~~~
Silhouette
> Are you saying we should not listen to instructors and don't bother reading
> books that are being written by someone who haven't "produced" anything in
> its respective industry?

That might be going too far, but if someone presumes to teach others a
subject, should they not have _something_ that supports their authority and
gives their advice some credibility? A track record of doing the job
successfully themselves makes pretty solid case in that regard. Another
respectable possibility would be having studied the work of others, if the
teacher is presenting arguments based on careful observations of that work.

However, most of the Agile consultancy crowd have precious little personal
track record and precious little empirical data to back up the things they
recommend either. Instead, they tend to rely on selective evidence,
unwarranted extrapolation, over-generalisation and crude insults as their
debating tools of choice.

Unsurprisingly, there is also data available that contradicts some of the
consultants' favourite arguments. Typically, they ignore such data in their
own presentations. If challenged with it, they usually try to hand-wave it
away by reinterpreting something they have previously said or conveniently
redefining their terms.

The trouble is, given the high profile that these consultants maintain, a lot
of impressionable new starters in our industry read their writing and do take
it as gospel. Then they start working with other people, and their managers
and mentors and colleagues have to waste a silly amount of time undoing the
damage.

I've been that undoing-the-damage guy on way too many occasions. I have
absolutely no doubt that people like Robert C. Martin are harmful to our
industry. I wish he would keep the preaching in church and leave software
development to people who understand that professionalism does not require
blind faith in whatever he happens to believe himself.

I realise that I have myself indulged in a bit of character assassination
without evidence here. This is already a rather long post, and I don't want to
double it with all the examples I'm thinking of as I write it. However, if
anyone is interested and not familiar with the typical criticisms I've alluded
to, feel free to reply and I'll try to back up any specific claims I've made.

~~~
hello_moto
Or perhaps you should read the message instead of looking (and shooting) at
the messenger.

By the way, I do not own his books at all. None.

So... Uncle Bob does not have anything that supports his skill and authority?
Just because he worked with clients building internal apps or back-end b2b
apps does not mean he has not done anything.

If you want to use his software or check his code maybe you should try
FitNesse (<http://en.wikipedia.org/wiki/FitNesse>).

I'm not his biggest fanboy nor I care even a slight bit when it comes to TDD,
BDD, Agile or whatever. But this guy has written books since '95 and he's
doing a darn good job and the customers are happy (check his ratings).

[http://www.amazon.com/Robert-C.-Martin/e/B000APG87E/ref=sr_n...](http://www.amazon.com/Robert-C.-Martin/e/B000APG87E/ref=sr_ntt_srch_lnk_4?qid=1322365740&sr=8-4)

While other "consultants" preach Agile processes, Uncle Bob focuses on writing
code. Code darn it. Not processes or steps or standup meetings or burn-down
chart. C.O.D.E.

While others preaching OOP with re-use crap, Uncle Bob made a stand with SOLID
and "Object in real world is not the same with Object as program". Actual
implementation as opposed to re-hash the same old "theoretical" stuff.

Check out his Craftsman articles:
<http://www.objectmentor.com/resources/publishedArticles.html> (click the
Craftsman, I can't give you the URL). All code.

On the other hand, I met tons of developers that write code only for
themselves and not other, developers that have huge ego and did the heroic
crap, developers that write code without even inline documentation, developers
that don't have any professionalism or whatsoever just because they thought
that "Hey, Linus never care any of these craps".

Let's keep in mind that great programmers like Linus is just 0.01% while
others that try to emulate him failed miserably.

So yeah, I chose Uncle Bob over Linus when it comes to educating others since
95% of developers are below average (yes, I'm harsh. I could be one of that
95% as well for all I know). If Uncle Bob can push that number down
significantly. I'll be much happier.

PS: Have you actually look at the article that this HN thread link to? Tell
me, what's wrong with Uncle Bob's latest book? All the suggestions are good.
Uncle Bob pretty much advised developers to become better.

Those 9 points that the blogger pointed are what happening in the real world:
developers are crappy in general and that is due to their own character and
attitude : "I just want to hack some code the way I want it to be, to hell
with the rest".

Guess who's going to clean that sucker's code?

~~~
Silhouette
I'm sorry, but you seem to have read something in my post that was not there
and then attacked a series of straw men.

You asked about listening to teachers without a track record and reading their
books. I gave an argument that some people aren't worth listening to/reading,
including the author in question here.

 _Tell me, what's wrong with Uncle Bob's latest book? All the suggestions are
good._

I only bought his previous book (which is part of the reason I have a very
negative view of Martin's work) but picking on some of the points in the
article here that jumped out immediately:

 _It is important to remember that you don’t own the code, but rather the team
does._

The degree to which collective code ownership by an entire team might be
better than having more specialist roles is still an open question.

 _Over time, teams slowly grows better and better as well, resulting in team
members will eventually know each others strengths and weaknesses._

Another great theory. It usually gets some cute title like "forming, storming,
norming and performing" in the management textbooks.

What the article (and, I am therefore trusting, the book itself) glosses over
is that many teams never reach the performing stage in practice.

 _When coding you should always aim to cause no harm in your project, by
always aiming to get the error rate as close to zero as possible. This is done
by simple writing tests. Tested code gives you more confident about your work,
knowing the fact that what deliver is at top class and checked against
errors._

The list of loopholes in pro-TDD arguments and the number of fallacies
perpetuated by TDD advocates would fill at least a chapter of a book. To say
that whether TDD is beneficial is an open question is putting it mildly.

Moreover, describing someone who doesn't buy the TDD hype as "unprofessional"
is simply a crude _ad hominem_ attack, which by the way targets almost all
professional developers who do in fact work on software with bug rates an
order of magnitude or more better than the industry average.

 _According to Robert C. Martin, if you work 40 hours a week, you should spend
around 20 additional hours enhancing your own profession._

Ah, yes, I remember the management research about this one. It definitely
showed that sustaining a 60-hour work week in a creative field was the best
way to maintain performance, and found no negative consequences that quickly
led to a net performance loss and ultimately to burn-out of the worker.

 _As a professional developer, you should know that being a software developer
is a very intellectual and exhausting job. It is important that you don’t
overwork yourself, but rather find a balance in life with your job._

Hang on a minute... Yep, we really did just talk about spending 60+ hours per
week on work-related activities and then segue into the importance of getting
enough rest.

 _If your superiors refuses to listen to you and does not take no as an
answer, you should think about going one step higher. Even though going over
someones head might feel uncomfortable, in the end it will deliver the best
possible outcome for all involved parties._

If your superiors refuse to listen to you, it is their problem. If they do
listen to you but then choose not to follow your recommendation, it is also
their problem. Either way, you can if necessary ensure that your objections
have been properly recorded, but it's almost certainly not your job as a
software developer to second-guess a management decision and start playing
levels of management off against each other. What happened to keeping a level
head in a crisis and to being a team player?

~~~
hello_moto
I have no problem for a single person owning a specific component of the
codebase assuming he adhere with a set of policy regarding code style, best
practices, etc.

The problem here is that in most companies, other than the big guys (MS,
Google) that have smart developers along with good policies, the single owner
usually take hostage and write bad code that nobody wants to touch. You can
debate this night and day if you will.

Google is famous for having a very strict rule: pass your specific programming
language policy exam then you can write code and commit to Google main
repository using that language. I wish more companies have this type of
policy.

No argument against those forming/storming/norming/performing, non-issue, just
a nice footnote.

Again, TDD useful or not? Here's the thing: many people prefer to write
features and not unit-test. It's psychological.

Features = you're a hero.

Unit-test = grunt work.

Many people would try their best to look for excuses to write less unit-tests.
You'll often hear the "as needed", "as efficient as possible", "the least
amount of work" when it comes to unit-test. But when it comes to features, oh
boy, you'll hear the big words "patterns", "architecture designs", "design
decisions" and all the bullshit.

For the record, I don't care if you do TDD or test-last as long as your
implementation is testable.

Of course the problem here is that most of the time, their code isn't
testable. Lots of hard dependencies against 3rd-party web-services, hard
dependencies with GUI widgets, hard dependencies against the server, unable to
mock the crap out of the DB, etc.

Suddenly you'll hear tons of excuses why we can't write unit-test. "Oh, we
have to refactor and it'll cost X days". Management doesn't want to hear that.

This is why some people made a strong stance of TDD or die. Because most
developers just simply behaving like cats; they do whatever they want. Hence
the phrase "Herding Cats", "Herding Developers".

In a team where the people know and have experienced this kind of pain, they
probably won't do TDD but will do test-last. But since we have no friggin
standards at all, how do you know what team you'll be in unless you've been
with them for a while or have done some sort of 1 day bootcamp?

So the choice here in many places out there is either you'll have unit-test or
no test at all. The in-between places are very very rare.

Sure, I agree that calling non-TDD is unprofessional is harsh. Bad uncle Bob,
bad. But then again, perhaps his target audience is those developers lazy-ass
developers who think they're a rockstar (many developers think that way about
themselves: Dev is king). If you tell lazy-ass developers that "well, test-
last is fine as long as your code testable", they have a different filter in
their ear: "Oh let's just write the implementation first and figure out
testing last". Suddenly you hit the deadline and you'll hear the excuse again
"I have no time to write test, here's my work" (and realize that it is not
testable).

What other choice other than draw a line and call "To not TDD is
unprofessional". Once writing unit-tests become a habit, you can always inform
them the latter (test-last is fine as long as...)

Start with the highest level of discipline and relax them as you go.

Spending extra time to enhance your skill is not something new. Other people
said something along the line of you should contribute to open source software
and whatnot. It's not a bad advise and you shouldn't follow them ad-hoc. You
could spend 10 hours for all I care but if your skill stuck and you can't get
better then we will find someone else better.

The last one is probably not a good suggestion (regarding jumping your
superior).

Sure, you can make an argument that certain "opinions" are not well-suited in
general just like everything else out there. But that doesn't make him a very
very bad guy.

------
kiba
It would seems that all good and bad advice sound blindly obvious and one
would easily come up with reasoning that sound goods.

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?

------
DanielRibeiro
I find it interesting that many of these points are actively discussed on _The
Passionate Programmer_ [1]

[1] <http://pragprog.com/book/cfcar2/the-passionate-programmer>

------
gcb
I like #1. domain knowledge.

how many bad programmers i've seen sit down to vomit up code without having no
idea which problem they were trying to solve.

but that happens on any area.

~~~
hello_moto
That's why we have plenty todo list, project management tools, and
issue/bugtracking software :)

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

