Just to point out, with the median mortgage at $2349 a month, it's more like you need a household income of $93,000 a year (probably closer to $100k with utilities and other expenses) for your housing costs to equal 30% of your income. That is steep for a lot of people, but still much more attainable than 7 figures. A quick Google says that makes up around 37% of US households as of 2022. Still doesn't quite add up to their figures, admittedly, unless "nearly half" is doing a lot of work in that sentence.

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.

That's certainly what we do in my workplace. Shocked that they don't.

It's actually hot sauce specifically that has a tendency towards intentionally weird names. Don't know how it started exactly, but at this point it's a pretty common marketing gimmick.

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.

My pixel 7 pro is perfectly smooth and seamless. Oh and voice assistant is far faster than anything on iPhone thanks to the on-board Tensor chip.

In my experience all terms are used pretty interchangeably (well, rarely programmer or coder, I guess), though I prefer software engineer.

HIPPA is no joke and companies actually don't fuck around with it. It's not worth it. It's one of the few pieces of consumer protection out there that has real teeth. Under HIPPA, you are expressly forbidden from using personal health information for anything unrelated to that patient's care, and companies can and are fined heavily for violating it.

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

Because you never learned SQL properly, from the sound of it.

Also, ORMs produce trash queries and are never expressive enough.