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

We need a new paradigm for social media. And no, I’m not satisfied with Lemmy either (privacy 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 :

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

Which distro?

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.

I was under the impression that even in other countries, activism is generally separate from the political parties and it’s more like activist groups putting pressure on candidates and organizing for them if they are more favorable, and sometimes getting something in return.

I’ve seen exceptions, but I gather they are rare (and we can already see some change as the party is under pressure to become more “normal” and “competitive”).

Don’t tempt the fates. You will get this, but everything else will be worse.

Trust me. Don’t temp the fates.

deleted by creator

Those are really stupid managers.

If you don’t have docs it’s a tough competition between having your more knowledgeable devs re-explaining what they know X times to X new hires, or letting new devs figure it out on their own which is both costly in terms of their time and more importantly, risky as hell.

Bad managers love risk though. Since it usually is a choice between speed now and risk later, it only blows up in your face later, and quite spectacularly, and everyone looks like heroes while they are putting fires out on overtime.

That said good managers probably don’t tolerate that shit from bad managers under them and can sniff out a firefighter culture pretty quick.

I guess what I meant to say was, managers that value doc do exist. If they really do, they’ll let you know.

That is different than for layoffs, which generally is less about rooting out toxic people and more about lowering costs. And people know it usually.

That said, anyone causing trouble for management or viewed as not pulling their weight will be the first on the list since management won’t have to justify firing them.

Expect this from corporate and political types alike.

Takes time to become ubiquitous.

Yes. They will start doing so when it is too late for that to help.

You’d think the republicans, their voters, their donors, and the whole media apparatus behind it, would get some of the blame too. I know, they’ll see it as glory rather than blame. The dems didn’t do it, they were just lame.

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.

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.