Also worth mentioning that universities generally see themselves as research facilities first and foremost. They teach students, because they want to get the next generation of researchers.

Sure, they’ll also do job training to some degree, because it’s a good argument to get more funding, but yeah, just not their primary goal.

Well, Bethesda isn’t actually involved in that, so it’ll be of much higher quality either way…

I did find it quite weird that the most powerful stage for Digimon was often just a man. Always felt like the, uh, cartoonist(?) had a bit of a superiority complex. Like, what’s more powerful than an iron t-rex? An iron man, of course.

Although, thinking now, there was something about them merging with their humans. Was that just what that last stage is? Then I guess, I would allow it as some dramatic thingamabob.

You’re right that there is a risk, that rebasing introduces compile errors or even subtle breakages. The thing is, version control works best, if you keep the number of different versions to a minimum. That means merging back as soon as possible. And rebases simultaneously help with that, but also definitely work best when doing that.

There may be reasons why you cannot merge back quickly, typically organizational reasons why your devs can’t establish close-knit communication to avoid conflicts that way, or just not enough automation in testing. In that case, merges may be the right choice.
But I will always encourage folks to merge back as soon as possible, and if you can bring down the lifetime of feature branches (or ideally eliminate them entirely), then rebases are unlikely to introduces unintended changes and speed you up quite a bit.

I don’t work with merges, so maybe I’m way off base, but I thought they meant, they’re working on another branch or fork, then merging the base branch into theirs every so often to get the newest changes, and then that creates multiple merge commits, which they can’t squash at the end…?

I’m not sure, about that last part, but the rest, I’ve definitely seen with contributors that didn’t know to work with rebases (and unfortunately we’re on GitHub, which only half-assedly supports working with rebases by default).

Hmm, well, thanks for throwing that tidbit in either way. I’m certainly not deep into that whole artform, so probably just saw big eyes + cat ears and that was the end of my thought process. 🫠

You might prefer working with rebases + fast-forward-only merges, if you want merge commits to be squashed…

(As in, there won’t be any merge commits. Your PR will look as if you forked, then coded real fast, and then opened the PR before anyone else pushed anything.)

Yeah, the big thing is that management has no sense how little coding you actually do in a software engineering role. You spend so much more time understanding requirements, understanding how you can resolve roadblocks within your organization and understanding what the hell the code does that was previously written.

In particular, the last part is something that will most definitely take longer for vibecoded programs.
The code is often needlessly complex, because:

• folks throw in additional features with no restraint,
• the AI will gladly generate a second implementation for stuff, you already solved in the codebase, and
• AI-generated code tends to just be noisy, because you need rigorous logical reasoning to find the most minimal solution.

But you also just don’t have human beings that made all the detail decisions and can tell you why they’re important. In vibecoded code, all of these detail decisions are accidental and only ‘proven’ in so far as the given accidental state that the code is in, happens to not explode in reality. If you need to tweak anything about it, you’re completely blind as to what’s actually important and what’s just in there, because the AI figured, it’s the most likely thing to autocomplete there.

News article: https://en.rua.gr/2024/12/03/loud-arrest-in-moscow-a-robot-drug-courier-fell-into-the-hands-of-law-enforcement-officers/

It’s just a silly anime girl showing up on first page load. If you’re deathly afraid of seeming unprofessional, that’s gonna do your head in…

I mean, even then, they could increase the price per token, if they want to hand out fewer tokens for the price paid.

They could make this work like a prepaid SIM card, where you charge it with e.g. $10 and then you can use it until the $10 are used up.
Instead, they make it work like in-game currencies in scammy free-to-play games. Except that they didn’t choose a confusing conversion rate, for some reason…

Yeah, I imagine that they did try. But it’s not just the intentionally misleading announcement post, they also have 5(?) different subscription tiers, which get different changes from this. And one of the subscription tiers is actually called “Pro+”, so that does not mean “Pro and more expensive tiers” like I wondered. And they have this ridiculous intermediate currency to make things even more confusing.

Their offering itself is overly complex and confusing…

Man, they couldn’t have communicated this more confusingly, if they tried.

Which is a crime, by the way, when you sell it together with a product you hold a monopoly for: https://en.wikipedia.org/wiki/Tying_(commerce)

So, did they use AI tools to type “LGTM” 400 times or nah?

But yeah, I also find that frustrating. Management just looks at terrible metrics like PRs closed or lines of code produced.
It’s not even novel that you can produce terrible code very quickly. Decades ago, our industry learned that it isn’t worth it, because you suffer for it later. Now the game is altered slightly and management demands that we throw all these learnings out the window.

Well, base prices stay the same. They seem to just be billing more per usage on top of that…

Personally, I found it worth playing around with. I cared less than I thought where I had to move my eyeballs to, once I didn’t have to make the decision anymore.

And automatic tiling can also enable workflows that just don’t make sense with manual tiling, for example master-stack-layout where basically one window takes up half the screen and the other windows share the other half, and then you swap out which one’s the big window as you see fit.

But I also wouldn’t have written all that, if I didn’t have a way that you can easily try it out: You can add automatic tiling into KDE Plasma via Kwinscripts. Personally, I’m using Krohnkite: https://store.kde.org/p/2144146
(Easiest to install by going through the System Settings…)

Retirement is more of a synchronized event, because folks generally retire around the same age…

If there’s no reason to hold the feature code back (i.e. its integration doesn’t break anything), then it’s much easier for development to ship the feature and disable it with a feature flag. Otherwise, you have two versions of the code, which means changes need to be integrated in both versions, which is largely just pointless busywork.