It’s not about ease of use and freemium, it’s the strong network economies at play, just like credit cards or social networks. It’s impossible for a competing product to get traction if it’s merely a little better than GitHub.

This is the real issue. We’re currently migrating from GitLab+Jira to GitHub. I did most of the migration, including our CI/CD with a self-hosted runner, and it was… fine.

The straw that broke the camel’s back was that Claude managed cloud agents are awkward to use with anything other than GitHub. In general, we realized that the whole world was on GitHub and we were swimming upstream.

But the original mistake was separating issue tracking and source control when we didn’t need all that power. Everything is so much simpler if you don’t have to maintain those integrations.

Maybe they’ll really enshittify GitHub in the future. We’ll cross that bridge when we come to it.

We did this on a train! Also StarCraft, also a coding competition, also felt like the coolest kids in the world.

Don't you tell me the competition was in New Jersey...

Nope, it was in the Midwest.

I love that Naur paper! Also love this essay that extends it: https://hiringengineersbook.com/post/autonomy/

I literally maintain a conceptual-model.md that describes the “things” in our entire system, how they relate to each other, and some bits about how that maps to the code (the DB schema maps sort of closely to it but sometimes not that close, and so does the API, and that’s ok). I wrote most of the doc myself, but plan to coauthor with LLMs going forward.

So far it’s saved me tons of typing as I add features. I don’t have enough data yet on how well it will guide myself and others when adding stuff that really stretches the model, but I’m also optimistic that it’s a valuable approach.

This is the kind of practice I was going to get an insight into.

For your conceptual-model.md, do you find natural language is sufficient? Do you use pseudo code, Entity Relationship modeling, or anything like that?

And how do you go about round-tripping it from the source code, keeping it up to say with any changes, and yet at the right later of abstraction?

Were you concerned about the overhead of shelling out to journalctl?

No, at the very worst I could have done it on a different thread (although I don't expect to have needed to). Since I initially planned on supporting 3 different init systems (systemd, Shepherd, and OpenRC) which are all used on wildly different systems, the shelling approach seemed way too brittle. Paths for example are going to be significantly different for systemd on Ubuntu and NixOS for example, and then there are distros like Alpine that like to put binaries into /usr/lib instead of /usr/bin sometimes for some unknown reason (had that one happen to me with Ninja, which caused problems with some CMake scripts I was using). So ultimately, I decided that the project had too many unknowns. Bit of a shame, since I planned to use it to really get to grips with Haskell.

You abandoned your dreams of mastering Haskell by making a system operator UI using QT, but gave up out of concern that `journalctl` might not be in PATH?

I gave up because I couldn't see a way to make the program consistent. The path issues were the most immediate concern, yes, but not the only one. I really wanted a consistent UI because there are few things that irritate me more than UI layouts switching up on me, but I just couldn't see a way of doing that. For example, OpenRC stores the complete description of service definitions in 2 separate files, one of which is optional. You have a shell script that contains the code to run in /etc/init.d, but you also have a config file that describes the environment that code is ran in in /etc/conf.d. If I wanted to have services be editable live in the GUI (and that was one of the main features I wanted out of it), I would have had to split the text editor into two panes for OpenRC.

Overall, I guess this is a kind of perfectionism or choice paralysis I guess. I have continued to write Haskell since, and am now comfortable with the base language, if not the ecosystem (I have no idea what a lens is).

[stares awkwardly in Haskell]

I often have to remind myself that we have the programs we have today only because somebody wanted them to exist more than they wanted them to express abstract properties like consistency.

As someone who’s an experienced coder but sorta new to LLMs, I’ve learned that my intuition about what is and isn’t machine-readable for an LLM isn’t well-tuned. Better to do the benchmarking so you can be sure you’re not fooling yourself about whether use of YAML is warranted.

From the perspective of the “physics” of code (for lack of a better term), this feels right. We all know that if you have a generated asset, you basically mark that asset as read-only or you’re entering a world of pain. As more and more code is generated, the same forces will apply.

Harder for brownfield projects of course (and it basically replaces Jira, which would cost me all my social capital if I try), so I won’t be adopting it now. But I will be leaning into long-lived organic, grass-fed assets like conceptual-model.md that‘s critical for evolving the product forward but doesn’t strictly map to the types in the code.

I really enjoyed engaging with the article. Loved the humor sprinkled in, and the humility demonstrated throughout. Some great first-principles clear thinking here.

It’s almost as if we need to write some unit tests. For our profession.

Every now and then someone shares a small web link here (Kagi is one aggregator). It’s like survivors picking up the shards of civilization after the apocalypse. Of course such a project can remain viable and useful as long as it remains niche, which is virtually guaranteed as long as there’s no money in it.

It’s incredible how too much money corrupts everything it touches.

Some of my best work has been done as a labor of love. I do have the vague impression that we as a society have taken a wrong turn in selling the sacred. I am not in favor of collapsing society down to hippie communes or anything, but it does seem to me that we told better stories back when stories were freer.

I sometimes imagine gathering up some number of like-minded electrical and software engineers, and founding some sort of monastary in which everyone was fed and taken care of and built the best technology they could, as a gift to humanity. I do wonder if the day's robber barons would find a way to shut us down, of course, but I still remember a bright and optimistic time when technology was made to serve people, not to oppress them, and it seems to me like a bright expression of human spirit that oughtn't to have been sold.

I switched to Linux in 2018, and I hear you on the quirks. But now, an LLM can fix basically any quirk you hit. I’ve been surprised multiple times. I’m also on Pop OS, which feels more batteries-included than Ubuntu.