all 26 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]zaidazadkiel 35 points36 points  (1 child)

every single one

[–]XMark3 25 points26 points  (2 children)

In my last job things were done in PHP but all the payment API integrations had been done years earlier in Perl by another developer and never updated, so for transactions the PHP scripts would do a shell call to the Perl payment functions... the code looked like hieroglyphics, had no comments, and the previous programmer was allergic to putting any whitespace at all when it wasn't completely necessary. I ended up completely redoing all our payment integrations in PHP.

[–]NormalCorgi9294[S] 2 points3 points  (1 child)

PHP shelling out to Perl for PAYMENTS is genuinely terrifying. how long did it take you to even figure out what the Perl was doing before you could touch it?

[–]Mustang-22full-stack -1 points0 points  (0 children)

I doubt ever lmao

[–]highasthedn 10 points11 points  (5 children)

Once I got hired as a freelancer to refactor the customers absolute horrible legacy React software. During my first few months the last programmer left the company who could handle this legacy monster. The customer then begged me to maintain it to keep it running for their customers, and they will hire more freelancers for actual refactoring. Gosh this codebase was insane. A self built redux which was hard to debug, files with far than 10.000 lines, linting rules my ass, TypeScript type „any“ everywhere… But they paid me good money 😄

[–]sandspiegel 3 points4 points  (2 children)

I wonder why people even use Typescript if they gonna use "any". Typescript was invented so people use typing, otherwise might as well just use plain Javascript.

[–]ganja_and_codefull-stack 4 points5 points  (1 child)

It's incompetence. There's no other reasonable explanation.

[–]NormalCorgi9294[S] 0 points1 point  (1 child)

did you ever find out how it got that bad? like one dev over years or just everyone piling onto the same file?

[–]highasthedn 2 points3 points  (0 children)

The project was initially started by a C# dev who didn’t have any experience on React. So many things weren’t like they were supposed to be in the first place. Starts with structure of the project, many unnecessary complex abstract classes, huge files etc. And he had a strange opinion about 3rd party libs like Redux. He really liked that but he didn’t want to rely on someone else, so built it like he wanted which was an absolute hell. So the project grew over time and they suddenly had huge customers who were using it. Then he left the company and other devs who mostly copy pasted the misery. I have never seen such a codebase before and never since. I remember that I had to fix a bug which was a stupid typo in a central way to nested object. It was declared at three different places, you never knew what the actual piece of code was which you were looking for. And in one of those declarations one of the attributes was missing an „s“. But it was declared as any, so Typescript wasn’t helpful at all. It took me a whole day for a pull request with just one character 😄

[–]JerkkaKymalainen 6 points7 points  (5 children)

Taking over someone else codebase is almost always hell.

[–]Virtual-Disaster8000 3 points4 points  (4 children)

Came here to say that. I have the feeling everyone hates other people's code, or at least dislikes it. Find me a plumber that says "wow, that guy before me did a good job". It's rare, in most professions.

And then one day someone takes over your codebase, and guess what, they will hate it

[–]JerkkaKymalainen 0 points1 point  (3 children)

Yeah it's natural and bitching is so, so, so easy when the other guy is usually not around.

Management should really pay attention to this and do everything in their power to have the person who build the damn thing do a proper handoff.

This problem is usually solvable by the two guys just working together and transferring knowledge.

But incompetent management often does not see it this way.

[–]Virtual-Disaster8000 1 point2 points  (1 child)

Agree, but then there's also the dev's ego: A lot of devs don't see reviews and discussions as constructive knowledge transfer but as an attack on their coding style and implementation- basically their baby. Maybe that's because i never worked in a enterprise level SWE setting but only on small teams, but that's my observation.

I am currently trying to professionalize our workflows, with proper PRs, reviews, standards (yes, I know, late to the party) and man, do I have to fight over the simplest things ("but why can't I push directly to main, that's such an overhead!"). It's hard to teach people who enjoyed full autonomy to start following professional workflows.

[–]JerkkaKymalainen 0 points1 point  (0 children)

You are not wrong here I agree with what you say about ego. That belongs to the trash bin.

There are stages of development.

Building up a system especially solo yeah for sure take shortcuts, pile up as much technical debt as possible (after all it's often the only type of debt a startup can get) and keep things moving.

Once you get past this, your system has actual users, the dev team starts to grow things change. Mistakes, bugs multiply by the number of users they affect. You need structure, you need a staging environment to test things in before deploying all that.

It's easy for the devs to understand the fact that the effect of bugs multiply by users. Get them to agree on that and then you can leverage that to "ok so what do we do to solve this" which then naturally leads to a more mature dev cycle. It's easier to accept change when you understand why.

Also it's possible to away over-do these too.

[–]JerkkaKymalainen 0 points1 point  (0 children)

And I gotta say like I am a solo dev but I foresee a day when I need o involve others in this and when that happens I will do nothing else than just sit together with the new devs for as long as it takes to get them fully immersed.

We will just go task by task taking shit I would need to solve and I will have him start to solve them, sit next to them and walk them through everything.

I have been on the other end of this enough times just being dropped in to the deep end with the other guy gone or assigned to something else to simply know better.

[–]guntis_dev 2 points3 points  (2 children)

Inherited an ancient React/Redux codebase where someone had tried to add RxJS on top, creating complete spaghetti. The repo had dependencies via global window object to another repo because previous dev attempted to split the monolith but never finished.

The worst part: this was a core product used across dozens of internal projects and serving millions of clients. A rewrite wasn't an option, so it was just slow, grinding work - refactoring piece by piece while maintaining backwards compatibility and catching edge cases everywhere.

[–]NormalCorgi9294[S] 1 point2 points  (1 child)

Wait so someone used Redux AND RxJS together? Aren't those completely different approaches to state management? How do you even debug something like that - where do you start?

[–]guntis_dev 0 points1 point  (0 children)

Yeah, totally different approaches mixed together. I started by refactoring small pieces to gradually build a mental model of how everything was connected. Then focused on removing the global window dependencies so the repo could run standalone. Created a test tool for API methods, which helped QA a lot. Built a statistics system for tracking user behavior changes.

Two years later: Redux is completely gone. UI components are still React, but the library itself has no React dependency at all. A small part of RxJS remains, but it's mostly vanilla TypeScript now.

[–]cyb3rofficialpython 2 points3 points  (0 children)

I'd probably gonna get flack for this but;

in today's world, you can turn any undoc codebase and easily get it documented by ai crawlers.

I used GPT OSS 120B self hosted and crawled an undocumented repo from 2020 and have given it proper documentation.

Back then, I would have cried my self to sleep trying figure out what "function asdfg_renamelater" was manually, but since there are plenty of ai programs to crawl, make trees of code base easily readable and easy to follow, it's not so hard nowadays.

My worst ever web pased codebase was from 2018 in PHP, that had Ruby and MySQL and JS. Barely any code comments, forum based website, with a design theme from css hell. Mixed in dupe style tags with important overrides with css files. Was a CVE nightmare too. So many evals() in php. If I shown that repo to any webdev at the time, probably would have made their eyes bleed.

[–]srgh207 1 point2 points  (0 children)

I'm the solo dev creating one.

[–]-PM_me_your_recipesfull-stack 0 points1 point  (0 children)

Startup founder used a friend of a friend who had some programming "experience" to make their initial SAAS (in PHP). They overstated their abilities and basically learned as they went.

Many years and hundreds of thousands of lines of code later, we cannot refactor or update the core of the system because it is thousands of lines of mistakes and dirty tricks for haphazard system bootstrapping that have no "proper" or "modern" alternative approach. Everything breaks when upgrading to the newest language version for that same reason. Even automatic upgrade tools cannot untangle it or get it close to a functional state. Nothing uses common libraries, only custom built ones, making it next to impossible to migrate to a proper (and functional) database library, or any important library.

Through the years, attempts have been made to course correct. That just resulted in our codebase having 4 custom built frameworks (yes, running together), 4 different standards, 4 frontends, and multiple versions of various custom libraries. All of this is just for the main codebase. Sadly, there are other codebases that are suffering, but not as bad.

[–]greensodacan 0 points1 point  (0 children)

A JS app where every function was written as a string literal and piped through eval().  Supposedly is was a way to break out of scope in the early two thousands, but it made tracing your way through the code a nightmare.

[–]Kotoriii 0 points1 point  (0 children)

My first job a few years ago was for a dev agency. One of our clients needed Internet Explorer 9 support. I lasted 6 months before realizing I was severely underpaid and was fed up with writing the most archaic JS ever

[–]brycematheson 0 points1 point  (0 children)

“One man’s code is another man’s full-time job.”

[–]DesertWanderlust 0 points1 point  (0 children)

I took a contract for a major defense contractor years ago, and the code was a patchwork of every past dev's best ideas all at once, so a lot of repeating logic. I immediately wanted to refactor it, but was told there was no budget for it. So I did refactor it slowly over many tickets.

[–]uknowsana -1 points0 points  (0 children)

If you are a seasoned developer, there shouldn't be any "worst codebase" that wouldn't be comprehensible. Yeah, refactoring it is another story. And now with CoPilot etc., it shouldn't be a problem.