I’m really sad that after 20 year we still have to explain that commit message is not a summary of code modification.
Commit message is here to gives information’s that are not visible in the diff. The context, the side effects, the decision that were made, etc… All of this cannot be generated by LLM.
Interesting point of view. You got my upvote 😉 I think many people took it 1st degree, so the many downvote you have.
I’m personnaly not a big fan of natural language programing. Natural language is too ambiguous and subject of interpretation. So you have to give very long description of what you want to achieve. I often do the parallel with Mathematics. If you read Euclid’s_Elements’s definition for point, line, etc…, wording is extremly wordy and indigestible. But moderne formalism is much more concise and precise. Now with LLM and vibe coding, I have the impression that programming is evolving backward 😟
The role of a developper has never been about writing code. The role of a developper is to formalize a problem. In a certain way, job of developper didn’t changed a lot since the last 50 years. My grandpa use to be developper on punch cards, and he had the sames problems than us today. How to translate accounting department request into series of instruction, how to define boundaries, etc…
I don’t know if the last part “What do these software developers actually do all day? ;->” is ironique or not.
Anyway, from my experience, industrial software developpers generate around 10 to 100 loc/day. For mobile game or shitty web stuff, it can go up to a few hundreds. For DO178A certified aeronautic code, this is closer to several days per loc 🤪. To know what’s going on when manager try to increase this metric, just have a look to Boeing.
Here is my “Tuesday evening 15min before leaving work analysis”.
Before COVID, IT market was stable. After COVID, there was WAY too many IT offers. Then, market collapse supposedly because of AI:
(Source: https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE)
In blue line, actual curve. In green line, what should have been IT market without COVID and AI.
For IT market to get back to equilibrium, red area should be equal to blue area. If I do some patchwork, I ended up with this:
So my conclusion is that it indeed slowly starting to recover and should be back to normal ~mid 2027.
Time to go home, bye 😁
I use AI for small, atomic, stuff that don’t bring any intellectual value to spend time for.
Like “Typescrit. Find smallest element in an array”. “Python. Simulate keboard event to avoid computer going to sleep mode”. Or copy/past error message because I missed an import and I just want to know which one.
I also use it sometime for well identified algorithm that could be interesting but are not the core of the problem. Like “C#. Clustering algorithm to group points together in a point cloud”.
The generated code is catastrophic in term of performances/memory, but it’s good enough 80% of the time.
But eveytime I tried to use AI for higher level stuff, or that require several interdependant concepts, it ended up into hallucination pit.
I was prepared to use my Cunningham Law mental model to correct your article, but no. I have nothing to say 😊
I’ve seen way too many wrong usage of git merge/rebase in lots of article but you get the point and clearly explained it.
Maybe just at the end, instead of
git checkout main
git pull
git checkout feature-branch
git rebase main
I would just do:
git fetch
git rebase origin/main
This avoid checkout main and checkout back to working branch, which may takes times on big repos.
Everytine I’ve seen a pre-commit hook in my job, it was something that should have been in integration pipeline.
You should not run linter, test or any static analysis tool in a pre-commit (I’m looking at you husky 😡). Why ? Because:
It takes time. A commit should be instantaneous.
It may change the content of the commit or of the repos without explicite action of the developer.
The developper’s branch is the developper’s mess. He don’t have to respect any convention, any quality gate or any workflow on its branch. Quality gates should happen only when integrating into trunk.
I always commit and push on Friday afternoon before leaving as “WIP”, in case my computer crash during week end. I don’t want to address issues of a WIP job. I just want to backup my work.
I may commit several time per minute, and do a rebase latter. I don’t want to spend 2min each time waiting for eslint to parse the repos. I don’t want to fix styling because I now I will fix it later and rebase -i before pushing.
You can use custom pre-commit in your own workflow, but forcing all developer to have the same pre-commit is a bad idea.
“Bad abstraction is worse than duplication”
Oh shit, thank you so much for this part ! I don’t even count number of time I had to face enthusiasts developers saying "These lines of code are very similar, let’s factorize them ! "
And that’s how MathManagerHelper class is born…
I gave a try to jj. It’s fine for personal projects or small team and make the workflow a bit easier. No more “git add; git commit; git push” each time you do a modification. You just “jj git push” and everything will be automatically pushed.
However, the biggest criticism I have is that he doesn’t encourage to push every time. It really encourages you to keep your modif locally and push only to create a PR, and that’s not a good approach.
Even if you code is WIP, even if everything crash, you really should push your code to backup it. Who cares ? As long as it is not on master branch, it’s your own mess.
I never really understood the advantage of worktree over having just several clone of the repos on different folders.
Can someone explain me ? I should have missed smth.
Could be a comment indeed. It’s hard, or even impossible, to clearly decide where to put an information. There are some guidelines, but no absolute rules. Commit messages, comments, API docs, tickets, wikis, etc… all of them serve different purpose.
Comments are here to explain an implementation detail when code cannot be self-explanatory. They live as long as the code live (and are unfortunately not always updated). They are used when a developer arrives on that line of code.
Commit message are here to explain why something has been added/removed. What happen before, what happen after, why this solution was needed. They are tightly couple to the diff and generally don’t contain generic high-level information (unless commit is a design or architectural modification). They are used by the reviewer and 5 years later by someone that do a git blame to understand why this line was introduced and what happen if I remove it.
API Docs explain the behavior of an API, as seen from the outside. They should not explain the implementation, nor explain in which case and which part of the system they are used.
Tickets explain a user request. They detail who request this and for what purpose, but only from user point of view. No implementation detail.
Wikis are here to cover your ass so you can say “See, it was written in the wiki !”