legorobot

I wish it were :)

This is the right way to do it. Whether using trunk-based development, git-flow, etc -- you're controlling the flow of merges in a particular direction.

However, I think the "larger planning issue" is harder to easily avoid when you have more devs, more changes, or the AI-boosted output we have today. If feature B requires feature A, and feature A isn't up-to-date with main, I could rebase feature A to main, then feature B to feature A. When feature A is merged and we're ready to PR feature B, I can rebase to main again then make my PR.

Would we say us as humans also have captured the "best" way to reduce complexity and write great code? Maybe there's patterns and guidelines but no hard and fast rules. Until we have better understanding around that, LLMs may also not arrive at those levels either. Most of that knowledge is gleamed when sticking with a system -- dealing with past choices and requiring changes and tweaks to the code, complexity and solution over time. Maybe the right "memory" or compaction could help LLMs get better over time, but we're just scratching the surface there today.

LLMs output code as good as their training data. They can reason about parts of code they are prompted and offer ideas, but they're inherently based on the data and concepts they've trained on. And unfortunately...its likely much more average code than highly respected ones that flood the training data, at least for now.

Ideally I'd love to see better code written and complexity driven down by _whatever_ writes the code. But there will always been verification required when using a writer that is probabilistic.

Preface: I'm likely nitpicking here; the use of "_just_" is enough for me to mostly agree with your take.

Isn't the idea that the bulk of complexity IS in the understanding of how a system works, both how it should work and how it does work? We could take the Quake Fast Inverse Square Root code, which is simple in "size" but quite complex on how it actually achieves its outcome. I'd argue it requires comments, tests, and/or clarifications to make sense of what its actually doing.

How do we measure that complexity? No idea :) But I like to believe that's why the book takes a philosophical approach to the discussion.

I agree the arguments in the book largely "make sense" to me but I found myself finding it a little hand-wavey on it actually proving its points without concrete examples. I don't recall there being any metrics or measurements on improvement either, making it a philosophical discussion to me and not a scientific exercise.

However, my personal projects have a different set of code I reuse (more CLI- and tool-heavy focus), and I'm sure other environments would have an entirely different set of reused code.

On the opinionated library side of things, I did follow LiveBud for a while, and Go-Micro but haven't really sat well with the experiences from those, given how they lock you in to different aspects of your stack.

We've had to perform occasional maintenance but its operated for years with no major issues. 99% are solved with a server restart + a startup script to auto-re-mount s3fs-fuse in all the appropriate places.

Give them a try, I recommend it!

It was the first time I felt like I can wrangle the OAuth spec and implementation, and really understand all the ways in which things can go wrong without proper care and expertise into how an OAuth server can be attacked, and how to mitigate those issues the right way.

By the end you might have so little to show, but I found writing down what I learned a great way to "mark" the project with a healthy milestone :)

I usually get stuck in "cycles" where I know I'm not making progress, but I'm exploring my interests and seeing what sticks and what doesn't.

I've found forcing myself to a bare minimum has helped. The age-old "write one article a month" type of thing has forced me to find that sense of purpose to sit down and write something. Sometimes it turns out well, sometimes it doesn't. The process and lessons learned have been more important than the (immediate) results.

Once you're reaching 1.0.0, you know these can no longer be sliding through, and you can support all of this in CI.