Learn git. For real. Not just git pull and git push. Setup git with a mergetool and do the gitimmersion tutorial. Be the gitmaster!

The Return of Mr. Gitmaster:
So there is this colleague I already ranted about several times. After my previous team lead had confronted him about not doing much work, there was some irritation because he showed not up at work, but it turned out the external training he did was just a week earlier. Then he was ill a week, another week vacation so we didn't see him much. Not that his pre- or absence makes much difference to our repo: When his and my team lead looked at his commits of the past three months they found like the one copy-pasted HTML-form that wouldn't even show.
Fast forward to now, where we have a new team lead and we were going to lunch with Mr. gitmaster. So we got some more hero stories from the great work he was doing in the previous company. How he was graphically monitoring the heap fragmentation that stupid glibc was causing to their search engine, and how much better it became with tcmalloc.
I still don't understand how he bridges that cognitive dissonance from all the superior tech knowledge he displays to not actually writing any code at all. Not that I would not have experienced some states of feeling low, in paralysis unable to write a single line of code... but he seems so full of confidence, always commenting how trivial and easy all these tasks would be, as if it's all so lightyears below his abilities. Maybe he should just become a manager - but not mine.

Okay, I knew one of my colleagues was actually a work freak, but to this point...

He's been working for most of the day yesterday on a school project, and so was I. Satisfied with my progress, I push the code with TODOs on things we had to agree on tomorrow as well as mentioning it in the issue associated with it on Git, with my last commit a bit before 11PM.

I wake up, with a ping on Discord asking me what was that "bug" I just pushed, wondering what editor I use and asking me if I even use the console debugger. Said "bug" was the point of discussion I said we wanted to talk about tomorrow, I replied in the morning. But he decided of the fix on his own and committed it, as well as other things until... 3AM...

Honestly, I don't blame him for choosing at our stead, he's the leader of our branch and the Gitmaster on top of that. I just reproach him to call it a bug, not see the issue, and all that while he could, you know, sleep. And get some rest overall.
This dude has been working himself madly these last weeks, where he did about 80% of what each of the team member was supposed to do in a whole semester (which amounts to 150 hours of work) for this project (we're nine folks on it).
Now I'm pretty sure it's how he works and that he still gets a decent amount of sleep (like I dunno, until 9AM or so), so I don't expect a response beforehand.

And indeed, as he woke up, he replied to me.

At 7:50AM.

So we had a guy who spend decade in automotive, flight simulation and stuff. C mostly. Lasted only a month of his probation period. Didn't seem to know about double pointers. Maybe coding standards in automotive even discourage them...

But made me wonder how to judge skills. - I tend do be on the cautious side, as I hadn't really understood inheritance and many basic things when I started. But luckily my first boss believed in me, saw me gnawing through (Well about my 'initiation' that'd be others stories to tell). Well, guy was hired as a 'senior', so they expected bit more. Dunno, still feel a bit strange about it, even if I ranted about his chattering before, coz he also had his heart in the right spot, but maybe it's for the best anyway...

But guess who's taking his place in our team! Drumroll.. Yes, Mr gitmaster is.

The worst of Agile and Sc(r)um: All those people knowing the right way(™) to do it. Endless discussion about useless tooling: the proper use of the custom workflow in Jira, on when and how to create sub tickets. The hour-less meta-discussions on what should be discussed where and when (what's subject of the backlog refinement, retro, etc), the roles: the PO's, what he should do, cannot, the PM's. Who is allowed to pull a ticket to the sprint or not. How many reviewers need to acknowledge a pull request. To and fro. Pointless, but fought with heart and blood, full of sound and fury, signifying nothing.

And everywhere I hear: "In my previous company, we did Scrum like.. and it worked perfectly!"

Some of you might remember my rants on Mr. Gitmaster, with whom I thought I'd made my peace. Guess what? He's now a team member and turning into Mr. Agile - a more severe reincarnation! As our company starts flogging that dead horse of Agility, he seems to feel strong tailwind. Our team lead would constantly cut his monologues, but he's now on holiday, so we have no escape from the never ending: "In my previous company..."

If it was so great, why didn't you stay?

We are not allowed to pull a ticket to the sprint unless every team member is notified? I don't fucking care. If our software fails on customer's machines and I can fix it, I will do if there is a ticket, if it's in the sprint or not. Screw Scrum, if it is getting in the way of it. You can waste your hours discussing horseshit, I want to sit at my desk, deep in the test-compile loop and ship some fucking code.

Long time nothing from Mr. Gitmaster, somehow made my peace with him as the project moved out of my focus and he actually seemed to be contributing.
But now some pull request exchanges burst into flames as if they were on LKLM before Linus got castrated. Actually it's with the guy who is jamming out most of the front end code trying to make a really shiny UI with lots of animations that turn our macs into heaters.
Well, debate was over JS code styles or lack thereof and how commented out code should be removed (would actually support Mr gitmaster here). They have me a bit lost there, as I expect the freestyle JS code we produce without any agreed Coding Style Guideline to be an even greater clusterfuck than our C++ code base.

Anyway, hope they come to terms again, like at the start of the project when they jokingly attributed one another as assholes. Their opposing characters could actually benefit from each other.