What I learned from reading The Clean Coder(blog.christoffer.me)
blog.christoffer.me
What I learned from reading The Clean Coder
http://blog.christoffer.me/2011/11/9-things-i-learned-from-reading-clean.html
7 comments
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.
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.
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.
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).
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."
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.
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.
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?
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?
> 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.
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.
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...
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?
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...
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?
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?
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?
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.
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.
"Why not read both?": I am thinking that reading Robert C. Martin is not likely to make you smarter.
Reading Coders at Work does not make me smarter either (and I've read it).
Don't get me wrong, it is an interesting book but let's not forget that it is a personal interview type of book. These people are telling stories about their life + computers. Not necessary to focus on educating other people.
If you look at the list of the people for CaW, most of them are either in Research or no longer actively writing code in recent environment. They might write code fragments or design stuffs (more like Architect role).
But I do like to pick some of the opinions regarding unit-test that all of these so-called great developers believe and shove them to other developers :).
Don't get me wrong, it is an interesting book but let's not forget that it is a personal interview type of book. These people are telling stories about their life + computers. Not necessary to focus on educating other people.
If you look at the list of the people for CaW, most of them are either in Research or no longer actively writing code in recent environment. They might write code fragments or design stuffs (more like Architect role).
But I do like to pick some of the opinions regarding unit-test that all of these so-called great developers believe and shove them to other developers :).
[deleted]
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?
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 The Passionate Programmer[1]
[1] http://pragprog.com/book/cfcar2/the-passionate-programmer
[1] http://pragprog.com/book/cfcar2/the-passionate-programmer
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.
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.
That's why we have plenty todo list, project management tools, and issue/bugtracking software :)
This book change my view and thoughts on professional software developers too. One of the most inspiring I have ever read.