Other than others have pointed out:

• clinging to arcane tech
• having reinvented the wheel
• taken things out of context

Inheriting old code from someone else might result in some learning curve about how the other programmers' coding practices, their thinking and approach to solving a particular problem.

While putting comments inside codes help in understand the context of a particular scope of a code, it might not help you in understand the whole logic associated with a block of code.

For eg, using variables like i or j in loops in quite obvious and many people use that. But if you use those variables in a loop which has a lot of business logic associated with it, other developers become confused when they visit that block later on. Whereas, if you put self-explanatory variables, it becomes very helpful for the other developers also.

While in an ideal case, there shouldn't be any spaghetti code, in real life, in some portion of your app, you might have to use spaghetti code. It's always better to document them in a separate doc or in any other place as well as put comments on them.

In some cases, there is a mix of concern also. Say, to solve the same problem, in some places, some library (like Lodash) is used. Whereas, in some other place, to solve the same problem, Vanilla JS (or Underscore) has been used. It becomes very difficult for the other developers to work with this code and also, this type of code is very prone to errors.

N.B.

I understand that the question was something different. It didn't ask for reasons but I wanted to post them anyways in the hope that someone might be benefitted! :)

I see this like walking into a room where there is an unbuilt puzzle on a table and I am introduced to the process at a later stage:

I don't like when I am busy with an area and then find that the puzzle pieces for that area are literally missing. Like for example: if a library has been introduced, and I am expected to enhance the area 'quickfix' using THAT library and am given a set period of time. So turns out the library has been discontinued...

The problem is not re-doing the area, or finding another library that does the same thing. The problem in this case would be time, I suppose

Some of the most annoying stuff are:

• Gigantic poorly named methods that don't really reveal what's going on. Methods should be small and named in a way to describe what's happening, like an explanation of what's going on.
• Code from different features in the same place. It slows me down having to deal with code from feature A when I'm fixing feature B. Avoid this.
• Code from one feature in different places. This is probably the most annoying. Having to chase the code from one feature along multiple files and directories can stress me out really bad. People tend to make that mistake in the name of DRY (don't repeat yourself), but completely forget KISS (keep it simple, stupid) in the process. In my experience, KISS is waaaaaaaay more important than DRY.

More than anything, poor formatting. For example:

for(var x=0;x<somevar.length;x++) {



    if(x<123){console.log('why are there no spaces here, but a bunch of lines above?')}
console.log(somevar[x]);
       }

Dealing with the mess code, comments useless, bad naming of variables, methods classes and more, a lot of functionality for one class instead of separate behaviour.