4 ms·

> At this stage I’m just distrustful of anything he’s said or written, including these arbitrary design principles. Absolutely agree with this. I was a huge f

> At this stage I’m just distrustful of anything he’s said or written, including these arbitrary design principles. Absolutely agree with this. I was a huge fan of clean code, when I first read his books I was fascinated that this man knows what he is talking about, and this is The way how to write code. Then as my knowledge grew, watched a lot of talks, read more books on the topic and learned new languages that gave me different perspectives, I noticed he borrowed a lot of advices form other experts and put it in a way that was a misinterpretation of the idea of the original author. And through his books he distributed this "knowledge" to a lot of people who became dogmatic to his "teachings". I saw many interviews when the candidate was rejected because of the wrong interpretation of some clean code principles by the hiring manager/lead developer, and the candidate got it right.

rented_mule 3y ago
> And through his books he distributed this "knowledge" to a lot of people who became dogmatic to his "teachings". A dogmatic following of even the best of ideas often leads to problems (e.g., your interview example). Software engineering is a thinking craft. It's critical to be constantly thinking about the tradeoffs involved in the systems we're building so we can find a better set of tradeoffs. The same goes for the tradeoffs offered by our tools, techniques, approaches, etc. in any given situation. Even the best techniques are the wrong choice in some situations. I think books, articles, advice from experienced engineers, etc. are best used to set up a set of questions in your head along with default answers. As you gain experience and as our craft evolves, you should be throwing out some of the default answers (or even some of the questions) and replacing them with ones you see elsewhere or ones that your experience has taught you. But they continue to be default answers, not the right answers for every situation.

rented_mule 3y ago

> And through his books he distributed this "knowledge" to a lot of people who became dogmatic to his "teachings". A dogmatic following of even the best of ideas often leads to problems (e.g., your interview example). Software engineering is a thinking craft. It's critical to be constantly thinking about the tradeoffs involved in the systems we're building so we can find a better set of tradeoffs. The same goes for the tradeoffs offered by our tools, techniques, approaches, etc. in any given situation. Even the best techniques are the wrong choice in some situations. I think books, articles, advice from experienced engineers, etc. are best used to set up a set of questions in your head along with default answers. As you gain experience and as our craft evolves, you should be throwing out some of the default answers (or even some of the questions) and replacing them with ones you see elsewhere or ones that your experience has taught you. But they continue to be default answers, not the right answers for every situation.