sodapopcan

I don't disagree, but the fact that it's not required to border on expert, or be willing to put in the work to get there, of a framework or library you are going to be working heavily in a pretty broken thing about our industry. But you know, as people have been posting lately: not AI therefore irrelevant.

This framing sucks. "I'm unhappy with the job I put years into honing my skills for, but since I make decent money I should shut up even when even things are happening that I don't like." And as if "flipping burgers" is the only alternative.

This is a key piece of information you left out of your original post.

At least in web development it really seems to have become widely accepted, at least at many places, that people aren't expected to be anywhere near experts in the tools they use every day.

There is a HUGE difference between framework/library "magic" and business logic "magic." When framework/library "magic" is documented it's awesome, you just need to take the time to learn it.

If you are the only person who ever touches your code, fine, otherwise I despise this attitude and would insta-reject any candidate who said this. In a team setting, "I don't like magic" and "I don't want to learn a framework" means: "I want you to learn my bespoke framework I'm inevitably going to write."

The problem with this is that it means you have to read guides which it seems no one wants to do. It drives me nuts.

But ya, I hate when people say they don't like "magic." It's not magic, it's programming.

I'm not trying to convince you to adopt or anything, but I'm saying you can have all of that without squashing with the caveat that you would need an alias to jump to the merge commit. Otherwise, you just treat merge commits as you would a squash one. Merge commits are just like regular commits that can have a custom message and show a diff.

They aren't noise at all and have found them useful a bunch in the past when I worked at a place that didn't squash. Commits at this level act as immutable comments that don't get out of date. Provided you do --no-fast-forward merges, the merge commit is the feature commit and you can get the "clean" feature history with `git log --merges --first-parent`. Best of both worlds! Being able to `git blame` and get a granular message about why something was done can be really handy, especially when looking unfamiliar code.

`git log --merges --first-parent` gives you both.

I've had separate commits come in handy several times when `git blame`ing when working with people who actually described what changes were about in their commits (which, unlike comments, don't go out of date).

Ya-haw!

So many people are complaining about police brutality, but there are like some really good people on our force! Can't we just focus on them?

Then I can write a "I hate people who hate 'I hate stuff' articles" article!

The internet is only for training data and praising any and all technological progress. If you don't like it, keep it to yourself. Self-expression has no place here!

Physical media is already making a comeback, so let's hope it does with a vengeance and with it, more and more live events.

> Coincidentally, these same people think the most “artistic” process is the most intentional one.

While people do think like this, it misses the point.

Yes, all forms of art is FULL of randomness and people copying each other. The thing that makes it special is that it took people going out and living and having experiences to create it. They have to actively absorb prior art, learn about it, analyze it, generally be influenced by it. You have to seek out paints, clay, musical instruments, etc etc and at least somewhat learn how to use them. It's not about being difficult to do (although it's certainly impressive but not part of the emotional takeaway), but everyone's process is different and their experiences go into what they create. When I see a photograph of a tree, I think: "Someone went to where that tree is!" and that's part of the feeling and excitement of a really artful photo.

Now, someone who has only ever heard the term "free jazz" can sit in their parents' basement and type out "make me a free jazz song" and shit out the result onto the internet. It's really not the same thing at all.

That's only because no one understood agile or XP and they've become a "no one actually does that stuff" joke to many. I have first hand experience with prototyping full features in a day or two and throwing the result away. It comes with the added benefit of getting your hands dirty and being able to make more informed decisions when doing the actual implementation. It has always been possible, just most people didn't want to do it.

This is how I always did it too. When the whole does it every day, juniors don't stay junior for long!

It's exhausting to me too! But when you do it every day you get used to it. You also get a lot more done so last time I did it we would work shorter days.

I find it impossible to use without a plugin. I use https://github.com/mbbill/undotree and map it to `U` since I realized I never use `U` and it's easy to remember. https://github.com/sjl/gundo.vim/ is also popular but I like that the former is in pure vimscript (and the interface is a lil' better IMO).

They are both useful. I'm a frequent committer but find myself using this, I wanna say, 0 - 3 times per month. It's one of those things that when you want it, you're really glad it exists.

I figured that this was what this article was going to be about.

Yes, I am just against code review (except in certain circumstances) and think pair programming (with humans) is much more productive and beneficial.

Ha, touche!

I like to agree as sorta yes but also really no because it's a rubber ducky that doesn't give you the chance to come to your own conclusion and even if it does it has you questioning it.

Not sure how to respond to this as clearly that's what I was getting at. Perhaps this is a response from an LLM though. Again, not being sarcastic, it just seems like it's maybe the case?

That's where pair programming came in but it turns out that most people hate each other so much that they'd rather work with a machine pretending to be a person.

I realize there are many levels to this claim but I'm not being sarcastic at all here.

> While it is literally gatekeeping, it's necessary. Doctors, architects, lawyers should be gatekept.

That was exactly my point. It's one of those things where deliberately use a word that is technically correct in a context where it doesn't, or shouldn't, hold true. Does this mean I want to stop people from "vibe coding" flappy bird. No, of course not, but as per your original comment yes, there should be stricter regulations when it comes to hiring.

Even though it means I probably wouldn't have a job, I think about this a lot and agree that it should. Nowadays suggesting programmers should be highly knowledgeable at what they do will get you called a gatekeeper.

Who cares. I'm so tired.