Should I quit my job if I am taking over a bad code base with not-so-good support from the original creators?

Question

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.

Update

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.

Answer 1

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!

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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!

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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?

Etc.

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.

Answer 11

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 :)

Answer 12

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.