I believe the term "hook" comes from the Windows API where you can register "hooks" - callback functions - to respond to certain events, optionally replacing the original behavior. Not necessarily other processes, it could also be hardware events etc.
If you wish to respond to events occurring inside another process though, that isn't possible because you aren't generally allowed to act on things occurring outside your own process' address space.
One way to perform code injection is through hooks - by placing your code inside a DLL, then somehow trick the other process into loading your DLL by the means of a listening to DLL events through hooks. Then the code inside the DLL will end up existing in the same process as the one you wish to respond to and it can then listen and interact to things going on in that process.
You can also do other forms of "DLL injection" that attaches a DLL to a process, but doesn't modify the other process/program.
Traditional code injection is rather done by appending your own program to the other process' executable, then abuse some API call or other vulnerability so that the process will call code placed inside the appended part of it's own address space. This is how old time computer viruses worked, and old time anti-virus software would simply scan executables looking for binary sequences of known viruses at the end.