It convinces people it improves their performance. It doesn't in reality: https://secondthoughts.ai/p/ai-coding-slowdown.

I was born in 1990. Fully a '90s kid.

Atlanta is pretty incredible.

While that's true, it doesn't make it right. All representation should be proportionate.

No, there are many different kinds of stocks with different terms. Stocks are an asset with value, regardless of whether or not dividends are paid out. It's very commonly the case for shares to be issued with no dividends paid because profits are reinvested back into the company with the goal of increasing the share price for some future massive liquidation event (like an acquisition).

Shares also represent ownership in a company and thus their value is also in the leverage it can give potentially give you in said company.

It's a toss up, for me. Both managed to capture all discussion on major open source projects.

It's speed, but it's also flow and a continuous stream of thought. If all your editing is being done with muscle memory and minimal thought, you can continue thinking about the problem at hand rather than interrupting your thoughts process to fumble through some context menu to make a change.

Yeah it is something people should take time to learn. I do think its "dangers" are pretty overstated, though, especially if you always do git rebase --interactive, since if anything goes wrong, you can easily get out with git rebase --abort.

In general there's a pretty weird fear that you can fuck up git to the point at which you can't recover. Basically the only time that's really actually true is if you somehow lose uncommitted work in your working tree. But if you've actually committed everything (and you should always commit everything before trying any destructive operations), you can pretty much always get back to where you were. Commits are never actually lost.

This a really bad take and fundamentally misunderstands rebasing.

First off, developers should never be committing to the same branch. Each developer maintains their own branch. Work that needs to be tested together before merging to master belongs on a dedicated integration branch that each developer merges their respective features branches into. This is pretty standard stuff.

You don't use rebasing on shared branches, and no one arguing for rebasing is suggesting you do that. The only exception might be perhaps a dedicated release manager preparing a release or a merge of a long-running shared branch. But that is the kind of thing that's communicated and coordinated.

Rebasing is for a single developer working on a feature branch to produce a clean history of their own changes. Rebasing in this fashion doesn't touch any commits other than the author's. The purpose is to craft a high quality history that walks a reader through a proposed sequence of logical, coherent changes.

Contrary to your claim, a clean history is incredibly valuable. There's many tools in git that benefit significantly from clean, well-organizes commits. git bisect, git cherry-pick... Pretty much any command that wants to pluck commits from history for some reason. Or even stuff like git log -L or git blame are far more useful when the commit referenced is not some giant amalgamation of changes from all over the place.

When working on a feature branch, if you're merging upstream into your branch, you're littering your history with pointless, noisy commits and making your MR harder to review, in addition to making your project's history harder to understand and navigate.

Yes. Everyone should have autonomy over their own bodies, especially when it's a matter of something as major as pregnancy. Pregnancy is a medical condition, and the only person that should (legally) have any input in medical decision making for pregnancy is the person that's pregnant.

Yeah, sounds like they may not have been very comfortable with the tools. Which is fine, but nothing has really changed.

Yeah, this penny pinching on licenses is pretty absurd. I promise you that it hardly affects the bottom line.