“we need more resources” is bounded by the rate at which you can incorporate new teams members without absolutely destroying your productivity, or having a bunch of untrained fools running around breaking things (of course the later is standard at many places already, so I guess it doesn’t always matter).

The right answer is usually : “No”. Or at least “Prioritize”. Or “This is what we need to get it done” at which point they might start to get software takes time to make decently, and they don’t want software that doesn’t work decently in the first place.

Never touched it? A website? What about updating frameworks for security issues?

The closest I got to this kind of job., is the closest I got to running away. I’m much happier elsewhere now.

This, to a point.

Other things help :

• Unit test to help catch regressions. If you are confident in your test catching a good portion of bugs from refactoring, at least you feel confident refactoring. Worst case, at least you ensured your code is testable. There is nothing worse than refactoring untestable code.
• Self-documenting code and when it fails to self-document, comments or refer to a wiki page.

Takes time to become ubiquitous.

Learning to deal with “unmaintanable” codebases is a pretty good skill. It taught me good documentation and refactoring manners. It’s only a problem for you if management does not accept that their velocity has gone down as a result of tech debt pilling up.

Code should scream it’s intent (business-wise) so as to be self-documenting as much as possible As much as possible is not 100%, so add comments when needed. Comments should be assumed to be relevant when written, at best. Git comment should be linked to your work ticket so that we can figure out why the hell you would do that, when looking at the code file itself. I swear some people seem to think we only read them in PRs (we don’t). Overall concepts used everyday, if they need to be reexplained, should probably be written down (at least today’s version). Tests are documentation. Often the only up to date one?

Git wasn’t used all that much in the 2000s. As far as I know it became popular in the 2010s (though it was always a thing in some circles I think) and then just supplanted almost everything else.

Also keep in mind some shops tend to follow larger tech companies (microsoft, etc.) and their product offering. So even new products might not have been on git until MS went in that direction.

This. Especially if your team does not follow SOLID principles (as then someone fixes a bug in a base class method that shouldn’t be shared. This fixes an issue in a subclass but introduces one in another. Rinse, repeat.

Yes and no. I mean sure, if you are going to leverage this to gain a significant edge in the market, that works.

If you add a tool to the project, that you need to understand to maintain some parts of it, which adds to the learning curve of someone joining said team, then the gains have best be worth the effort.

We adopt so many librairies/plugins/tools over time that adding more complexity than you need this way is just terrible.

Yeah, but it’s easy to overuse it. If your for loop is much longer. For a few lines I’d agree, don’t bother using something longer.

Code should scream out it’s intent for the reader to see. It’s why you are doing something that needs to be communicated, not what you are doing. “i”, “counter” or “index” all scream out what you are doing, not why. This is more important than the name being short (but for equal explanations of intent, go with the shorter name). The for loop does that already.

If you can’t do that, be more precise. At the least make it “cardIndex”, or “searchIndex”. It makes it easier to connect the dots.