![](/static/66c60d9f/assets/icons/icon-96x96.png)
![](https://programming.dev/pictrs/image/170721ad-9010-470f-a4a4-ead95f51f13b.png)
Never touched it? A website? What about updating frameworks for security issues?
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 :
If a TODO passes code review, more than one person fucked up.
You should assume that any consumption, if not proven otherwise, is not cruelty free and environmentally friendly. The most moral thing to do is to consume less, I guess.
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.
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.
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.
Ecosystems there won’t necessarily fare all too well. Trees are drying up because they aren’t used to that dryness/heat. New trees will take time to grow and they don’t necessarily support the same species.
The mix of species you used to have that lived in a balanced way is being disturbed by various invasive species.
I’m not saying those ecosystems will necessarily collapse, but there is a nonzero risk that they might.
“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.