I'm surprised by the huge amount of detractors of the book, which to me was very useful (when I read it almost 10 years ago). I was planing to go back to it, but considering recent discussion, I want to know HN's alternative suggestions.<p>What is your modern
<i>The Pragmatic Programmer</i>, <i>Refactoring</i> (I'm rereading it after many years with the 2018 edition, opinion not totally formed on this one), <i>Working Effectively With Legacy Code</i>, <i>A Philosophy of Software Design</i>. It's been a long time since I've read <i>Clean Code</i>, I don't quite get the hate from the other thread here today so I'm rereading it now. I figure it'll take me a couple days and worst case I'll agree with the criticism and stop recommending it.
Code Complete, specifically chapters 7, 11, 15, and 22-24. I always found the examples to be clearer and more thoughtful than Clean Code. But with Code Complete, there are several chapters which feel dated around stuff like version control.
#1. Software engineering is a very complex skill that you can’t just put in a book.<p>Confusion comes from CS which is based on math which is based on determined set of rules and axioms.<p>But modern software engineering is more art, CS is just one of many tools at your disposal.<p>So many developers and book authors still don’t get it.<p>There are no laws or rules that just works — u always have to think for yourself.<p>=> any book teaching you specific principles or practices would be incomplete and incorrect in some big set of cases.<p>#2. CC is a great book, as any book written by experienced engineers.<p>You just have to remember #1 and learn to understand motivation and applicability of each idea in a book.
I'm reading Clean Code at the moment.
I don't agree with everything.
I think it would be a mistake to take it on it's every recommendation.
I can suggest something that was recommended on HN maybe five years ago: Code Simplicity by Kanat-Alexander.<p>It's relatively short and doesn't commit the sin of providing code snippets. It only lays down general rules about software development and give generic heuristic for better software design. Nothing specific to code. It has no prescriptive rules on the way you write code, but rather, on which code to write. This makes the recommendations timeless despite the fact the book is fairly old. As someone who was just starting in development at the time, it was a HUGE help and provided insights that I can only agree with now that I'm working in the field. Maybe for someone who has a bit of experience already, it might just elicit shrugs, but I think it's a good introduction on how to think about software design.