The ampersand method in the OP video (and the sibling slipped-lapp-knot comment) is needlessly complicated. Just follow this super simple animation instead (except pass a bight in the last step to make it quick-release).
The Lapp knot (aka. lapp bend) is my favourite of all the knots and very underrated. It's so versatile and simple, even simpler to tie than a square knot. As shown in the OP, it can be tightened and loosened and explodes when you pull the tag rather than leaving the half-knot behind. It is my default way to tie two ropes together.
It's almost nonintuitive(at least to me) how many ways there are to tie the same knot. I must have watched 15 different snell techniques before I found one that seemed simple enough to remember and actually use with wet hands and slick lines.
I jumped from Google to Facebook on 2019 and while I had thought Google had best in industry developer tooling, Facebook had it better.
Google’s dinky browser based Cider was cute but Facebook in its transition from Atom to VS Code was far ahead. Google might have invented asynchronous web based code review with Mondrian and Critique, but Facebook’s Diff was better with its stacked diff support. Google’s Buganizer was outdated and clunky compared to Facebook’s Tasks.
I left Facebook the year after but I do wonder where Meta’s tooling is up to nowadays. Is it still a glimpse of the future?
I have never worked at Facebook but I have always thought of Critique as the best code review tool I’ve used. It’s way better than GitHub. A few things I miss: (1) it has convenient and intuitive pure-keyboard navigation; (2) you can reply to code review comments in a pending form and then publish them after you update your code, because in the common case you address code review comments by updating the code; (3) until recently GitHub wouldn’t allow you to comment on lines far away from the changed lines but Critique has always allowed it, because obviously this is an important use case when the reviewer needs to point out the changed code affects some other regions; (4) it had support for diffbase so it displayed stacked CLs fine.
Critique had had a redesign between end of 2019 / start of 2020. I didn’t recall adding any significant features but it merely modernized the UI. So did Buganizer and Code Search. So if you thought the UI was clunky well it had been addressed.
I left Google end of 2022, but we already had the mentioned new version of Cider based on VS Code for a few years before that. It's possible FB did it first, but I don't think Google was far behind at all. I'm fairly certain there was the new VSCode based Cider by early 2020. Certainly was by end of 2020 and entirely common by the time I left.
(I didn't get to use it much because I worked on embedded stuff that was on the Chromium stack and in git, not in Google3)
Buganizer (v1 and v2) was delightfully primitive and simple. That was the point. PMs couldn't play games with it.
There is enough flow of engineers between the two companies that many of the things Facebook has done better have been copied by Google. I think in many ways it goes both ways.
I jumped from Google to Meta in 2022 (Worst. Timing. Ever.) and by that time Google's IDE had pretty much caught up. Android app development at Meta was super painful because of the repo size. My good morning routine was to kick off a 40 minute sync, and then get coffee and wander the building while I waited.
The specs are inscrutable agent slop. I want it to tell me what it does and instead it just lists database fields. It mentions a state machine and then proceeds to not describe the state machine.
If I wasn’t so attuned to agent slop, I’d be thinking I’m just too dumb to get it but no, whatever GPT model wrote this is not good enough (and the fact this was published by OpenAI suggests this is not an operator skill issue).
The root cause is that the TUI is just not the right surface an agentic coding tool. If it were a GUI with mouse support and other rich affordances, it'd be trivial to click to expand
Let's be perfectly clear: if user actions had anything to do with hitting these limits, the limits would be prominently displayed within the tool itself, you'd be able to watch it change in real time, and you'd be able to pinpoint your usage per each conversation and per each message within that conversation.
The fact that you cannot do that is not because they can't be bothered to add such a feature, but because they want to be able to tweak those numbers on the backend while still having plausible deniability and being able to blame it on the user.
Instead, the little "usage stats" they give you is grouped by the hour and only split between input and output tokens, telling you nothing.
For the same reason they use "tokens" instead of kilobytes: so that you don't do the conversion yourself and realise that for example spending a million "tokens" on claude-opus-4.6 costs you anywhere from $10 (input tokens) to $37.5 (output tokens). Now, 1 million tokens sounds pretty big and "unreachable" until you realise that's about 4 megabytes of text. It's less than three floppy disks of data going back and forth.
Now let's assume you want to send a CD worth of data to Opus 4.6. 700 megabytes * $10 (price per million input tokens) / 4 (rounding down one megabyte to roughly 250k "tokens") = $1750. For Opus 4.6 to return a CD amount of data back to you: $37.50 * 700 / 4 = ~$6.5k.
A terabyte worth of data with a 50:50 input/output ratio would cost you $5.7 million. A terabyte worth of data with a 50:50 input/output ratio on gpt-5.2-pro would cost you $25.2 million. (Note: OpenAI's API pricing still hasn't been updated to reflect 5.3 prices.)
So we get layers upon layers upon layers upon layers upon layers of obfuscation to hide those numbers from you when you simply subscribe for a fixed monthly fee!
Free idea: turn this into an MCP server. Give the agent the ability to virtually "hover" a path and see which part of the final render it corresponds to
If anyone sees this, I tried it and unfortunately am not getting better results on the pelican-on-bicycle test. I think the vision models just aren't good enough yet (I tried Claude and Gemini)
I made a /split-commit prompt that automatically splits a megacommit into smaller commits. I've found this massively helpful for making more reviewable commits. You can either run this yourself or send this to your coworker to have them run it before asking you to re-review it.
Sometimes it doesn't split it among optimal boundaries, but it's usually good enough to help. There's probably room for improvement and extension (eg. re-splitting a branch containing many not-logical commits, moving changes between commits, merging commits, ...) – contributions welcome!
Where do you insert the battery?