Currently I'm working with a codebase at my job which I think is absolutely terrible. Documentation is largely missing, there's a lot of inconsistency, singletons all over the place, and on top it's slow as hell. So after spending two hours today trying to do something that would take a couple of SECONDS in comparable applications, I lost containment and gave my keyboard a "mild" slap with my flat hand. Others in the office noticed that and I felt pretty ashamed and frustrated. I'm the only one working on this project, so nobody would probably understand my pain.

Do you ever have situations like this and if so, how do you deal with it?

Yes, I can relate. But I just remind myself that my job at its absolute worst is still a million times better than what most people on the planet do to make a living.

Slapping a keyboard doesn't sounds too bad. I went through a phase of punching monitors when I was a youngster. It was all CRT in those days so caused a few injuries.

One nice side effect is as you learn to cope with this code base, you'll become a more effective coder because of it, and you'll become really good at refactoring

I try my best, as I suspect most people do, to be a productive and efficient worker. I sometimes get frustrated when external factors beyond my control negatively impacted that productivity as well. Years ago I got into the habit of reciting an irreligious facsimile of the Serenity Prayer to myself when I had those moments of frustration. Basically:

Accept what I cannot change.

Change what I have the power to change.

Is this situation the former or latter?

I also force myself to recognize that my frustration is unproductive in itself and only exacerbates the problem. It doesn't always help, but it often does for me.

I went through a phase of punching monitors when I was a youngster. It was all CRT in those days so caused a few injuries.

I have still have quite noticeable scars on my foreknuckles from where I put my fist through a CRT screen about 20 years ago. I had just spent several weeks writing writing a textmode GUI for DOS in assembly when my HDD crashed and I lost the entire project.

One nice side effect is as you learn to cope with this code base, you'll become a more effective coder because of it, and you'll become really good at refactoring

Just make sure your boss doesn't think you cope too well with it, otherwise you'll become 'the expert' and never get away from it.

Get a rubber ball that you can squeeze in situations like these.

I think for most people who aren't real veterans, their initial reaction to most new codebases is one of confusion, mistrust, and irritation. We all know how "We'd do it", and that very rarely coincides with how the things we're handed were done. Its sort of NIH-ish, although its not always the case that what we're handed is well-tested and battle-worn like the libraries of code some people distrust due to NIH-syndrome.

It helps to keep in mind, though, when those things are well-tested and battle-worn, because its nearly guaranteed that your newer, better solution will have more bugs in it. It also helps to keep in mind that you, now, don't have the context that whomever wrote it did. You don't know what ridiculous requirement or bug inspired that snippet of seemingly-hideous code. It takes some wisdom and experience before you really know what's worth re-doing. As an annecdote, Bjarne Stroustrup, inventor of C++, will happily tell you that today's Bjarne couldn't have done a better job at inventing C++ and making it a success than young Bjarne -- not because Today's Bjarne has grown slow, stupid, senile, or out of touch, indeed today's Bjarne is much wiser -- but because today's Bjarne is not steeped in the realities that young Bjarne was. Today's Bjarne is incapable of understanding things in the way that young Bjarne was.

That's not to say that old-code is good code. Everyone has seen at least one old, decrepit, crawling horror before. There are times when a radical refactoring or complete re-write justified. Really, what you have to ask yourself is this: "Can I make it better and fix it in the same amount of time that I can just fix it?" If you can size that up honestly and accurately, then you know what to do.

Its hard to do that with whole system though, and an even harder sell to management. A good strategy is this -- when you need to make a change, see if you can refactor something to make the change easy, rather than simply slogging through a hard change. If you can do this, things will become more sane over time.

Biggest question for the original poster: Are you in a position to change it?

Are you able to make incremental changes?

Obviously you have the authority to make some changes, since you are writing and modifying code.

Even if you don't have the ability or authority to remove a singleton that is used in millions of places, are you at least able to tidy up your corner of the world?

When you submit a change to a system, if something specific bothers you, look at what is involved in correcting some of it. Rename the inconsistently named variable used in 30 files, but keep the total change small, a checkin note "renamed for consistency with other systems." Rewrite that one troubling function, and as part of the code review and submission make a note: "Also cleaned this function up, measured before and after with the profiler, now with 70% more speed."

Even if you don't have the authority to make sweeping changes today, you do have the authority and ability to make small improvements. Just be sure to verify that they actually are improvements. Do it consistently, and eventually you can make bigger and bigger systemic changes.

Keep them small enough that they are within your scope and simple enough that they are not disruptive, but part of programming is cleaning up behind you. It is not so different from wood shop where you must clean up the sawdust and cuttings. Cleaning up as you work is part of the job.

When I hit a source of irritation, I remember that my ultimate goal is to learn and better myself as a valuable individual.

To do so means also coping with this shit, and there is a way to present that under a better light.

Robert C Martin, for example, wrote two books that heavily describe methods to be better at what other consider a shitty job:

• Clean Code: A Handbook of Agile Software Craftsmanship. Prentice Hall PTR. 2008. ISBN 0-13-235088-2.
• The Clean Coder: A Code of Conduct for Professional Programmers. Prentice Hall. 2011. ISBN 0-13-708107-3.

Several chapters in these books give you an in-depth howto that covers bad code and how you deal with it. It gives you ways to keep your cool and make the job manageable without going to either extremes:

- I don't give a shit (which means you just do what you need to)

- I want to refactor this whole mess and start from the groundup (which is not profitable for your business, especially if the software is actually working)

It helps you be a boyscout too :)