What I learned from reading The Clean Coder

http://blog.christoffer.me/2011/11/9-things-i-learned-from-reading-clean.html

by jemeshsu • 15 years ago

43 17 15 years ago

blog.christoffer.me

kiba• 15 years ago

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?

gcb• 15 years ago

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_moto5• 15 years ago

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

DanielRibeiro• 15 years ago

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

SammyRulez• 15 years ago

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

wglb2• 15 years ago

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_moto5• 15 years ago

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?

Silhouette2• 15 years ago

> 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.

wglb2• 15 years ago

"Why not read both?": I am thinking that reading Robert C. Martin is not likely to make you smarter.

prodigal_erik• 15 years ago

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• 15 years ago

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• 15 years ago

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."

SomeCallMeTim• 15 years ago

Yeah, I tend to agree with you. I can code when not in The Zone, but there's NOTHING like the productivity you get when you're cranking out code.

He claims you'll be revisiting that code. So what? Maybe HIS code, written in The Zone, comes out as crap, but mine is as solid as my "normal" code. It's certainly better than my "stay up all night until the bug is fixed" code; THAT is something that I've stopped doing, thankfully, because when that happens I typically have to clean up a mess no matter how much of a slog the code was to write.

In fact, his comment that you'll come back to code written in The Zone more often is tautological if you end up writing most of your code that way, since bugs typically correlate to lines of code. You could have half as many bugs per line in your Zone code as the rest, and if 80% of your code is written in the Zone, it will still seem like you spend most of your time debugging it.

To be fair, I've also managed a Zen coding state that's not quite Zone, but not as painful as the state you describe. Code gets written at a relatively calm pace, and I keep going until I either fall out of the state or achieve The Zone. The advantage is that I can transition in and out of the Zen state more quickly, so I can manage interruptions.

What I learned from reading The Clean Coder

Related Stories