Despite that the two books Clean Code and Clean Coder are good books.
A long while ago Blaine reviewed Clean Architecture by Uncle Bob here on DEV. It apparently was not up to the same standard. In fact, not even good. That, and the twitter mess highlighted in the article you linked, and the crap articles on his website, is reason for me to have written off Uncle Bob.
I've even heard that Clean Code and Clean Coder have a dangerous mix of good and bad ideas, so they're only "good reads" if you already know enough about coding to sort the wheat from the chaff. I prefer to learn clean coding from anyone but Martin.
It has been a while since I read it. But I do not recall any dangerous ideas. There are a bunch of things in it I do not agree with. But that's common with most books. That's why you should read multiple books by various people on the same subjects so that you can form your mind on different perspectives. There is no single truth.
Clean Code does contain a disclaimer, although in a rather long form. Here's the most important bit of it.
Consider this book a description of the Object Mentor School of Clean Code. The techniques and teachings within are the way that we practice our art. We are willing to claim that if you follow these teachings, you will enjoy the benefits that we have enjoyed, and you will learn to write code that is clean and professional. But don’t make the mistake of thinking that we are somehow “right” in any absolute sense. There are other schools and other masters that have just as much claim to professionalism as we. It would behoove you to learn from them as well.
Indeed, many of the recommendations in this book are controversial. You will probably not agree with all of them. You might violently disagree with some of them. That’s fine. We can’t claim final authority. On the other hand, the recommendations in this book are things that we have thought long and hard about. We have learned them through decades of experience and repeated trial and error. So whether you agree or disagree, it would be a shame if you did not see, and respect, our point of view.
Note, I didn't say there were "dangerous ideas", rather that the mix of good and bad ideas was dangerous. Slight difference in word order, major difference in meaning.
What I'm saying is, you can really only weigh the ideas in Martin's work if you're already well versed in software development. When you're at the "absorb knowledge like a sponge" stage, such a mixed bag is dangerous, because you don't yet have the ability to separate the wheat from the chaff. No book can ever be taken entirely at face value, but Martin's work is particularly inconsistent in its reliability, in part due to his inability to separate his opinion from objective fact.
Dreaming in Code isn't really about the act of programming though. It's a chronicling of how a project, and business, failed.
But I do recommend it too. It's a really good and interesting read. And for the younger people it's also a nice dip in the history of software development in late 90s/early 2000.
Ah, but it is about programming, specifically how unpredictable programming is. It's helped me time and again with checking my assumptions and cognitive biases as a software developer.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I always like to add "Dreaming in Code" by Scott Rosenberg.
In any case, I just added several more books to my list of things to read! Thanks for compiling this list.
(Side note: Not sure I'd take John Sonmez's or Robert Martin's word for anything, especially after some of the recent fallout.)
In this case we should also mention The Phoenix Project ;)
Sorry, I must not have been in the loop somehow. What is this about?
Here's the best summary. (Read Ben's comment there; the bulk of information is there.)
Can we separate the artist from their art? Should we?
Andrew (he/him) ・ Oct 22 '19 ・ 1 min read
There's also this, which gives the entire timeline:
medium.com/@cherp/propaganda-other...
Despite that the two books Clean Code and Clean Coder are good books.
A long while ago Blaine reviewed Clean Architecture by Uncle Bob here on DEV. It apparently was not up to the same standard. In fact, not even good. That, and the twitter mess highlighted in the article you linked, and the crap articles on his website, is reason for me to have written off Uncle Bob.
I've even heard that Clean Code and Clean Coder have a dangerous mix of good and bad ideas, so they're only "good reads" if you already know enough about coding to sort the wheat from the chaff. I prefer to learn clean coding from anyone but Martin.
It has been a while since I read it. But I do not recall any dangerous ideas. There are a bunch of things in it I do not agree with. But that's common with most books. That's why you should read multiple books by various people on the same subjects so that you can form your mind on different perspectives. There is no single truth.
Clean Code does contain a disclaimer, although in a rather long form. Here's the most important bit of it.
Note, I didn't say there were "dangerous ideas", rather that the mix of good and bad ideas was dangerous. Slight difference in word order, major difference in meaning.
What I'm saying is, you can really only weigh the ideas in Martin's work if you're already well versed in software development. When you're at the "absorb knowledge like a sponge" stage, such a mixed bag is dangerous, because you don't yet have the ability to separate the wheat from the chaff. No book can ever be taken entirely at face value, but Martin's work is particularly inconsistent in its reliability, in part due to his inability to separate his opinion from objective fact.
D'oh, guess I wasn't fully awake yet ;)
I hear ya.
Slides a cup of hot coffee and a plate of donuts to Michiel.
Dreaming in Code isn't really about the act of programming though. It's a chronicling of how a project, and business, failed.
But I do recommend it too. It's a really good and interesting read. And for the younger people it's also a nice dip in the history of software development in late 90s/early 2000.
Ah, but it is about programming, specifically how unpredictable programming is. It's helped me time and again with checking my assumptions and cognitive biases as a software developer.