If your codebase is messy…
The biggest obstacle to improvement in large codebases is the existing code. “Duh.” you might say. But I’m not talking about how hard it is to work in difficult code; I’m talking about what that code leads you to believe.
If you spend most of your day wading through ugly code, it’s very easy to believe that it will always be ugly and that any little thing that you do to make it better is simply not worth it. You might think, “What does it matter whether I make this little peice nicer if 90 percent of the time I’ll still be working with murky slime? Sure, I can make this piece better, but what will that do for me this afternoon? Tomorrow?”
Well, if you look at it that way, I’d have to agree with you. Not much.
But if you consistently do these little improvements, your system will start to look significantly different over the course of a couple of months. At some point, you’ll come to work in the morning expecting to sink your hands into some slime and discover, “Huh, this code looks pretty good. It looks like someone was in here refactoring recently.” At that point, when you feel the difference between good code and bad code in your gut, you are a changed person…
— Michael Feathers (p. 75 of “Working Effectively with Legacy Code”)
I would love to work on new projects where I will have influence on the decisions about the structure of the project (or at least I know the reasons behind the chosen structure), and whose codebase is kept clean from the start.
But most software systems in existence today are in the maintenance phase. And I’ve seen systems in the maintenance phase whose codebase is very messy. It’s so hard to work on such codebases, especially when you are just a beginner programmer. And in the beginning of my career as a programmer, I was amazed that production code can be messy too. I even thought to myself during that time that I will never work on any messy codebase again.
But my attitude towards messy codebases somewhat changed after I read this from an article written by Jonathan Boccara (“The Right Attitude to Deal with Legacy Code”):
I think it is important to recognize that legacy code is not the enemy.
In fact, in most cases, we’re here thanks to legacy code. The early stages of a given project were where it started to grow, capture clients, build up financial interest, and establish a brand that inspired customers. All of this was done with code that may happen to still be around today and that still performs the functionalities that your customers liked you for in the first place. This is legacy code. As its name states, this is your legacy. Without it you would probably not even be getting paid today.
“… consider that the code you’re working on is your code. Even if you haven’t written it yourself, and regardless of how good or bad you think it is, this is your code, and you have responsibility over it.”
Because of that, it’s okay for me to be involved working on a legacy (or messy) codebase on one condition: If you are going to hire me to work on a messy codebase, I will stay working on it for a long time only if the current team involved in it (which will include me) are cleaning it up (or intends to clean it up, and will clean it up) bit-by-bit as they work on it daily. 
If I’m the only one working on the codebase, then I strongly request that I be allowed to clean it up bit-by-bit… except maybe when it is too messy that I do not know where or how to start, then I will not be able to clean it up. 
I’m not saying that I’m already an expert in cleaning messy codebases. I’m not. But I’m studying to be good at it too.
And one of the reasons why I want to be part of a team who wants to keep their codebases clean is that I want to learn from them. I want to learn their techniques of cleaning up codebases. I hope they can also learn from me.
Another reason why I want the codebases I will be working on as clean as I can make it is because I do not want the programmers who will inherit my codebase to spit lots of WT*s while working on it in the future. 
Another reason is because “a well-crafted code base makes me happy to go to work every day”. Another is pride, a good kind of pride I hope. Lastly, if I stay long working on a project, there might arise a problem someday which will be hard to solve, or will take very long to solve, if the codebase is messy.
Okay… That’s my condition before I will agree to work on a messy codebase. I hope that is okay with you. 
If you hire me to work on a messy codebase, and the team working on it does not care about it and does not have a plan of doing something to clean it up bit-by-bit, I will work on that project and with that team only if you pay me a million pesos per month. 
I’m including this here in my anti-résumé because I noticed in my previous jobs that if a programming team does not have a common set of values (such as adhering to “Always leave the codebase cleaner than you found it”) working on a project will become frustrating. And frustrated people will not be very productive.
And if I noticed that I’m not productive in my job, I feel ashamed and I tend to quit.