SpookyMulder

I have been using this as my daily driver on my Android phone for the past year or so because there is no LibreWolf for Android. No complaints.

What is the goal, exactly, and what is your threat/trust model?

"I'm not a [king]. I earned everything I got."

Clickbait title, but decent journalism.

That flouride quote is from one of the 5,000 rando attendees in one meeting. It was not uttered by who you're supposed to think said it.

Not that it matters, because it might as well have been said by Oz or RFK Jr or Orange Julius.

"13 interviews with 11 different people for one job at one company and ultimately they went with another candidate"

That about sums up the best case scenario in this market. This report is grim, and doesn't even begin to scratch the surface of all the other red flags and warning signs.

I have 20+ years experience in one of the most in demand jobs and in one of the hottest markets, who ticks all the boxes in all the qualifications for each of the hundreds of jobs I have applied for, who lives in one of the top regions for the industry, and (I have to at least acknowledge) whose demographic traits are the very stereotype of privilege... yet even I haven't gotten so much as a callback in six months.

Economic uncertainty is one reason the job market is dead. The surge of both automated candidate screening bots and in automated job application spam bots creates artificial competition for jobs, compounding the real competition from sustained and accelerating unemployment rates. The widespread availability and use of LLMs has been devastating for resumes, cover letters and portfolios in particular, which are intrinsically conventional and derivative of the job posting to which they are attached, and thus optimal for LLMs to produce.

So on top of the general economic reasons and the supply/demand issues resulting from rapidly accelerating unemployment, LLMs have irrevocably and single-handedly destroyed what was left of traditional job seeking procedure, wisdom, and etiquette.

FYI: CUPS was recently outed as extremely insecure and irrevocably broken by design. So if you're not actively printing, it's probably best to uninstall it.

• Solve the problem directly in front of you. You are not as good at predicting the future as you think you are. (aka: YAGNI)

• Organize your code around the problem domain, and name things accordingly. As a basic razor, consider someone seeing your codebase for the first time -- they should be able to easily glean what your app does, not just what language (Java) or frameworks (Rails) or design patterns (MVC) you might be using.

• Each function must Do One Thing. And yes, each test case is a unit, too.

• It must be clear to someone reading a function call what is expected to happen. Only use positional arguments when this is true and when order matters and is reasonably intuitive. Otherwise, always use named arguments.

• Your tests must run quickly. Your code must build quickly. Your CI/CD pipelines must be measured in seconds, not minutes or hours.

• Take nothing for granted. Declare all dependencies, and avoid implicit globals.

• Use a linter, and enforce compliance. It doesn't matter what the rules are, but once established, avoid changing them.

• Never isolate yourself from your team for too long. If you're working on a multi-day implementation, check in with the people who would be reviewing your code at least every couple of days. The longer you isolate, the more exhaustion and conflict you can expect during review, for both you and your reviewers.

• Learn to work iteratively, validating minimal implementations that fall short of the full feature as requested, but which build up to it. As opposed to One Big Release. It helps everyone to experience and validate early and often how the feature feels and whether it's the right direction.

• Never rush. Always take the time to build properly. Your professionalism and expert opinion is non-negotiable, even if (especially if) there's a deadline. I'm not saying to say "no" -- rather, just give honest estimates and offer functional compromises or alternatives when possible. Never "try" to do more than is reasonable.

A lot of this, I attribute to Martin's books ("Clean Code" and "The Clean Coder") and his Laracon talk from several years ago (you can find it on YouTube).

I have found that it often takes a very long time for Tor to build a circuit (bootstrap) using obfs4, because of what seems to be difficulty finding bridges.

It's about time! That's good news for other rare, overpriced DVDs of popular movies and shows. The secondary market for Dogma was (is?) wild.

Every now and then this question comes up. It's a timeless software engineering conundrum. Kind of like how med students might start to think they have all kinds of diseases and conditions because they're learning all these symptoms.

Software engineers, especially new ones, tend to be heavily biased toward applying technical solutions to non-technical problems. Most never actually grow out of this.

I'll advise what I advise every time someone approaches me or one of my peer groups with this very question:

Get yourself a notebook and a pen.

I'm dead serious, not trolling, and not some kind of technophobe zealot.

When it comes down to it, if you let go of what you think you need in a to-do list app, you'll find that what you actually need is much simpler.

Notebooks are e2e encrypted. Self hosted. Offline. As ephemeral as you like. Indexable for search. Versatile. Take a picture of a page if you really want to. OCR it if you need to.

Pen and paper.

Tor comes packaged with torify which you can prefix any CLI command with to have it route through Tor and resolve onion sites properly.

No, you're not looking to understand. You're looking to persuade.