While it hasn't "changed my life", I'd like to post a solid +1 for this here.
I just blasted through the audiobook version (which is excellent, btw!) of the 20th anniversary 2nd edition two weeks ago, and might be able to share another perspective on this.
As someone who hasn't been in the industry since the 90ies, I find absolutely astonishing how basic some of the stuff is, yet my own workplace environment is full of people ignoring most of these "obvious" ideas. So if you're feeling like you're re-iterating "common sense" ideas (like: implement things orthogonally if possible; write tests; try out concepts before implementing them completely…) without them seeming to stick, this book is a great resource to point people to.
It's great to know that someone actually described those ideas and wrote down the thought process behind them. If only so you yourself don't have to argue for them over and over again…
I think part of the reason it gets less attention these days is because so much of it is considered common sense now, back then many coders didn't get it yet from my experience.
Of course now we've come more or less full circle and gone all into institutionalizing the methods used to break the status quo.
What do you or the author mean by "implement things orthogonally?
I (somewhat) know what the word "orthogonally" means, but not sure what the phrase means in this context.
That's an interesting metaphor because I picked it up somewhere else, but it might well be that Hunt and Thomas actually coined this phrase in "The Pragmatic Programmer".
If you think of orthogonality in geometry, you can describe any N-dimensional vector space through a set of N orthogonal vectors (say the unit vectors in X, Y, Z). "Orthogonal" in this case means that moving something along one of those (say the X axis) won't alter its position from any other base vector's perspective.
In the same way, "orthogonal implementations" is a way of saying that the things are independent from each other. You can find their explanation in the Google preview for the book [1].
So, say you write utility code for a couple of applications, for example: Message transmission and subscription management. Then, you should try and keep both as independent as possible from each other, so that as a downstream user I won't have to pull in or even "massage" both just to use one of them.
As I wrote before, that sounds totally obvious when said out loud; yet I constantly find new examples where someone found a way to unnecessarily "complect" [2] multiple things.
I just blasted through the audiobook version (which is excellent, btw!) of the 20th anniversary 2nd edition two weeks ago, and might be able to share another perspective on this.
As someone who hasn't been in the industry since the 90ies, I find absolutely astonishing how basic some of the stuff is, yet my own workplace environment is full of people ignoring most of these "obvious" ideas. So if you're feeling like you're re-iterating "common sense" ideas (like: implement things orthogonally if possible; write tests; try out concepts before implementing them completely…) without them seeming to stick, this book is a great resource to point people to.
It's great to know that someone actually described those ideas and wrote down the thought process behind them. If only so you yourself don't have to argue for them over and over again…