Working Notes: a commonplace notebook for recording & exploring ideas.
Home. Site Map. Subscribe. More at expLog.
Spent the week learning about dataloaders, played with Go extensions and generally thinking about problems. I'd write more but I have a lot of work to catch up on.
After publishing the letter last week I fell into a rabbit hole of implementing a sqlite extension that can help understand / organize / parse markdown documents -- particularly using Claude and Chat GPT 4-o. Unfortunately the LLMs became very confused very quickly, constantly generating broken code and moving back and forth between the same issues. After a while I gave up and spent time learning to build this from scratch without needing to use LLMs.
CGo is surprisingly nice, and involves writing C code in comments that are simply parsed out and used while generating the extension.
Reading the unix philosophy was extremely satisfying: a lot of the ideas and patterns described in the book have survived 30 years, and resonated deeply with me.
I saved some of my favourites in threads, but reproducing the quotes with some impressions:
the UNIX philosophy is an approach to developing operating systems and software that constantly looks to the future. It assumes that the world is ever changing. We're not saying that we can predict the future. We can only acknowledge that, even if we know everything about the present, our knowledge is still incomplete.
I wish organizations in general were significantly more open about this, and understood their limitations in predicting the future, optimizing for the ability to move fast instead of perfect planning. This resonates all the way back to Boyd's description of the OODA loop.
When an application must be written and (a) it must be done to meet a practical need, (b) there aren't any "experts" around who would know how to write it, and (c) there is no time to do it "right," the odds are very good that an outstanding piece of software will be written.
I described this a little bit while writing about developer tools: but the scripts engineers will put together to unblock themselves tend to accomplish 80-90% of what a tooling team will build for them with perhaps .1% of the effort and time involved. Realizing this has changed how I think about building tools, and I would much rather leverage the fact that when my customers are engineers I can truly force multiply them instead of limiting their opportunities.
it is better to let the user shoot himself in the foot than never let him run at all. This can be painful to implement in practice, and I often have to push back on people locking down software for "safety", but often throwing out the baby with the bathwater. But if the organization is functional then there should be enough trust to let people run with scissors when they need to.
The software that exists in the world today represents a great store of wealth. Even more true today with the sheer amount of open source software powering most of the technology in the world today; open weights/source LLMs just add to the value and having these available is really valuable.
I'm still surprised at how little I see LLMs applied to CLIs and sys-adminy work at the moment: it's all text, and the problems feel like they would naturally lend themselves to being evaluated by LLMs. Most recently, I want to play with something that can construct a command for me by reading the help text, man page, and sample commands.
I think I've written about this before but I'm also a little surprised at all the products replacing the UI with custom UIs -- but I should just be able to ask the LLM to do things for me without needing to navigate yet another UI -- I can imagine a huge market for building tiny application specific LLMs that just super-charge the "Help"; instead of learning to navigate the application, ask the LLM to do something for you, and it also shows you how. I could see this being very valuable for everything from Excel to Photoshop.
Then layer on magical capabilities ("edit my photo in the style of Salgado") or domain specific knowledge.
— Kunal