This might be a me problem but I extensively manipulate the git history all the time which makes me loathe git hooks. A commit should take milliseconds, not a minute.
What one considers fast or slow may vary, but the general rule is something like the following.
- very fast? run it all the time (shell prompt drawing, if you want, like direnv)
- fast? run it in a pre-commit hook
- a bit slow? run it in a pre-push book
- really slow? run it in CI, during code review, etc.
Fwiw: I also rewrite history often-ish but it's never that fast for me because I have commit signing turned on and that requires verifying my presence to a USB smartcard on each commit. For me, it's okay if a commit takes a second or two. As it creeps up beyond 3 or 4 seconds, I become increasingly annoyed. If a commit took a minute I would consider that broken, and if I were expected to tolerate that or it were forced on me, I'd be furious.
I generally expect an individual pre-commit hook to under ~200ms (hopefully less), which seems reasonable to me. Some of the ones we have are kinda slow (more than 1s) and maybe should be moved to pre-push.
Since you seem especially sensitive to that latency, here's what I'd propose if we worked together:
If you own a repo, let's make all the hooks pre-push instead of pre-commit. On my repos, I like many hooks to run pre-commit. But since the hooks we use are managed by a system that honors local overrides via devenv.local.nix, let's make sure that's in .gitignore everywhere. When I'm iterating in your codebases and I want more automated feedback, I'll move more hooks to pre-commit, and when you're working in mine you can move all my hooks to pre-push (or just disable them while tidying up a branch).
I would reckon cleaning up your branch before opening a pull request is good practice. I also rebase a lot, aswell as git reset, and I use wip commits.
Slow hooks are also not a problem in projects I manage as I don't use them.
No, I would not and don't do that. It is better to leave the PR commits separate and atomic so reviewers can digest them more easily. You just squash on merge.
> Slow hooks are also not a problem in projects I manage as I don't use them.
You bypass the slow hooks you mentioned? Why even have hooks then?
> It is better to leave the PR commits separate and atomic so reviewers can digest them more easily.
So reviewers have to digest all of the twists and turns I took to get to the final result? Why oh why oh why?
Sure, if they've already seen some of it, then there should be an easy way for them to see the updates. (Either via separate commits or if you're fortunate enough to have a good review system, integrated interdiffs so you can choose what view to use.)
In a better world, it would be the code author's responsibility to construct a meaningful series of commits. Unless you do everything perfectly right the first time, that means updating commits or using fixup commits. This doesn't just benefit reviewers, it's also enormously valuable when something goes wrong and you can bisect it down to one small change rather than half a dozen not-even-compiling ones.
But then, you said "atomic", which suggests you're already trying to make clean commits. How do you do that without modifying past commits once you discover another piece that belongs with an earlier step?
> You just squash on merge.
I'd rather not. Or more specifically, optimal review granularity != optimal final granularity. Some things should be reviewed separately then squashed together (eg a refactoring + the change on top). Some things should stay separate (eg making a change to one scary area and then making it to another). And optimal authoring granularity can often be yet another thing.
But I'll admit, git + github tooling kind of forces a subpar workflow.
I do leave PR commits separate. In my teams I don't set up pre-commit hooks altogether, unless others feel strongly otherwise. In projects where they are forced upon me I frequently --no-verify hooks if they are slow, as the linter runs on save and I run tests during development. CI failing unintentionally is usually not a problem for me.
I was thinking that he's describing implementing an initial algebra for a functor (≈AST) and an F-Algebra for evaluation. But I guess those are different words for the same things.
According to the wayback machine, the change happened somewhere between Oct 7 and Oct 10. Interestingly there are no recorded snapshots on Oct 8 and Oct 9, perhaps the redesign caused a couple days of outage.
Haha hey lyc! I didn't forget, you guys were second family! You taught me a lot about maths and code, not sure where I'd be without you :) Learnt more while messing around with fractals and gfx than in all my time at uni.
Honestly I try not doing much computer stuff in my free time because I'm doing so much in my day to day but I'll stop by some time! I've been in the Chaotica discord for years but never said hello.
That's kind of you to say, and I'd love to meet up sometime just for the lolz, it's really far too close (with lots of other cool fractal ppl nearby) not to :)
Do you remember the email you sent me 12 years and 1 month ago, in which (among much other unhinged stuff) you called me a nazi because I mentioned I'm (part) German? I remembered your name; hello again! I see your project didn't go anywhere, that's too bad. I'm sure you'll understand if I decline to invite you to my Discord server :)
Did the switch to NixOS a few months ago on my Thinkpad and ChatGPT worked wonders. I'm not very experienced with Linux distros and have been an Ubuntu user for a long time. I don't think I'll be switching away from NixOS anytime soon, it's great.
The learning curve is still extremely steep but after the initial 10 hours of googling it just all falls into place.
At some time in the video he's casually played a groove on the piano to back the birds for a couple of second, then stopped ("Wait, what am I doing") :)
You can also see his modular setup in the background.
I didn't know of him until today. Instantly, a new inspiration.
Except making employers do only easy things will make them stagnate. People who do nothing but simple CRUD apps over and over won't even be particularly good at making CRUD apps... whereas the guy who builds an Unicode font renderer in his free time always seems to write better code for some reason.
Getting better at your job is not just a "personal want" but very much something that the employer appreciates aswell.
Of course reinventing the wheel isn't good in corporate because the reinvented wheel is buggier than the ready made npm package but employers should go out of their way to find hard problems to solve that they can pass to their employees. It's called a growth opportunity.
You can’t convince an employer with that attitude. They’re gonna keep exploiting their employees and “encourage” them to do their “personal development” in their free time.
Unless you work for enterprise consulting where employers appreciate replaceable cogs that they randomly drop into any project, and nicely out project budget regardless of delivery quality.
I probably spend 30% of time on refactoring. Deduplicating common things different people have done, adding seperating layers between old shitty code and the fancy new abstractions, adding friction to some areas to discourage crossing module boundaries, that sort of thing.
For some reason new devs keep telling me how easy it is to implement features.
Really wonder why that is. The managers keep telling me that refactoring is a nice-to-have thing and not necessary and maybe we have time next sprint.
You just have to do it without telling anyone, it improves velocity for everyone. It's architecture work on the small scale.
I totally just verbalize my inner monologue, swearing and everything. Sometimes I just type "weeeeeeeelllllll" and send it, to get more LLM output or to have it provide alternatives.
It might sound weird but I try to make the LLM comfortable. Because I find you get worse results when you point out mistake after mistake and it goes into apologetic mode. Also because being nice puts me in a better mood and it makes my own programming better.
reply