All code ends up as shit code. Misuse, poor maintenance, shifting contexts and rotating developers mean very little code stays good. It's fine. Accepting that bad code is fine and should just be documented as an opportunity for refactor and moving on is the path to a successful career/less frustrating life. You'll watch code you wrote, that at the time was fine, become terrible after you move away from that area. It's just a fact of life.

Also, you have 3 years experience, so you probably have very little understanding of what "good" and "bad" actually means, with respect to large software systems. Deadlines exist, priority calls need to be made, things have to be done for the sake of delivery. Not everything can be "good", but lots of "bad" code is actually just fine.

> (and learning about the code altogether)

If you're saying this, stop saying things are bad. You don't know what you don't know.

Read this, internalize it: https://fs.blog/chestertons-fence/ By far the best resource I've ever found about thinking about legacy code.

> 1. In your engineering careers how often do you have to deal with shit code other people wrote

It's all shit, and most of the stuff we all write every day starts or becomes shit

> 2. If so, how do you deal with it? Psychologically and physically.

Escape the trap of binary thinking and accept that code serves a purpose and if that purpose is being met, it's fine.

> 3. Are there any resources online that can help me structure my thoughts around this problem.

Linked above.