Slay the Spire and Balatro is kind of the sweet spot for mobile gaming imo

Strength exercise keeps your joints working well long-term

Indeed, wild statement if I ever heard one

It’s mostly a skill issue for services that go down when USE-1 has issues in AWS - if you actually know your shit, then you don’t get these kinds of issues.

Case in point: Netflix runs on AWS and experienced no issues during this thing.

And yes, it’s scary that so many high-profile companies are this bad at the thing they spend all day doing

You prepare for these by doing specific exercises for them, sad as it may seem.

Leetcoding problems? You grind them out for a month or two to prepare for doing them during interview loops.

Mock interviews can help too, to get you better at handling the stress. You can use services/groups for these, or just go interview for random places you’re not necessarily planning to actually say yes to.

Still on the Slay the Spire-train. A downright excellent game.

Also playing some Hades 2

Pick-Up Group

Agreed. If your commits are reasonably structured, rebasing is far more helpful.

Although these days I usually opt for one ball-of-mud commit while developing the code, which is always fairly trivial to rebase - only one commit, can’t have follow-up issues - and then I redo the commit structure from scratch as a part of preparing the code for the benefit of the reviewer.

Use a rebase.

Well, you might be inclined to not roll the feature out at all, depending on the results you see from the rollout/an A/B-test. Also, having it written out with a date in the changelog binds you to that date, unless you want the embarrassment of not shipping on a promised time. Maintaining a changelog for very large app development organizations is also a pretty damn hard task, trying to coordinate whatever all teams are releasing in a particular build.

I agree that getting cute with the changelog messages is a bit stale. Might as well not add anything at that point.

Modern mobile app development almost always releases features gradually behind feature flags, so changelogging things is not necessarily practical to do.

One Rich Asshole Called Larry Ellison

I can recommend switching to reading books. An e-reader with mild backlight is ideal for this use-case as you can keep the room pitch black and still be able to read. My time to fall asleep and rate of early wakeups has plummeted since I made the switch

Dudes trying to assassinate them with cringe

To clarify - Sweden has a lesser variant of the U.S credit score system, but it differs in some important ways. For example, you don’t have to get a credit card to ‘build credit’ - you are assumed to be in good standing unless you have unusual ratios of debt and so on.

Sweden does not have a social credit score system.

This is true. They do not think, because they are next token predictors, not brains.

Having this in mind, you can still harness a few usable properties from them. Nothing like the kind of hype the techbros and VCs imagine, but a few moderately beneficial use-cases exist.

LLMs are fundamentally unsuitable for character counting on account of how they ‘see’ the world - as a sequence of tokens, which can split words in non-intuitive ways.

Regular programs already excel at counting characters in words, and LLMs can be used to generate such programs with ease.

I have zero desire to live like that to be completely honest with you

That kind of commit quality should only really be permissible on private projects, and as a reviewer, it’s arguably acceptable to reject PRs with this kind of history.

You should be writing your commits to the benefit of the code reviewer - structure them in a logical fashion to tell the story about the changes you want to get merged.

For non-trivial branches I usually soft reset to the point where all code is unstaged and uncommitted and then curate the commits to align with what the reviewer should be reading. It’s not uncommon for me to have several branches containing a single “wip”-commit which I amend onto while building up the full code for the branch.

In non-minimal changesets, I would miss information/documentation about individual logical changes that make up the changeset.

It’s usually possible to find this by navigating back to the PR which you can find referenced in the squash commit.

I guess this might be a larger problem for codebases not following a trunk-based approach, where PRs grows to very large sizes before going into the mainline branch.