So you have 3 years of working experience. How many code bases of similar size are you familiar with?

When working on a new code base of that size, figure out how old it is, and how the requirements changed over time. It might be more likely your don't see the big picture of why things are done and structured the way they are. obviously, it would be great to have someone around to ask why every time your see something that doesn't make sense or seems overly complicated or backwards. You don't have that luxury. But try to get to know the code more.

Sure, you might be right and the code is just complete garbage, but I'm just reminded of how third semester CS students also know everything better as soon as they learn some pattern X and consider it the best and only way to do things. :-)

Good advice that more generally amounts to Chesterton's fence:

https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence

To expand on this. Shit code is not the result of poor developers. It is the result of bad requirements. Bad communication. Bad business processes.

All of this is usually the result of a VIP or someone who thinks he is a VIP screaming to make an exception for his special needs. This shitty exception results in illogical processes. And shitty code.

At the end of the day, it is all boils down to weak management who cannot stand up to problem customers.

1. Shit code is in the eye of the beholder. Most programmers think code they didn't write qualifies as shit. I see it as an opportunity. Learn it, fix it, make it better, that's part of the job. What did you expect you'd be doing that makes this job seem so bad? A programmer who can competently work with legacy code without whining has a valuable and rare career skill, so get good at it and increase your value.

2. I don't get invested psychologically in code, and certainly not physically. Get some perspective.

3. Martin Fowler's book Refactoring has some good advice and techniques.

Just to be clear, I was not implying that I want to give up and not do it. (I love writing and fixing code). I was more alluding to the fact that every time I fix a bug, I just want to fix the whole thing.

Thanks a ton for your advice and thanks for the recommendation!

I know the feeling. Resist the urge. Incremental refactoring almost always works better.

This is obligatory reading, and I would say at 3 years you're probably exactly at that stage of your career when developers tend to be most susceptible to this mistake: https://www.joelonsoftware.com/2000/04/06/things-you-should-...

The message in this is as true now as it was 23 years ago. Granted, the code in your case might not be the company's flagship product for all I know, and maybe you should start from scratch, but definitely not until you've tried everything else.

This, really; It's a shame I can only upvote it the once.

Damn, it's like Joel is talking to me. Thanks for sharing this.

> This is killing me.

You should absolutely not continue doing something that is literally or figuratively killing you.

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

Handling shitty code doesn't affect me mentally and honestly I don't see how it could affect anyone physically. It's not like it causes you nausea or stomach pains, is it? However, feeling that my talents are wasted negatively affects my mood. I would not stand "duct taping" someone's trash unless I were given the authority to refactor and fix the underlying problems with it.

Bottom line is that you should leave jobs that make you feel bad.

I will share a contrarian experience I had. I once had to maintain the tcp/ip stack for an esoteric device running Linux. The stack was insanely complicated, with C code calling ksh scripts, etc. I was able the code's authors why it was designed this way: Because Linux doesn't let you assign more than one ip address to an interface. Except it does... The architect didn't want to believe me when I told him that Linux has had this feature for over two decades. Eventually he realized I was right and apologized. So, all code is written the way it is for a reason, but that reason may not be a good reason.

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.

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

Love this line! Thanks a ton for you thought, they are great and to the point.

I am about six years in on software dev career. Every so often, I'll see something that makes me think, "What fxcking animal wrote that?"

Very often, a quick git/blame shows my own name back to me.

Have patience, have mercy.

Love this!

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

Almost as often as I have to deal with shit code I wrote :)

> I'm in the process of fixing bugs (and learning about the code altogether).

This is exactly the way to deal with this situation. Until you understand the project's architecture you can't make an objective decision on how to improve things.

As you go along make sure that you're adding in relevant tests so that when you are in a position to make an objective change you can make sure you don't break the actual business logic of the project.

My very first programming job was like this. The simple method is this:

Leave the code as is because if it ain't broken, don't fix it.

However, once you have to go into code and fix it, this is where you can re-write it, leave comments, maybe even put the old code at the bottom in a comment.

It'd be too much time and possible errors to fix everything, but if you can go in there and re-write some, maybe even make it more efficient, than you might be able to do it.