JimmieMcnulty

I didn't say you could, I said your proposed "never use any branch other than main" was both factually incorrect (your team literally didn't do that) and not how the git tool was designed (merging branches into a main branch is trivial, and in fact how the tool was designed).

What? You want an "article" that describes how git branching works? Here.[0].

> Some people refer to Git’s branching model as its “killer feature,” and it certainly sets Git apart in the VCS community. Why is it so special? The way Git branches is incredibly lightweight, making branching operations nearly instantaneous, and switching back and forth between branches generally just as fast. Unlike many other VCSs, Git encourages workflows that branch and merge often, even multiple times in a day. Understanding and mastering this feature gives you a powerful and unique tool and can entirely change the way that you develop.

It's really not hard, a "local copy" is a branch.

If you can't manage what you just described trivially, you need to learn git better, because I, and everyone else who knows how to use git, can manage those things trivially, and have successfully for many years now.

Your solution was the wrong one, homegrown to avoid dealing with the reality that you and your team didn't know how git works.

All of this would be fine, by the way, had you not proposed others listen to you. Exactly zero people should do as you have described.

[0] https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-N...

It does make discussion easier, which is why your improper use of the term caused such confusion here, and illustrates my larger point; your team sounds like it has a fundamental lack of git knowledge which prevented it from successfully making use of the tool, instead falling into anti-patterns and bad habits that may or may not have resulted in delays, confusion, and disruption that would not have been necessary had you actually known the correct way to keep a branch up to date and avoid costly merge conflicts.

You're not using the correct terminology to describe what you were doing...

Your local copy is a feature branch, as you are developing features on a branch other than the branch you've designated as the "primary" branch (your "main" is a branch off of the main repo's "main").

There is nothing whatsoever that requires a feature branch be long lived or named anything in particular. This is what I mean when I say you don't understand the technology you're using.

What you have linked is a "flow" that uses branching, and isn't relevant to this discussion.

My brother in Christ what is it you think you’re doing when you clone a repo?

Yeah, but nobody here is suggesting long lived branches, nothing about a feature branch requires that it exist for a “long time”. Your local “main” branch that you’re developing a feature against is a “feature branch” you just aren’t calling it that.

But even if it did, regularly remerging main back into it (or rebasing) does solve like 90% of the issues being described here, and further comes with a whole host of other benefits.

You’re literally doing feature branches, you’re just doing it worse by not changing the names of the branch as you have it locally (so you can’t share or store your work anywhere but on your machine), but you don’t know enough about git to speak intelligently with others to accurately describe your team’s workflow.

Also I guarantee I’ve used git branches in more dynamic situations than what you’ve described here and it caused absolutely zero issues.

Learning to use the tool absolutely does help, because it alters your workflow to fix your glaring developer experience issues.

Your team is suffering badly from a lack of even a baseline understanding of how to develop software as a group, and learning even the most basic usage of git would substantially alleviate that issue.

What? It’s trivial to keep these branches in sync…

The more you comment, the more it’s clear you work with a bunch of coders who want to “go dark”, and there are a ton of problems with that.

Don’t go dark.

Coworkers.

Also you’re pushing code into this main branch from… where? Another main branch.

That’s literally how git works, you’re just removing any oversight and collaboration opportunities by insisting on calling this branch you’ve created locally “main” as well.

Code reviews are awesome, and not doing them is a fantastic way to ruin your team’s ability to support work they didn’t themselves write.

Git completely removes the complexity introduced by branching, as it takes care of merging the branch for you?

It honestly sounds like you don’t know what a branch is, since you’re talking about libraries and multiple supported branches, so I very much doubt your “git-fu”.

It sounds like you’re in the “merge conflicts are hard” camp, which is a camp of ignorance.

I’ve been using git for nearly 15 years and not more than a half dozen times has resolving a merge conflict taken me more than 15 minutes.

This just isn’t a real problem. Try working more incrementally, or try working with colleagues who don’t rewrite large swaths of code without coordinating with their team.

You have a people problem, not a tool problem.

This is written as if git doesn’t exist, and Agile were never invented.

If branching/merging is giving you this much trouble, you’re doing something very, very wrong.

Pause, actually learn git, then resume.

Also, testing is so easy, if you’re doubling your dev time writing tests, that’s another thing you need to dedicate time to for learning, because it should add maybe 10% more if you’re competent.

… that’s literally what all the meetings are for, to take care of building the project properly, because you know how to build all of the parts of the product.

There is no level of skill at which anyone will ever just be able to do an entire project on their own; no matter how good you are, you’re always going to be better with others.

That's not really virtuoso, that's just what you get a while (5-10 years, sometimes less) after starting your coding career.

My larger point is that they're not worth as much as the coder who can also project manage/lead/mentor/etc, because the latter coder can both be a "virtuoso" (or like 95% of one) and also make the people around them better, and that's substantially more valuable.

The thing folks who "just want to code" don't realize is that their "value above replacement" is never going to be high enough to justify the desired pay increase over time that most folks expect as they advance in their careers.

That said, it's probably more fine if you want to be 10+ years into your career and accept the pay comparable to those more junior coders. Some people do get this by negotiating fewer hours, for example.

And not for nothing, but leading/mentoring is highly achievable for any "virtuoso" coder; not wanting to help others and pitch in on design is a personal choice, as most "virtuoso" coders would probably be great at both if they put in the effort. It just means holding meetings more and coding less, which is outside of their comfort zone and therefore "scary" in some sense.

They could be doing so many other great things, I wish they would please try to get over their insecurities and fears! I will help, as that's my job because I did get over those things and transition into this role from a coding role.

“Better” is subjective, but one of the people from Hipmunk built a new… browser plugin that mimics some portion of Hipmunk’s functionality.

I used it a bit, but Google Flights is getting me 80% there so I haven’t overcome the switching inertia yet.

https://chrome.google.com/webstore/detail/flightpenguin/nofn...

Okay on one hand, I feel dumb for saying this, but on the other hand I’ve literally built SSO integrations this way, so…

What about OAuth2? I had very little issue building auth integration with both Okta and Google using OAuth, and storing the non-secret stuff about the user in my DB.

Children aren’t full humans yet, that’s the whole point of doing stuff differently for them…

The problem is that “just coding” isn’t all that valuable, relatively speaking.

College grads can do it barely, and 5 years in they’re fine. What do you do with the rest of the people who, 10 years after that, want to do the same things but get paid 50%+ more?

“Virtuoso” coders aren’t worth much (relatively), because it’s not that rare, and honestly bugs aren’t really a big deal. Heck, you can write some pretty terrible code, and as long as it’s not some specific flavors of bad, your company will be totally okay for a very long time.

IDK this is a giant red flag that the engineers running their infrastructure aren’t baseline competent, I wouldn’t trust these folks with my email, let alone my banking.

That said, this reeks of a contractor situation gone bad.

Oh some absolutely do, based on the bonds formed during that off-site.

Fair!

I'm pretty confident in my ability to pick up new tools and tech (I'm probably too far into the "bleeding edge" side of the "how comfortable are you supporting new tech in prod?" scale), so I'm not overly worried about getting left behind.

I just recently had to explicitly build a "raw" JS/HTML/CSS app for work, and found myself missing the organization React overlayed on top of JS, is all.

Besides, my bread and butter is backend, so I can always throw my hands up and shove the work onto some web dev's plate if I ever do get left behind! :D

I find myself missing React when building a plain HTML/CSS/JS site. I just like the modularity and my fingers have muscle memory for solving certain issues.

JavaScript is decidedly not "easy to use" in any sense for building out and managing infrastructure.

There are AWS/GCP/Azure APIs where you can fully manage your infra if you'd like via JavaScript. Nobody does this, however, for a reason. Lots of reasons, actually.

That's what this submission is, a way to solve a problem in a much harder (and limiting) way than is necessary, given the other available tools that can be used to solve this problem.

You'd be much better off learning something like Terraform to solve the problems being addressed here. Not everything has to be solved in JavaScript, and that's a uniquely "JavaScript" community solution, given how seemingly attainable it is to newer coders (which a lot of JS programmers are).

JavaScript, which is why "you must hate JavaScript" is a confusing thing to say to me...

Because I don't think JavaScript is useful for literally everything, I am therefore a hater? I don't think so.

You can also write everything in binary directly.

So how many projects do you build in Brainfuck?

After all, you don’t care about the details, as long as the language enables you to output something useful, and Brainfuck is Turing complete, so that checks your only box, yeah?

…or maybe using the wrong tools is a terrible idea, and you really ought to care more about the details.

Python doesn't have anything remotely close to this problem, as you can't (reasonably) write Python for the browser.

JavaScript has this problem because it's actually a somewhat attainable goal.

The main problem is that once you run into a problem not explicitly solved for by whatever Node.js framework that's holding your hand, you're in deep trouble, very quickly, unless you have a more "classical" software development background.