I wouldn't go by any book/article the teaches you game engine physics. But ofcourse, Ive read a few, that may have influenced my thoughts over how I write code. But never believe everything you read.
The way I see it, physics is just a set of interaction rules for various actors involved. Just like ticket reservation system.
Learn the rules, when you see a box tumble down a slope, it shouldn't look magical. If you can garner exactly whats at play, you can apply the rules in programming.
Now the trick with game physics: it bends the rules slightly, some will skip details, simplify a model, reduce the number of variables.
Using finite element/slice methods - in this you simulate a few set if equations over a finite body for a finite duration of time (cycletime).
Physics engines wouldnt be realtime if they really simulated reality.
Read kinematics and rigid body mechanics in 'Fundamentals of Physics - Resnick and Haliday'.
Try to solve a problem or two from 'Problems in Physics - Irodov'
Then comes the programming.
There is always a debate - go procedural / object oriented , have inheritance hierarchies / composites.
In the end you'd really have to be a good programmer - no alternatives.
Master double dispatch and visitor pattern for c++/java, or take to dynamic languages like Ruby.