Hacker News Reader

Comment by joshuamoyers | Hacker News Reader

so ironic to see “load bearing” in a comment about removing AI. certain phrases have been ruined by fable/opus 5 for all time.

View on HN

I had this conversation recently. Not only are search engines and comment threads getting filled with AI responses, but people are increasingly sounding like AI themselves. This makes it even harder to distinguish.

Related to code quality, I've noticed developers picking up tricks from AI. Like using feature/xxxxx as the branch name. Last year exactly zero developers used this convention. If any used paths in their branches, it was almost certainly their name. Now everyone uses this convention. Though, they do use correct capitalization instead of lowercase freaking _everything_ that AI does.

I think this is just a Jira/bitbucket thing. If you add a feature branch, that's how the naming convention defaults. I've been seeing it for years.

I assumed the convention came from somewhere before AI and maybe one of the new devs brought it in from there. We also have an analyst who used em-dashes before AI ruined them, and who justifiably complains about that every so often. I'm not sure that's a trend anyone wants to pick up on.

But for branches in addition to Feature/, we're seeing Hotfix/, Modernization/, you name it. If you're parking branches for a long time without completing them, I'm 100% appreciative they're categorized.

The original git flow suggestion [0] was posted more than 15 years ago (date on the post is 2010). It didn't entirely invent the branch names/conventions from whole cloth, it was based on plenty of prior history in SVN spaces especially, which it picked up from CVS.

(Personally, for long term parked branches I prefer `{username/dev name}/` branches because then you know who the owner is without having to look at the commit log and guess based on recent commit authors. But that's the fun thing about branching conventions, there are so many to choose from, many of which have been around forever.)

[0] https://nvie.com/posts/a-successful-git-branching-model/

Linear does this, too. It provides a button that copies a branch name to the clipboard based on the ticket id/name.

> Like using feature/xxxxx as the branch name. Last year exactly zero developers used this convention.

The AI learned it from somewhere though, it didn't come up with it on its own

What. Strict branch naming like feature/, bugfix/, chore/, release/ has been the standard for probably 10 years now in all projects I've been in, often enforced by auto-rejecting pushes that don't comply.

Never used it in any of the projects I’ve been on.

Yeah, we've had our CI only run pipelines on proper branch prefixes for many years, so if you for whatever reason had a wip/branch you wouldn't clog up our runners.

I've used that style in 3 different companies over the last 10 years and I assumed the technique was ubiquitous. This just goes to show the standard deviation in engineering culture is high. There are some large bodies of water but also lots and lots of little isolated tide pools.

I've been using it at work since we moved from TF source control to TF-Git, close to a decade ago. feature/ticketno, release/number and user/initials/...

TF at least gave a nice folder view on the branches screen, which we've lost now we've moved to GitHub, but it has made it easier to enforce.

I think gitkraken is the only tool I use that presents it that way currently. It's a good convention.

> Like using feature/xxxxx as the branch name. Last year exactly zero developers used this convention.

People have been doing this for years.

> People have been doing this for years.

Tell me something I don't know. My point is that it's usage has seen a _measurable_ increase where I work over the last two years.

I don't think I have a single "feature/*" branch before 2024. Developer names, feature names, sure. But specifically feature/, no.

You have claimed that "last year exactly zero developers used this convention." If you choose to use hyperbole, don't be surprised when people push back.

> I don't think I have a single "feature/*" branch before 2024.

You might not, but other people have. Just because you haven't seen something doesn't mean it doesn't exist. Don't assume that your personal experience is representative of the whole world of software.

I think this comes from Conventional Branching, https://conventionalbranch.org, inspired by conventional commits (e.g. https://www.conventionalcommits.org/en/v1.0.0/)

And my point is that this pattern is now more popular than it was 3 years ago. Similar to people using the phrase "load bearing".

For me, this popularity is graphable. Telling me it's a convention doesn't change that fact. I'm sorry.

Closing tabs and I came back across conventionalbranch.org. I know this isn't your argument, just passing on info.

But holy heck, I really have to argue with their literal first point. All lowercase, for what reason? It's never explained why they insist on a dated convention instead of proper style.

And in what world is "feat/" abbreviation considered allowable?

I lump this in with advice from people who put their source in a src/ folder instead of Source/.

Feat/ or dev-initials/ or fix/ all very common pre-ai in my companies

If you use "Feat/" at my company you will get called out. No abbreviations allowed. Capitalization matters.

But that doesn't change my argument. For me, this popularity is graphable. Telling me it's a convention doesn't change that fact. I'm sorry.

> Related to code quality, I've noticed developers picking up tricks from AI. Like using feature/xxxxx as the branch name. Last year exactly zero developers used this convention.

Huh.

I've been using that convention for ages, but I have to remind Claude on new projects to actually use git in the first place, and then also specifically tell it to use branches.

Then again, I was using em-dashes before they got un-cool.

I'm not sure why you're arguing that when it's not the point of the statement. YOU have been using that convention. Now do an analysis of the people at your company.

Regex the pattern over time if you want to make an argument against my supporting example.

> I'm not sure why you're arguing that when it's not the point of the statement.

'twas an expression of surprise, not an argument.

Surprise in both directions, 'cause what you like about Claude is one of the ways it fails for me.

> Now do an analysis of the people at your company.

It was mandatory at several of them.

> Regex the pattern over time if you want to make an argument against my supporting example.

I wonder which of the various employers I've had in the last decade would consider me regexing commits to be an NDA violation?

I choose not to discover.

Reply on news.ycombinator.com