So today, again, I discovered the importance of unitests.
I was solving this performance issue, in which we had a few update actions for multiple entities in mongo, but it took FOREVER to complete, even when I unified it into one bulkWrite command.
Since the unified write did improve performance slightly, and we wanted to move on, we decided to let this bug go.
So there I was committing my changes when I got a rejection from the pre-commit hook since I didn't have enough unitests coverage.
Ok, let's start writing some unitests.
Some unitests also needed to test the bulk write. So there I was comparing expected with actual result, and suddenly I got a huge facepalm.
Apparently some rogue for loop iterated all entities again for each entity that needed update. So instead of getting one update per entity, I got N identical update commands per each of the N entities 🤦‍♂️
Needless to say, fixing this fixed the performance bug entirely.
Thank you unitests and pre-commit hooks!

Git pre-commit check means that only team lead can merge to master. Team lead is also pulled in meetings all day everyday and so never has time to merge...

More companies need to clamp down on hard-coding secrets. It’s not difficult to store them somewhere else, and there’s swathes of free tooling to stop you doing it in the first place.

Heck, set up a pre-commit hook. Link it to a shock collar.

all of them. countless wasted hours.

as fate decided to turn me from $random-dev-geek into "the guy that calls the shots in tech", one of my earliest decisions was to automate formatting.

everywhere, automated at CI.

gofmt was an inspiration for the industry.
js?/ts? use prettier
C++? use ClangFormat
etc.

always default settings.
enforced by pre-commit hooks and CI.

never a single argument about bracket style, I don't care if someone likes single or double quotes better.

"fucks given" counter is fixed at 0.
everybody prefers it (ok, sometimes after a while sometimes)

of course there is still some more conventions to do for us humans.
IMHO the most critical ones.

like naming or even casing (camel, snake, kebab, - which one works where), but taking out most of the "so what" decisions takes discussions to a much more resonable level.

These are the rules that apply to all of my JS projects:
- 100% typescript, “any” is not allowed
- strict prettier with pre-commit hook
- no semicolons
- no braces around single argument of an arrow function
- tabs

Pre commit hooks serve no other purpose than to be annoying.

When you have a linter that runs as a pre-commit task.

The number of times I've fixed errors thrown by linters during a commit and then run `git commit` straight after only to realize I'd forgotten to add the files I modified for the linter fix.

Released the product to customers without realising someone had pre-filled a production test accounted login at the login screen. Obviously it was used for testing purposes and the dev forgot to remove it before committing.
I loled when I found out about it, and some customers started to login and made transactions.
When I checked the commit history... It was under my name :/

Just joined a new company and can only describe the merge process as madness.....is it or am I the one that is mad?!

They have the following branches:

UAT#_Development branch
UAT#_Branch (this kicks of a build to a machine named UAT#)

Each developer has a branch with the # being a number 1 to 6 except 5 which has been reserved for UAT_Testing branch.

They are working on a massive monolith (73 projects), it has direct references to projects with no nuget packages. To build the solution requires building other solutions in a particular order, in short a total fucking mess.

Developer workflow:

Branch from master with a feature or hotfix branch

Make commits to said branch and test manually as there are no automated tests

Push the commits to their UAT#_Development branch, this branch isn't recreated each time and may have differences to all the other UAT#_Development branches.

Once happy create a pull request to merge from UAT#_Development to UAT#_Branch you can approve your own pull request, this kicks off a build and pushes it to a server that is named UAT#.

Developer reviews changes on the UAT# server.

QA team create a UAT/year/month/day branch. Then tell developers to merge their UAT#_branch branches in to the previously created branch, this has to be done in order and that is done through a flurry of emails.

Once all merges are in it then gets pushed to a UAT_Testing branch which kicks off a build, again not a single automated test, and is manually tested by the QA team. If happy they create a release branch named Release/year/month/day and push the changes into it.

A pull request from the release branch is then made to pre-live environment where upon merge a build is kicked off. If that passes testing then a pull request to live is created and the code goes out into production.

Ahhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh it's a total mess. I knew when I took on this job it would be a challenge but nothing has prepped me for the scale of the challenge!! My last place it was trunk based development, commit straight to master, build kicks off with automated testing and that just gets pushed through each of the environments, so easy, so simple!

They tell me this all came about because they previously used EntityFramework EDMX models for the database and it caused merge hell.

Just spent a day creating a git pre-commit hook to lint file changes before commiting, practically didn't get anything done today except for that script..

Let's see if it's going to be worth every minute I spent.