The irony! My router died literally an hour ago, and I was on bestbuy to buy a new one. Over 5g connection. That was probably the worst shopping experience I had in a while...

Seriously! I have too many years of software development experience, but I use Visual Studio UX to handle pretty much all git operations. And always merge.

I have better things to do in my life than "internalizing" anything that doesn't matter in the grand scheme of things.

I don’t like that approach, because people who work like that commit all kind of crap to repo or cry that GIT ate their homework…

Then we have line ending conflicts, file format conflict UTF8-BOM mixes with just UTF8 it makes more work for everyone like crappy PRs. Because of people for who those are things that „don’t matter in grand scheme of things”.

I happen to know a lot about git internals, but I don't think everyone should need to.

About the line ending conflicts: set up your CI once to complain about those. And help your coworkers set up their editors right once.

If it hurts, do it more often.

Rebase is easy and not terrifying. Here's a 1k word article on how to do it correctly.

Or just do a merge and move on with your life.

If you want to have a linear history on main, either always rebase your branch onto main, or merge but only accept squashed commits onto main.

I would prefer to have accurate history over linear "history".

Good luck bisecting.

With --first-parent, I don't need good luck in my bisecting.

It's funny because I learned git on the job and we exclusively used rebase when I was learning my git fundamentals. I wouldn't say merging scares be, but it's never a tool a reach for.

> Here's a 1k word article

lol if 1k words is "not easy" for you, i think you have bigger problems than merge vs rebase.

"Once those additional vaccines are off the "routine" schedule, they'll be pulled by the suppliers, because it eliminates exemption from lawsuits"

Why is this bad? From one of the threads - "There IS scrutiny on vaccines, by the scientific and medical community - your "scrutiny" (as presumably neither a PhD in a relevant field or MD) is not valuable or relevant. There is decades of research that says that currently recommended vaccines are safe and effective."

OK, then there won't be grounds for lawsuits or lawsuits will be easily dismissed.

"you can be sure there'll be a bunch of crackpot right-wingers trying to prove each one is "bad" and they'll disappear sooner or later" - This logic can be applied to literally any product, be it a medicine, a vaccine, or any consumer good. Somehow pharma companies are able to sell any other drug without going into bankruptcy.

Cerebral palsy, a naturally occuring disorder, generates $10M in "malpractice" payouts, part of why giving birth in USA is so expensive.

It is true. Withdrawals from SSRIs are no joke and can take a long time.

"But accepting the full S3Client here ties UploadReport to an interface that’s too broad. A fake must implement all the methods just to satisfy it."

In NET, one would simply mock one or two methods required by the implementation under the test. If I'm using Moq, then one would set it up in strict mode, to avoid surprises if unit under test starts calling something it didn't before.

That's exactly it. What happens in a private branch is an implementation detail and reflects personal work style. Policing that is counterproductive.

No one said anything about "policing" anything. I'm not telling anyone how to write PRs, I'm just suggesting that if we had better tools we'd get "better" PRs for values of "what happens in this 'private' branch is more than an implementation 'detail' but a useful story and a useful documentation of the process". You don't need to agree that is "objectively" or "universally" a "better" way to make PRs for everyone and every project, but I'd hope you could at least respect that it's a nice goal that some of us have at least some of the time and why we would like PR tools that respect that approach as much as they seem to already respect your "no one cares how the sausage is made" approach.

"Forward Deployed Engineer" is a bodyshop with LLM.

Weell, you probably don't want to serve "Backwards Deployed Engineers" to your clients

Pretty sure this title came from Palentir who got it from the military.

"Forward Deployed Software Engineer - This role includes working in locations that include risks of getting shot and possibly killed"

One-shot, one-kill.

They could just call it "Field Service Tech" like the rest of the universe. I understand using title inflation/deflation to keep pushing the engineer title (and pay expectation) into the dirt, but still, this is dumb.

I also dislike the term. It feels concocted to evoke “tacticool” vibes.

Unless you’re pushing new firmware onto a drone in Ukraine, FDE is stolen valor.

Might I interest you in "In the trenches" and "war stories"?

Ehh, I don’t think folks are claiming to be active duty or former military personnel, which is the bar for stolen valor accusations in my book. I agree with the sentiment but not with the determination of finding fault. Folks hired for a specific role rarely pick their own job titles.

Standard out-of-the-box Windows behavior: quick Alt-Tab press switches between last two windows; pinned apps on taskbar are switched with Win-1..9 shortcuts.

You actually don't need to. Just upload this little php script to a shared host for $1/mo and call it a day.