There are lots of sensible ways to do key derivation. Key derivation functions are a kind of hash functions, but normal cryptographic hash functions are often insufficient. Normal hash functions are designed to be fast on large inputs, whereas we want a one-way function that is very expensive even on small inputs, as to make cracking infeasible.
Your general idea is sound. Given some key derivation function H, we can compute an encryption key
If the password is strong enough, then this is perfectly fine. For example, if we want to use AES-256 as encryption, our key needs 256 bits of entropy. That is 32 bytes. But passwords are comparatively low entropy, and would need to be much longer to achieve this level of security.
So, an alternative is to derive the key from two parts: a partial key with the purpose of providing enough entropy to secure the encryption, and a human-friendly password. Both of these parts are crucial. Both must be kept secure since they could aid with cracking the key, but either part alone is not sufficient for performing decryption. You can think of the partial key as a salt for the hash function.
Of course, storing the partial key together with the encrypted file would be problematic, but this depends on the exact threat model. Example use cases for such a split key:
A password manager uses an encrypted vault. The vault may fall into the wrong hands. To open the vault on a new computer, I need a key file that I must separately transfer to that computer, and a password. Once the key file is installed, I will only need the password to subsequently unlock the vault. This strategy is widely used, e.g. by 1Password and optionally by Keepass.
A backup tool stores encrypted backups remotely on an untrusted server. I need to provide an encryption password, from which a key is derived. But to prevent weak keys from being used (for example, by reusing server credentials for encryption), the backup tools generates a cryptographically random partial key. I must store this key separately, and will need it together with my password to make and restore backups.
So, both you and your dad are having sensible ideas here. It would be useful to think about your threat model, about what data an attacker may be able to access, and about what security level is needed. In some cases, relying on a key derivation function might be sufficient. In other cases, you might want to combine the password with some random data to generate a stronger key. But unless you rely on frequent manual entry of the human-readable password part, it might be easier to just generate a strong password/key from the start.