throwawayx50223

> If a branch is rebased, then comments on code that was changed get lost

That's probably more related to UX than git itself. I remember Bitbucket (also git) handling these situations better and conversations were much easier to follow, but I haven't used it in a few years so things could have changed.

I haven't used Bitbucket for a long time, but from what I remember it had a superior merge/pr tool. It was much easier to follow review comments after a rebase or commit. Is that still the case?

That matches my experience too. SVN and CVS was very common as far as I remember. More developers probably use version control now than before, but version control was considered part of "best practice" before git was released.

There were of course places that were late to switch. I remember one of my old work places used P4 due to legacy in the CI/CD pipelines, but many teams kept a "shadow" git repository in Bitbucket with a bridge to P4. After a while, the company finally switched to Github Enterprise

> Personally I'd rather be working on a system that's massively important with less flashy tech, than building more inconsequential apps with the latest frameworks.

I am the same type of person. Solving a problem and creating a great product can be very rewarding and is my primary motivation.

There have been times in my career where I have been thinking more about how I could sneak in a new technology in a project. In those cases it was a sign that the things I worked on were not motivating enough, or a bad work environment. I'm more aware of how these things affect me now that I have the benefit of hindsight.

I probably fit the description of a dark matter developer. I don't have any public github repos and don't feel comfortable blogging. I do read a lot of blogs to keep me up to date with the current trends and try to get some in depth knowledge. A lot of the new trends are basically old stuff with a catchy name, so my primary focus is finding out what makes it different or better.

It's fun to test new technologies, but I can't in good conscience recommend them to companies that don't have the resources to actually be at the bleeding edge. Too many people look at the shiny new tech and don't consider the cost of using it.

My primary motivation is creating a good product. I get things done by managing a healthy mix of known technology with a sprinkle of new things so that the magpie developers can see something shiny. In my experience the new shiny things should be kept to a minimum until you either grow so big that your lost opportunities are insignificant, or you have several teams able to cover the bets in case s*t hits the fan.

Unless your startup is mostly technology (like a new database), you are probably better off using "boring" technology and focus on making your product stand out. Try to find a few dark matter developers who knows how to balance.