I recently started working as a developer for a start up. I have a little more than two years of programming experience (college + internships), and at this new job they asked me to do some feature enhancements and the entire code base is a mess. I am pointing out a few technical difficulties I face as a context to my question. Any reasonable developer must be able to agree on a few of these being annoying.

  • 90% of the functions are inside their own "try...except Exception" blocks (makes debugging a PITA)
  • Zero comments or docstrings (no feature documentations either; just word of mouth on the so called "Code Walkthrough")
  • Non-idiomatic code
  • Query formatted using string concatenation (not sure how well the inputs are sanitized)
  • One single dictionary used as input and output across a variety of functions, mutated everywhere.

When new features or bugs are assigned, I find it extremely difficult to debug this as virtually all errors are suppressed and printed as logs; as a result I end up spending more time to deliver what is expected of me. The program never breaks. Any and all exceptions are captured and silenced as logs. So there isn't any way to find where an error happens without getting messy (using "traceback" calls, etc.) which is not really needed if the exceptions were handled judiciously.

What I have tried

I tried asking for help internally, obviously. The response is there, but most of the time it is something along the lines of "Debug and find the difference", but debugging isn't really helpful as I have explained earlier.

I spoke to my manager, and his response was that I can rewrite this codebase given some time, but I deliver what is expected before I start the rewrite, which again comes to the point: I can not figure out this spaghetti code. If I can I wouldn't even have to rewrite.

Why is this a problem?

I am not able to complete things on time, so I am not performing as much as I want to. This will affect my growth, and I may get fired for not being punctual. I am beginning to hate my job as a result of this, not being able to write code, because I do not want to spend time debugging a mess.

Other Information

I am in no way a veteran developer. I spend some of my time answering (also asking) questions on Stack Overflow and I have a fair bit of an idea on what good and bad code looks like. I have zero experience as a professional developer other than a few months (internships aside), so I do not know if this is a normal occurrence.

Do let me know if you need any additional information.


Having taken into account the responses I have received here, I went ahead and spoke to the people who wrote this and their latest response is (non-verbatim)

"Change based on current needs. You are now the owner of this code base. Do what you want to make it work."

This pretty much feels like they are relieved it is not their (problem) anymore.

My manager did agree on letting me rewrite the code, but only after I complete my current backlog, which I guess is a sensible request from his end.


12 Answers 12


A lot of legacy code sucks. Even if the code was developed using best practices at the time best practices ten years ago are very often quite different than best practices today. But more than that, as developers come and go, not all developers are going to adhere to the original vision that the original developer had. Like even if they're able to figure out that vision they may just not care to further advance it. Some devs may care but other devs may just implement quick ugly hacks to get the job done. After a few years of this and you can have a really ugly code base.

My advice would be to just try to stick with it. If you run from a job every time you encounter crap code you're going to be running from every job under the sun. Well, maybe except for green field startups. If you get used to working with crap code now then your experiences can be stories that you share in interviews later on down the line!

  • 1
    Comments are not for extended discussion; this conversation has been moved to chat.
    – Lilienthal
    Commented Mar 26, 2021 at 11:13

There are a number of kinds of programmer jobs. This is one of them.

"Support legacy code" is a big part of the industry, with varying levels of ugliness. If you decide that you're not okay with working in that part of the field then yes, you can leave and seek another job, but you should realize that you're cutting out a lot of the possible career space. If you're generally okay with legacy code, but think that this particular legacy code is uniquely ugly, and don't want to deal with this stuff specifically? Well, you might be right. I wouldn't necessarily bet on it, though.

It sounds like you're going to need to work on refactoring as you go. Your boss doesn't sound likely to offer you a chance to do any major refactors any time soon, but he's not going to stop you from improving the code that you touch. Once you figure out what a piece of code is doing, comment it. If you're touching a portion of the code and you see those "swallow all the errors" wrappers, consider where you can afford to make them more informative. Even if you keep them running to the logs, you can dump the entire stack trace in there, at which point it should be relatively straightforward to get the information you need anyway. As you understand things better, work on improving where you can.

As far as "completing things on time" is concerned, is this just your perception, or are you getting some sort of feedback from your bosses that they consider your work unacceptable? It's true that legacy code with a lot of code debt takes longer to work with, especially when you're just starting out. It's possible that they're taking this into account and you're not. This will probably get better as you get a deeper understanding of how the system works (and manage to refactor some of it). As far as "affect your growth"? Well... yes, but not like you're thinking. It won't affect if you grow or how much you grow. It'll affect how you grow. Like I said, managing legacy code is a huge part of the industry. Learning how to do it well isn't wasted growth.

  • 1
    thanks for the response Ben, I have not thought about the fact that my boss could actually be taking into account the factors you mentioned, I will try talking with him regarding this Commented Mar 24, 2021 at 2:36
  • 1
    Also, push back on deadlines, manage up, and build informal relationships - if you need support from the previous developers on specific things, let your manager know, or, more usefully, try and make friends with the old devs. Don't approach it as though they are incompetent, but accept that the code base you inherited was built up through time, with layers of decisions and compromises along the way. Try and understand why that janky looking script was written like that. There might be a good reason, and the more of this you can take in the better.
    – lupe
    Commented Mar 26, 2021 at 10:58
  • 2
    In my experience of ~5 years working, adding a simple feature is not as trivial as you though when you were learning. You may come up with the solution quickly, see the end goal in you head but often implementation, testing and deployment take 85% of your time. (Good) Management know this, the more you work on a product, implementation reduces (and hopefully testing also as you build the test framework up).. and as Ben says Learning how to do it well isn't wasted growth Commented Mar 26, 2021 at 11:29
  • 1
    Adding good comments may add a lot of value to the codebase without actually changing anything (where you need to retest etc). These days markdown files next to the code is a reasonable compromise if you cannot put the comments in the code itself. Commented Mar 28, 2021 at 0:01
  • Legacy code might be as simple as "somebody elses code". People think differently and their code reflects this. Commented Mar 9, 2022 at 17:50

Legacy code compose most of the development on the market. You rarely get to develop new projects from scratch with state of the art tools and practices.

Legacy code is not bad per se but it is still a common enough occurrence that you need to learn how to work in such a environment.

I'm not saying you need to suck it up and stick with it, but that you need to leave a chance to your workplace. You need to learn how to tackle legacy code (you can read "Working Effectively with Legacy Code" for example) and you need to teach your colleague and manager about the cost of bad code.

If you can teach people better practices and introduce good practices and tools to your workplace you'll gain valuable professional skills and credibility. However if the situation does not improve and you're suffering from it then by all means find another workplace.

  • I guess l will try for a couple more months and try to make them understand the cost, also thanks for the book recommendation :) Commented Mar 23, 2021 at 16:32
  • 4
    One thing agout "the cost of bad code". With legacy code usually no matter how many cons you can come up with, the pro column always is "does the job well enough". Upgrading is trading the certainty that it does the job against a promise that it will still. Most managers don't really care if it has quirks, if it's janky and inefficient, as long as it does the job. I think practically it's less about the cost of bad code and more about quantifying the gains of upgrades, and that the credibility you need is that you can deliver them on time and on budget. Commented Mar 24, 2021 at 8:32
  • This is just an opinion, but in my opinion, if a legacy system needs a full time employee to fix problems, it is not doing the job well enough.
    – ojs
    Commented Mar 27, 2021 at 22:53

I'd continue working. Do your best with the codebase as it stands, you'll soon get the hang of how it hangs together.

As you work on items, clean up the code the best that you can in the areas you're working in. After a while, you should be able to free up some time for some wider work.

But for now, ramp up and adjust as necessary. Treat this as a learning experience.

Also, if you left and found another job, the likelihood of you ending up in a team using a fabulously organized codebase is minimal. Perfect code is an ideal but there's always going to be a compromise between perfection and "get it done". The majority of the time "get it done" wins.

  • your last paragraph is very much similar to the other answer, and the "get it done" part was something I kept telling myself when I was looking at the code, thanks for the response! Commented Mar 23, 2021 at 16:09

As others said, there's plenty of crap code out there, and lots of us will end up maintaining it.

(It's also fair to say that we're the ones creating it, under pressure, or at the beginning of our careers, or because we don't know any better. Don't take it personally when others push such code on you!)

However, your choices early in your career matter. A lot. If you spend your first few jobs doing maintenance of some spaghetti-code apps, it will be difficult to develop your finer engineering skills. It will be difficult to learn good design. And recognizing bad designs isn't the same as knowing how to create good ones.

In my experience, this will stunt your career opportunities later on. I am interviewing many software engineers and I have rejected scores for this very reason. They are nice, friendly and know basic programming, but after years of working in a bad environment, they don't seem to see beyond that. They don't know how to solve problems well. After being told many times that things can't change (or change, but slowly), they lost their spark. Their go-to engineering solutions will be colored by their (bad) experience.

When a fresh graduate is lacking finer skills, a hiring manager is looking for the ability to learn. When someone with 5 or 10 years of experience is lacking those skills, that's a huge red flag. Why didn't they learn yet? Will they ever? Are they coachable?

Being choosy about your jobs early on in your career will limit your choices. Not being choosy will also limit your choices (and your salary) later on.

As to what to look for in this - or other - jobs. It's not as much the tech that matters, but the mentors. Find a place where there's someone you can truly learn from and then glue yourself to him or her. Learn as much as you can before you move on to the next opportunity.

  • your suggestion sure has a different take, which is very much what I think, "if not now, when?" you have clearly explained what I had in mind :D Commented Mar 24, 2021 at 6:02
  • I like how this answer turns it into a potential learning experience.
    – Kilisi
    Commented Mar 24, 2021 at 9:03
  • 3
    I dunno if I agree with this one. Everybody's code is more or less "legacy," or very soon will be. Businesses change, computers change, things become possible that didn't used to be, and on and on. Meanwhile, quite outside the computer, the business changes also. "Maintaining legacy code" is a very fundamental part of the job. Commented Mar 24, 2021 at 16:03
  • 3
    You're right to an extent, Mike. But there's different kinds and levels of legacy. Some of them are "normal". Some are hopeless messes which kill your soul.
    – Sam
    Commented Mar 24, 2021 at 21:45
  • 1
    I strongly agree with this answer. Indeed, there are different codes of legacy. You can have software well designed which gets old, or software poorly designed which gets old. The former can be okay, can even have more interesting challenges than just writing something anew. The latter, however, not only will stunt you, but probably the environment where that code was developed will also be poor.
    – raxxast
    Commented Mar 25, 2021 at 13:49

You wrote:

Spoke to my manager, his response is that I can rewrite this codebase given some time but I deliver what is expected before I start the rewrite, which again comes to the point, I can not figure out this spaghetti code, if I can I wouldn't even have to rewrite

This sounds like an ideal case for gradually "refactoring" the codebase.

As you do your day-to-day tasks, take the chance to "refactor" (improve) the code base. Start, for example, to improve exception handling. Then add comments. Then improve the query handling. Then improve something else, and so on.

Talk to your manager, let him know your ambition to do this, and mix "refactoring" work with your day-to-day tasks. Convince them that the refactoring will deliver dividends in the medium to long term, given that a better code base will be easier to work on, both for you and the next programmer (whoever that may be).

Over time the code base will improve, and one day it will be logically organised and clear.

As programmers we all have to deal with bad code from time to time. Don't be scared or disenheartened - take this as a challenge and learning activity!

  • 1
    thanks for reassuring me with your response, I did get to talk with my manager and I have added an update on what the discussion led to Commented Mar 24, 2021 at 8:35
  • Be very sparing in your "refactoring." Commented Mar 24, 2021 at 16:04
  • 5
    If at all possible, build automated tests to check out the code you're changing before you change it. If you don't know what it's supposed to do and don't have a way to test for it (preferably automatically), then you won't know when your refactoring breaks something. If you leave the testing to your users, pretty soon you'll get a "no more refactoring, you're breaking everything" order from the boss.
    – George
    Commented Mar 25, 2021 at 19:15
  • 2
    I agree with this approach. I had a coworker who rewrote an entire (small) program, without any authorization, just because he didn't like the style. Developers are expensive and if I were the boss, I would have been furious about that redundant spending. But OP has some authorization, and the approach of vikingsteve is good.
    – donjuedo
    Commented Mar 26, 2021 at 3:29
  • You cannot rewrite what you don't understand. Commented Mar 28, 2021 at 0:02

So, welcome to the actual world of software development, not the world as you would like it to be. In the world, as I would like it to be, all code would be heavily commented, have proper test plans, designs, requirement specifications, and a lot of other things.

I've been at this for 42 years for money, I'm still not getting what I want.

This is more tailored to the situation that you're in.

Until you have enough experience, which is going to be much closer to 10 years than where you are, you won't have the professional reputation to make organizations change. What you can do right now, early in your career, is begin to develop that reputation. That means:

  1. Leave code better than you found it.
  2. Code idiomatically in whatever the language is. Don't make it your personal style, but do it it clear and readable, and in the idiom for that language.
  3. Be really careful lecturing more experienced developers. We all know that we're forced to do things we don't want to do by managers who need to stop doing that.

The kind of issues you're describing are something that takes years to fix. For one thing, there's a lot of legacy code that's rotted over the years. For another thing, you have to get your co-workers on board with the idea.

But what you can't do, if you want to ever have good code to work on, is quit. Because it's just as bad, more or less, at the next place.

  • 1
    Your 3 point is pure gold. Im actually gonna write that in caps on my whiteboard so it will distract me everytime I look up because it's just too easy to forget for something so capable to causing damage.
    – user12345
    Commented Jun 7, 2021 at 0:33

The most important thing first: No, this is not a normal occurrence. I have worked over 15 years as a software developer, in a startup (in the UK), government department (in New Zealand), big research institution, telecom and billion dollar investment institution (all in Switzerland). None of them had anywhere close to this bad code. Sure, I came across all of these issues (not the "90%" part, but all of them separately) more than once, and non-idiomatic code in particular is pretty common, but a code base littered with all of them is a death trap.

A manager worth their salt will know that rewrites are very risky and quite costly even when they go really well. In a startup it would be naive to expect that a rewrite is anywhere within the financial horizon of the company.

As for whether you should stay, there are heaps of jobs where you get the appropriate training, where people actually care about things like quality and security, where managers are realistic and honest about rewrites, where you can turn to people with intimate knowledge of the existing system for help, and, if even slightly lucky, all of the above.

  • thank for assuring me with your response, I did add an update stating that my manager has let me rewrite the code once I am done with my current deliverables, but I do agree with potentially going with a job where I get more training if things do not work out here soon. Commented Mar 24, 2021 at 8:32
  • 4
    Your situation is actually extremely typical, and the grass is not greener on the other side of the fence. Commented Mar 24, 2021 at 16:04
  • 3
    The software industry is vast and varied. The software that I worked on when I was in the financial industry was very performant and high quality, because a bug or bottleneck in that code could have quite literally ended the company financially. The image processing software that was only used by other programmers to get results for other technical people was messy but not awful. The web app stuff written by mostly by contractors that didn't stick around longer than 6 months was a daily dose of WTFF. To argue about what is normal or not with so little specific information is silly.
    – ColleenV
    Commented Mar 24, 2021 at 19:01
  • 4
    There's a reason why The Daily WTF has enough content to post every day (and probably will forever). Commented Mar 25, 2021 at 12:43
  • 1
    There are millions of software developer jobs. Finding one horror story per day is simply a matter of numbers: of course there will be lots of horrible examples in any sample of millions.
    – l0b0
    Commented Mar 25, 2021 at 18:29

Having to work with an old codebase is not a problem in itself. Someone has to do it. Just like someone has to collect people's garbage once every week or every two weeks. Of course if you don't like it, you should find a different job.

The workplace related problem may be that your work isn't valued. It only produces cost for the company, no new revenue. And as you said, you produce fewer results a week than you could in some other position. But it must be made clear to your manager and management in general that you need to be paid for the work you put in, not for how much profit it puts into the company's pockets. (And if it only produces cost, no new revenue, I guess it would cause huge damage if that work wasn't done, or they wouldn't have hired you in the first place. Producing profits and avoiding losses are the same thing. Or we should get rid of firefighters in towns everywhere, since they never produce anything of value. Usually when they do their job, there are massive losses. If they don't do their job, there would be much more massive losses, that's why we pay them).

So make clear to your boss that (a) the code base is messed up, and that it is undocumented, and that any work in it takes more time than would be expected, and (b) your pay must be the same or better than that of the people doing the fancy jobs.

Depending on how long this product is expected to be maintained, get an agreement with your manager that it is part of your job to improve and document the codebase.

  • 1
    If it was fun, they wouldn't have to pay you to do it. Would you do it voluntarily? No. Would you do it in exchange for money? You should. Commented Mar 25, 2021 at 13:40

Part of this is on you. When interviewing for a job, especially a programming or engineering job, some of the questions you should be asking are:

  • What technology is being used? How big and old is the code base?
  • Is this greenfield development?
  • Is there a good amount of tests written?
  • What sort of automation is being used (CI/CD)?
  • What's the check in and merge process, what do you use for source control?
  • What sort of tools do you use to assist in development/testing/debugging?


Be sure to ask these questions during the interview process. No company is perfect, but there are a lot of companies/code bases out there that drain your soul.

If you are unhappy, just stick it out for 6 months to a year. Nobody likes to hear I quit my last job because the code base was terrible. You could still learn a few things of what NOT to do, and you might be able to make small improvements during your tenure which you future employee will ask about.


The key question is:

Does your management understand, acknowledge and own the problem, and do they manage their own expectations regarding efficiency and quality of work based on that code base?

If yes: View this as a chance.

If no: Run :)


I have often found that the best approach when bringing these matters to the attention of management is not to complain about the complexities in the code, or how hard it is to develop against, but to bring a clear description of an issue that is caused by that structure.

In your case, with large amounts of exceptions being swallowed, come up with an easily explained and reproducible issue, e.g.:

  1. Client logs adds a foo to the basket
  2. Client checks out, but the checkout code fails silently when taking payment.
  3. We ship the item to the customer anyway

And this will probably grab their attention much more quickly. It is a question of framing:

"I have a problem with the codebase that is making it very hard to write and maintain this code without introducing bugs - can I change it please?"

This is your problem

"I have a problem with the codebase - I have found [Insert awful business problem here] that seems to largely be arising from the structure used in writing this. Can I have time to change it please?"

This is the same thing, but it is now a problem for your boss, and thus easier to get time set aside for you to work on it.

Code that is as hard to write and maintain as you describe is also much more likely to have such appalling issues. Anything that is regularly catching and eating exceptions is going to lead to the possibility of all sorts of oddness happening.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .