3 ms·

As someone who has read perhaps 75% of the books listed there, the outcome I got is: you need to learn the rules only to be able to discard them. Plenty of the

As someone who has read perhaps 75% of the books listed there, the outcome I got is: you need to learn the rules only to be able to discard them. Plenty of the "principles", "patterns", "laws", "good practices" that abound in these books are not only irrelevant but dangerous in plenty of real-world scenarios. From introducing an hierarchy of abstractions soon in the project, to apply blindly Brook's law, to using Scrum all the time... The real deal is to be able to say: "I know that most of you guys will say 'Let's apply Pattern X to this problem!', and while M. Fowler would also agree, based on similar projects we have done in the past, we definitely should not use Pattern X". There is nothing more dangerous than an engineer that after having read all these books, is incapable of accept that sometimes following M. Fowler is the wrong path to solve that little problem we have at hand.

jjice 4y ago
Absolutely. No book should be taken as word of law for software development. I like to think of books as a collection of ideas to expand my mind and then I can use judgement to choose to apply them as appropriate.
Ma8ee 4y ago
The danger is all the cargo-culting that is rampant among software “engineers”. They know all the patterns and repeat all the acronyms and phrases, while they have very little idea about the whys.
clumsysmurf 4y ago
> There is nothing more dangerous than an engineer that after having read all these books I disagree to some extend. We learn the rules, so we know when to break them. This is called improvisation. I think its worse to break the rules without even knowing why they are there in the first place. I have read many of these books, and don't think its much of a concern because they often don't even agree with each other, and anyone paying the slightest attention to what they are reading will wrestle with the tension. Sometimes they don't strictly disagree, but are different enough you must synthesize an even better idea! For example, in "Philosophy of Software Design", Ousterhout recommends X, and then says Uncle Bob's advice is to do Y instead. When the experts don't agree, that should make you think "hmm, maybe this isn't settled." In "Clean Architecture", Uncle Bob had a separate chapter (34 The Missing Chapter) written by Simon Brown which somewhat conflicts with the rest of the book.
- Hermitian909 4y ago
  > I have read many of these books, and don't think its much of a concern because they often don't even agree with each other, and anyone paying the slightest attention to what they are reading will wrestle with the tension. I'm not sure you're the norm, at the very least a large number of engineers I've interacted with or mentored have come away from these books with either an explicit belief in these hard rules or an implicit one. I've found Uncle Bob's work tends to be particularly bad in getting engineers into this mind set (though maybe I over-indexed because I think so much of his advice is bad).
  - serial_dev 4y ago
    In my experience, Uncle Bob's followers tend to be very dogmatic and somehow they think that only Uncle Bob's books are worth reading, so when you point out that maybe there is another valid perspective on the issue and not only Uncle Bob's, they look at you like you are crazy. If you admit that you think that some of his books are pretty dated, or if you point out the examples he used to justify certain patterns are so contrived to make the other alternative look ridiculously stupid, or if you say that maybe our CRUD mobile app that only fetches data from the backend and displays it 1-1 doesn't need the 20 layers of clean architecture cargo culting, then they get angry and will label you as someone who "doesn't care and know about software architecture". I'm not even sure why Uncle Bob is special in this regard, I have never met a Sandi Metz/Martin Fowler/John Ousterhout fan who could not comprehend that there are other valid points of view on a situation.

jjice 4y ago

Absolutely. No book should be taken as word of law for software development. I like to think of books as a collection of ideas to expand my mind and then I can use judgement to choose to apply them as appropriate.

Ma8ee 4y ago

The danger is all the cargo-culting that is rampant among software “engineers”. They know all the patterns and repeat all the acronyms and phrases, while they have very little idea about the whys.

clumsysmurf 4y ago

> There is nothing more dangerous than an engineer that after having read all these books I disagree to some extend. We learn the rules, so we know when to break them. This is called improvisation. I think its worse to break the rules without even knowing why they are there in the first place. I have read many of these books, and don't think its much of a concern because they often don't even agree with each other, and anyone paying the slightest attention to what they are reading will wrestle with the tension. Sometimes they don't strictly disagree, but are different enough you must synthesize an even better idea! For example, in "Philosophy of Software Design", Ousterhout recommends X, and then says Uncle Bob's advice is to do Y instead. When the experts don't agree, that should make you think "hmm, maybe this isn't settled." In "Clean Architecture", Uncle Bob had a separate chapter (34 The Missing Chapter) written by Simon Brown which somewhat conflicts with the rest of the book.

Hermitian909 4y ago
> I have read many of these books, and don't think its much of a concern because they often don't even agree with each other, and anyone paying the slightest attention to what they are reading will wrestle with the tension. I'm not sure you're the norm, at the very least a large number of engineers I've interacted with or mentored have come away from these books with either an explicit belief in these hard rules or an implicit one. I've found Uncle Bob's work tends to be particularly bad in getting engineers into this mind set (though maybe I over-indexed because I think so much of his advice is bad).
- serial_dev 4y ago
  In my experience, Uncle Bob's followers tend to be very dogmatic and somehow they think that only Uncle Bob's books are worth reading, so when you point out that maybe there is another valid perspective on the issue and not only Uncle Bob's, they look at you like you are crazy. If you admit that you think that some of his books are pretty dated, or if you point out the examples he used to justify certain patterns are so contrived to make the other alternative look ridiculously stupid, or if you say that maybe our CRUD mobile app that only fetches data from the backend and displays it 1-1 doesn't need the 20 layers of clean architecture cargo culting, then they get angry and will label you as someone who "doesn't care and know about software architecture". I'm not even sure why Uncle Bob is special in this regard, I have never met a Sandi Metz/Martin Fowler/John Ousterhout fan who could not comprehend that there are other valid points of view on a situation.