And for my area it is very high. I live in a cheap midwest town and according to this, the difference between here and San Francisco is only 30k a year.
You do realize that it's possible to ask AI to write code and then read the code yourself to ensure it's valid, right? I usually try to strip the pointless comments, but it's not the end of the world if people leave them in.
Vibe-coding as originally defined (by Karpathy?) implied not reading the code at all, just trying it and pasting back any error codes; repeat ad infinitum until it works or you give up.
Now the term has evolved into "using AI in coding" (usually with a hint of non rigor/casualness), but that's not what it originally meant.
AI assisted coding/engineering becomes "vibe coding" when you decide to abdicate any understanding of what you are building, instead focusing only on the outcome
That's literally the opposite of what this documentation is explaining. System containers exist. You can run the entire userspace of an OS (including systemd) in a container.
If it actually is stronger than a simple request, I could see saying "an ask" as a way of demanding using softer language. If your boss were to say "I demand ...", everybody is going to say they're a demanding jerk, but if they come to you with "an ask", that could carry the weight of the demand without sounding...demanding.
That said, I've never considered "an ask" to have any stronger meaning than a request. If I hear "an ask", I'm assuming I can push back the same amount I would to any other request.
How is a "PR comments" commit useful to you? If I'm looking at history, it's usually to see:
1. What caused a bug
2. Context around a feature and why it was written a certain way
Seeing a "PR comments" commit just turns into noise. It also makes me gather 10 commits together to try to piece back together the unit of work that was built. I just see no value in preserving this type of noise.
That is a perfect example. The "PR comments" commit helps me see what the dev considered most important (code before this commit), and what the rest of the team considered lacking (the content of this commit). Thus, the Git history records a facet of the team culture at the time of the commit.
No, you're making up that story and that culture, and when you lose this spurious foundation, you'll just as easily make up some other story based on any other random data.
For example, reality could've been that there was no team involved at all and all those changes came to the original person the moment he made the PR. And the "PR comments" could just as easily refer to his own comments he added during when checking those CI messages and noticing something else and commenting on that not to forget.
Rewriting history on main is bad. Rewriting history everywhere else is completely normal and should be encouraged. I don't want your "oops typo LOL" commits in main. I don't want a history that looks like "refactor stuff"->"new feature"->"1 line change to that thing I refactored". That one line change should go into the old commit. Fix all of that before you merge to main.
> Honestly, squash merges are frequently a sign of people who lack mastery in Git itself or make no effort to produce high-quality independent commits.
So literally any open source project that accepts external contributions. For this reason we default to squash merge but will allow for exceptions if people ask for it and know how to structure their commits.
reply