Part of critical thinking is to question your own beliefs, rather than being arrogant in believing that you know better.
This is already somewhat contradictory to the Good-Enough Software point made on the book just two topics later, but the worse is that it's actually based on a theory that was already debunked
They were making a metaphor. It could've as easily been a metaphor of keeping your car windows closed, or locking your bike. Do you think you are as likely to get your bike stolen when you don't lock it as you are when you lock it? In some European cities, perhaps, but definitely not everywhere.
a True Pragmatic Programer is skeptical, and values scientific rigour
A trait of a good programmer or a co-worker in general is if they can go along with a metaphor to see its point rather than unnecessarily arguing against their own misinterpretation.
If you are in exploration mode, most of the code you produce has no value and you will throw away
And it often happens that a prototype gets adopted as the basis of a project rather than being completely rewritten.
Being DRY is actually terrible advice for natural language communication, people don't pay attention, people forget, you actually need to be repetitive sometimes.
I think they referred to written documentation, for which this advice is good. Even good for most of verbal communication, though repeating out of compassion is good, of course, though sometimes simply repeating doesn't help - sometimes expressing something in a different way, perhaps as a metaphor, can make things clearer.
actually uses a dogma as an excuse (Good Design Is Easier to Change Than Bad Design)
It may be argued that being easier to change is at the core of the definition of good design.
now instead of one function causing bugs you have 4 functions that can interact in weird ways causing weirder bugs
The refactor is clearly better and more readable, as well as easier to change. The fact that you have to jump up and down isn't actually the case - the beauty of DRY and readable code is that you don't have to get in the weeds (i.e. view implementation of called functions) when you don't need to, since the code is immediately apparent.
It does not work here because this code is so simple, this is the wrong example
The example is not wrong, because every code example should be interpreted in the context of a larger code base. It may not matter if there's no other code around, but we never encounter such code by itself, and the sooner you can find the right thing to change, and the easier you can change it, the less mental effort will be wasted.
Generic Cloud Usage
That's an incorrect usage of "Reversibility". The point is not to miss out by only using interfaces supported by all databases, the point is to separate storage (or other) functionality behind an interface that may have multiple polymorphic implementations. For example, suppose you're designing a note-taking application (it is a real example I used this approach for). I used a service for storage. But why tie it to a specific source? I designed it in such a way that lets you fork it and easily turn it, for example, into electron app that saves the notes in local file system. All you need is to implement a simple interface.
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.
Part of critical thinking is to question your own beliefs, rather than being arrogant in believing that you know better.
They were making a metaphor. It could've as easily been a metaphor of keeping your car windows closed, or locking your bike. Do you think you are as likely to get your bike stolen when you don't lock it as you are when you lock it? In some European cities, perhaps, but definitely not everywhere.
A trait of a good programmer or a co-worker in general is if they can go along with a metaphor to see its point rather than unnecessarily arguing against their own misinterpretation.
And it often happens that a prototype gets adopted as the basis of a project rather than being completely rewritten.
I think they referred to written documentation, for which this advice is good. Even good for most of verbal communication, though repeating out of compassion is good, of course, though sometimes simply repeating doesn't help - sometimes expressing something in a different way, perhaps as a metaphor, can make things clearer.
It may be argued that being easier to change is at the core of the definition of good design.
The refactor is clearly better and more readable, as well as easier to change. The fact that you have to jump up and down isn't actually the case - the beauty of DRY and readable code is that you don't have to get in the weeds (i.e. view implementation of called functions) when you don't need to, since the code is immediately apparent.
The example is not wrong, because every code example should be interpreted in the context of a larger code base. It may not matter if there's no other code around, but we never encounter such code by itself, and the sooner you can find the right thing to change, and the easier you can change it, the less mental effort will be wasted.
That's an incorrect usage of "Reversibility". The point is not to miss out by only using interfaces supported by all databases, the point is to separate storage (or other) functionality behind an interface that may have multiple polymorphic implementations. For example, suppose you're designing a note-taking application (it is a real example I used this approach for). I used a service for storage. But why tie it to a specific source? I designed it in such a way that lets you fork it and easily turn it, for example, into electron app that saves the notes in local file system. All you need is to implement a simple interface.