So on the other side of this, I’ve also seen senior+ folk working on projects alone, with no collaboration at all, but still use a GitHub-esque PR/git-flow process. Almost feels like a professionalism-espousing self-flagellation.

Create a PR, self-approve the PR, then merge it to a develop branch. Then merge the develop branch into main. Then in main make a release branch, and tag it.

I sometimes do something similar, as it gives a chance for the CI to run more comprehensive tests on other platforms that's hooked up to the PR flow, and "reviewing" your own code can be pretty helpful.

You could easily have your CI keyed on tags or commits, reviewing my own code is very helpful but also so wasteful of time.

Depends how much CD you have.

> have your CI keyed on tags or commits

I think I treat "PRs" on my own projects as pretty much the same as tags or commits - they require pretty much the same amount of documentation and description as a PR to a third party if they are meant to be meaningful to myself in a few years time, after all.

I don't use pull requests because it seems higher ROI to just put that effort into crafting a good merge commit message.

Aside from that, you've more or less described my workflow for solo projects.

I can see doing this, stepping away from the change for a bit, come back and read the PR from a fresh perspective and see if you can make sense of the change and if there are any errors.

Also, the “paper trail” of PRs is nice to have.

That's commits with extra steps.

I'm guilty of this. I open PRs on my personal projects and then merge them in myself. Not for every commit of course, but for the big changes.

I just like to see the diffs on the github UI. <shrug>

Installing delta locally may ruin the GitHub UI for you

It's a mindset thing for some people I think, they have a "flow" and just continue using it. I sort of see it, but it's a time sink.

Personally if I'm working by myself absolutely not, commit straight to main or a feature branch, life is way too short.

Yes. Because writing code is so easy a bot can do it these days. sets the everything else that goes into writing code that wants to be captured, so following process is about how much you love future you, who has to come in three/five/ten/twenty years from now and figure out wtf you were thinking when you wrote this. Did I mean to use > instead of >= or was I just careless?

I've known quite a few software engineers who just don't bother to learn anything about the tooling they use to create and deploy code. For younger, new developers, I can understand it when everything is presented as an app with minimal customization, but for mid-levels and senior engineers I am baffled by the lack of curiosity.

Sometimes just a couple of simple howto sessions can be incredibly useful, especially for teams just starting on a new project. I've given tutorials on Git basics, command line basics, workflow basics, and AWS terminology. Each time I've had engineers say it was like learning computing for the first time, because apparently newer engineers just don't get taught this stuff.

This is partly why I enjoy improving the developer "experience" (DevEx) alongside my normal DevOps duties.

That's such a relatable story - and I feel like it highlights something I've been thinking about a lot while working on these visual and gamified Git tools.

There's this whole class of capable engineers (some at senior/staff levels!) who just never had to build good Git habits or learn how to think about the different options that Git's command set provides, because their workflow didn't demand it.

Curious - do you think that's mostly a tooling/culture thing, or more of a learning gap, where they just never had a reason to dive deeper?

Part of why I'm making these tools is to explore if a more visual approach might make some of those concepts stick better. But curious what you've seen actually work in practice for helping people improve their Git skills.

Maybe because they didn't use Git in their career or their role doesn't require to be hands-on.

In my company, we use mercurial so I can imagine that some SWEs aren't fluent in Git because they've used different tools. But apart from that, Git isn't rocket science. It takes a bit of practice like anything else but anybody should be able to know the basics in a few days, and become proficient after a few months of regular practice.

I don't think that regular usage of the Git CLI is sufficient to develop an insight into Git's internal data design for most people, which is really necessary for to become proficient enough to troubleshoot. You wind up thrashing a lot and then just giving up.

I've always used IntelliJ/PyCharm/Rubymine for my Git needs.

That handles 98% of what I need to do. For the remainder I sometimes stumble pretty badly, but figure things out.

As you highlight with the "VSCode over RDP" story later on the post, it doesn't stop on Git. Some people just don't care about learning their tools. RTFM? Hell no. There is no care for the "craft". Once they learn the very basic for their current need, they're done with it. We can also observe this behavior during coding, once "it works", they just push all changes and move forward to the next thing. No second thoughts if it could be simpler/there were unnecessary changes, no double check if there is missing cases, etc. "Someone will spot my wrongings during review".

From the outside, it feels like "low effort" all around. But to be honest, I can't really blame who does this. For some, it is just a 9-5 job anyway and they prefer not think about these stuff outside that 9-5 space. Deep diving into their tools might look like "wasted time" on their view.

A friend refered me to this great post a few days ago that touches on this subject: https://josvisser.substack.com/p/you-cant-teach-caring

This is simply what happens when you pay people with very little knowledge large amounts of money to do something that requires expertise. I'm not sure why we're pussyfooting around that.

It would be like not knowing about loops or how to print text to the screen or how to do I/O. People seem to think you can be clueless and somehow still deserve a programmer's salary. The entitlement baffles me (and I've experienced a lot of it from people throughout my career).

A staff SWE who can't send you a patch is simply unworthy of their title, the way I'm unworthy of the title "pilot" or "doctor" or "attorney".

I wouldn't trust the world's leading neurosurgeon to perform surgery on my ankle. Nor would I want my patent attorney to represent me on a murder charge. I'm also not trusting the pilot for the Marine One helicopter to fly me anywhere on a Boeing 737 Max. "SWE" is simply too broad a term to encompass all of the deep knowledge someone should have at some point in their career. That us, unless we want to talk about licensing software developers with certifications, which is a whole other can of worms.