"I do not know if this is a normal occurrence" - Narrator: It was a normal occurrence.

How many other developers are actively maintaining this codebase?

@snow there were 2 but they have handed over this to me, these two are the people I am supposed to ask in need of assistance

@JoeStrazzere appreciate the response, the code base is in no way advanced, its just that I find things that can very well be done better is handled as a mess and hence my question / confusion, ok, the logs aren't really helpful either, they just show the warning and hide the line number and do not display what function originally called it, the stack trace is not fully displayed, it is a log the end user would see not for a programmer

Cleaning up a mess created by others comes with the territory. Basically you have to inflate your estimates of feature addition and do a little cleanup each time you do something else. That's an essential part of what they're paying you for (attending to client/employer needs in a professional way), even if they don't understand the necessity of it. Most likely they do understand just fine, but have overriding business concerns, making this a classic urgent-vs-important case.

this is a MILLION DUPLICATE, who knows the canonical answer ?

Does this answer your question? Team employs bad practices in programming, Should I still stay?

actually HERE is the canonical answer, @python_user ! enjoy! workplace.stackexchange.com/a/169647/22844

@python_user, You should only quit this job after getting a good job offer elsewhere. If you go to another startup company, you may face similar situations because startups usually don't have enough time for senior programmers to help new grads to a large extent. If you work for a medium or big company, they may have senior programmers to help you to get up to the speed. So, yes, you can always look for a new job, but in the meantime, try your best to complete this current project. Good luck.

Can't you break on thrown exceptions when debugging?

Good luck with the project. My response to such code is always to refactor, rewrite, employ best effort to understand & fix the bad stuff. It's not easy, but especially if you work with the code for longer (weeks/months) making it better one line at a time is good for your sanity. I know it was for me. Also really helps for learning to avoid creating such messy code yourself. And (may not seem easy) don't listen to managers telling you to "wing it" or anything. Do things properly and let them know why & the value it provides (future development easier etc.).

having to set breakpoints just to see the line number of the erroneous call does not seem optimal to me, when the interpreter itself would point that out for me if not suppressed, it is not a wrapper, every function has its own repeated try...Except so I have to change every such blocks in the code base to change the log to show the line number, but for the time being this is what I am following, assume for a moment where you typo-ed a json key, as much as I am to blame, this gets caught up in the logs when a single mention of the line number would make this an easy fix. @Coxy

@AyCe you make a fair point when you mention "Do things properly" and in the fact that this lets me avoid writing bad code myself

@Snow apologies in advance for the ping, but as you recently edited the question I want to know if it is ok to add an "Update" as a new edit? Pretty much a response after I asked them (again) what to do?

@python_user Don't worry, the code you write now will be someone else's misery in 5 years time :) That's what happens in a fast moving industry.

@python_user There are no restrictions to editing your content if it improves it, regardless of who may have previously touched it.

Is logging consistent inside try...except Exception? If yes, you could monkey patch the log calls : check how bad the exception was, handle it, throw it again, with stacktrace, if it's bad enough.

@python_user Edited because code blocks sometimes cause issues - see Do code backticks really have a use on this site

You will not be allowed to do greenfield development with your job experience, anywhere. Supporting legacy code is what you'll be doing at the start of your career. Heck, most development time is maintaining old codebases, even greenfield projects turn into mature or even legacy projects after a while.

Wait : "not so good support" and "original creators", you guys are getting support? And have access to the orignal creator?

@python_user: Okay. So you don't have specific information about the exception inside this Log class? Worst case scenario: you could write a script to modify the codebase: any time you find a Log in a try except block, you replace except Exception with except Exception as e and you call Log.handle_exception(e). It could make debugging less painful.

@EricDuminil these blocks do have as e syntax, so what I ended up doing is e.__traceback__.tb_lineno to get the line number, the Log class only stores e.args which is not that helpful, but having to add e.__traceback__.tb_lineno to every single block is a hassle, but that is what I am using for time being, the people who designed the log and exception handling catered towards an End User log, so things like line no end up getting missed

@python_user: Couldn't you modify the Log class in order to save more useful information, and not just e.args? Once you have access to e in every exception call, you could work on getting more useful info inside Log methods (or MyDebugger) and start from there, without having to modify every single block, couldn't you?

Yes inheriting bad code is normal. Much of the code from 10 years ago is bad. Most of it due to practices didn't exist or a company rushed people to make a product as fast as possible. This is also a good sign considering that you see these mistakes. It shows there is improvement in the company, and you bring much needed improvement to that code base.

@EricDuminil all the custom Log class does is call the addHandler for a Logger object and sets the formatter, level to log and the name (in case of a FileHandler) (all this info fetched from a config file); the class has a log attribute which is used to do the actual logging using log.error or log.debug calls, it is not a custom container, in reality this could not even have been a class, just a normal Logger object, probably mis/overuse of OOP, only one instance of Log is created and used across the entire code base

Another old question with similar topics (though not exactly a duplicate), with pointers : workplace.stackexchange.com/questions/58874/…

Some of us LOVE this scenario, so long as we have a free hand to clean things up along the way.

"a bad code base with not so good support from the original creators" is what I feel when revisiting my old projects.

@python_user Remember that the end user is the one who pays the bills. It MUST WORK for the end user. Making anything easy or working for you is only to reduce the cost to have you fix something, but only if the reduction in cost is greater than any lost revenue.

@DawoodibnKareem Don't forget people who started rewriting parts but then had to stop halfway because something more urgent came up. Or people who rewrote it to be "beautiful code" and then re-discovered all the edge cases (that were already handled by the old code) and had to go back and add in all those little details....

"but having to add e.__traceback__.tb_lineno to every single block is a hassle". Don't WET yourself when trying to improve the code. Give e to Log and get Log to deal with the problem. You could have a global debug flag to print e.__traceback__.tb_lineno only when debugging, or however you think is best to handle the error.

Should you quit? Of course not… what in your exposition came close to justifying quitting? Taking over a bad code base with not so good support from the original creators matters only if your management refuses to acknowledge it. Is that what's happening, or not?

A lot of outsourcing techs uglify code to meet their deadlines. Multiply your ETAs with a factor of 3+

My manager did agree on letting me re write the code but only after I complete my current backlog your backlog will never be empty. Make small improvements when and where you can as you work on the backlog. That is the only way.

@RobbieGoodwin they do now, they didnt really realize the state of the code base until I pointed it out

Being able to do this is why you can make a living out of it. Leave it better than you found it.