“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.

My personal hate is the word “settler”, which invokes an image of somebody taking previously useless land and making it fit for human habitation, but apparently has been redefined within the borders of Palestine to mean “armed invader”.

North American Natives probably resent that sentence…

It is very rare for no humans to make use of land at all. Whenever someone “settles” it, they are taking it away from someone else. Usually force gets involved at some point, even for nomadic tribes. It’s why colonialism has a bad rep these days.

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.

Yeah, firefighter mentalities are terrible.

That said, as someone in software development, wouldn’t there be some optimization work you could do? Keeping up with the technology? Preparing training material? Figuring out the next steps for the next improvements to be done to the system? Looking at solutions to better monitor what is going on? Scripts to automate tasks?

I find it hard to believe that things are so static.

the problem is you can’t easily go get another job because all the other jobs require a stupid amount of qualifications that don’t really relate to what they are offering in anyway shape or form.

Job postings are a wishlist for an ideal candidate. Only some of the stuff is actually required, For the rest, it varies based on how scarce people able and willing to work in that field are.

To see through the fog, you have to try reaching out. Either apply at places or try to build yourself a network. Sadly I’m not great at it myself. Alternatively, if you have the time and inclination to learn new skills, that’s a thing you can do.

I think this depends on the crowd. Unfortunately, the intelligent crowd and the crowd with money and power is not exactly the same. Though hopefully there is overlap.

I think this points to a large problem in our society is how we train and pick our managers. Oh wait we don’t. They pick us.

If a TODO passes code review, more than one person fucked up.

1. Those apps are simple
2. Those apps target a wide audience, hence have more budget as a result
3. Those apps are made by large, well oiled (you’d hope at least) companies. You don’t want my honest opinion on most small software development boxes. This industry grew faster than mentors became available for the newbies, so many devs including seniors still don’t know what they are doing.

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.

It works like that in French until you use a different word for the machine.

“Mon ordinateur est une bonne machine”. In a single sentence my computer was described with words both male and female.

It’s just vocabulary and grammar, not the deep essence or identity of things or people.

Generally, you can replace some comments with variable names or comment names. Which means you must already be in the habbit of extracting methods, setting new variables to use appropriate names, and limit context to reduce the name (Smaller classes and methods means shorter names can be just as expressive, because the context is clearer). It lowers the number of wtfs per minute you get reading code before you even need whole sentences to explain why things are done in a certain way, because the names can be a powerful hint.

But realistically, you end up needing comments for some things anyways.

Except that instead of an authoritarian government using it to totally control the learned populace, they are showing you ads.

We’ve still got a way to go before 1984. If it did happen, you wouldn’t be able to discuss it.

It has a rocky start, and a lot of cruft from that era sticked around.

There are also a lot of horrible legacy projects from the pre-ES5 era which are a pain to work with. Often older projects were coded either before people knew how to do javascript right, or before the devs who wrote it knew how to write javascript right.