So the following was a bit too long for a comment...
Perhaps taking one step back and comparing benefits of preventative and detective controls might help. Preventative controls include encryption but you could also encode the password to make it less obvious. This approach is meant to protect the password from accidental sharing (a b32 encoding would produce less meaningful characters (b32 produces longer string than b64). Such an approach just increases the difficulty of memorizing the random sequence of numbers as well as the method that should be used to decode the string. Base32/64 encoding is a simple way of protecting passwords that do not require additional logic to be built/maintained.
The other approaches to preventative controls would likely use encryption. There are many different ways to protect the key. Without getting into the details or reiterating what D.W. already posted, you can layer detective controls to improve the security posture. For example, you can audit access to a file that contains the key. You can correlate events (such as restarting of server/service) with access to the key file. Any other access request (successful or not) to the key file could indicate abnormal activity.
To get to your questions, here's my take:
if you have to store password in a config file, I'd recommend at least encoding the password where possible. Encoding the password would reduce the chance that it's leaked in the event someone scrolls through the file, say with a vendor support rep watching. Encrypting the password is much safer, but that requires additional complexity.
How to deal with the fact that a key has to be hard coded or stored in another file. Well, separating the encryption key in another file increases the difficulty for someone to view the key. For example, you can use access control to limit access to the key file but still maintain a more open ACL for the config file. Similarly, you can implement auditing for access to the key file, which you can use to correlate back to events that require use of key. Hard coding the key may be fine if you limit access to the binary. Careful encoding of password can easily be detected by running a "strings" against the binary. You can encode/encrypt the hard coded password (i.e. require a separate function (perhaps with auditing) when to decode the password, but that increases the complexity for the developer and admin (i.e. how does one change the key without rebuilding/recompiling the binary?).
Should the encryption keys for password be human readable? It depends. There's only a limited number of ways to protect the key. An encryption key is usually seen as an alphanumeric string that's hard to commit to to memory. You can always encode/encrypt the key, but such methods doesn't deter someone that's smart enough to take a screen shot. However, you can use simple "keys" (more like passwords) as input to a key expansion function. In those instances, perhaps additional measures such as encoding adds some additional value relative to the cost of complexity.
If anything, a good approach is to implement multiple layers of controls. Preventative controls are more difficult while detective controls are generally easier to implement. Separating key files could simplify the overall architecture and implementation of controls. Regardless of whether preventative or detective controls are used, enabling some auditing functions is a must along with review of audit logs. This way, should the improbable happen (access to key), you can take corrective action.
