afc

Wonder if you've tried spec driven development (as opposed to just prompting)?

I used to create requirement-oriented prompts and I felt something similar to what you describe. However, I've switched to generating parts of my source code from my specs in a semi-automated way and it made the process much more pleasant (and efficient, I think).

I wrote a bit about my current state here: https://alejo.ch/3hi - for my Duende project I generate 8821 lines of code (2940 of implementation, 5881 of tests) from 1553 lines in specifications.

I also started building my own, it's fun and you get far quickly.

I'm now experimenting with letting the agent generate its own source code from a specification (currently generating 9K lines of Python code (3K of implementation, 6K of tests) from 1.5K lines in specifications (https://alejo.ch/3hi).

Disagree. If some small adjustments to your workflow or expectations enable you to use LLMs to produce good, working, high-quality code much faster than you could otherwise, at some point you should absolutely welcome this, not stubbornly refuse change.

For what it's worth it, I'm still developing and using exclusively my own text-based editor/IDE: https://github.com/alefore/edge

I wrote recently a bit about my conclusions after ten years of developing it: https://github.com/alefore/weblog/blob/master/edge/README.md

I wrote a somewhat related article, after running just this Friday into two blocks of code that were deliberately causing invariant violations (akin to the "max < min" situation) to be ignored silently: https://alejo.ch/3gk - Fail loudly: a plea to stop hiding bugs

Thank you for responding to my request for feedback, I appreciate it.

I actually I'm somewhat torn on this.

In my blog, I do this in my poems, such as: https://alejo.ch/39l — I don't expect this to be controversial, makes sense for poems, right?

However, I'm also experimenting with rendering my prose with the same type of breaks, like https://alejo.ch/3gb or https://alejo.ch/3g9

My guess, reading this thread, is that most people would tell me that they find the breaks annoying and would rather read my prose without the breaks? Hmm. Would love to hear some feedback.

+1 I own two Supernote (Nomad and Manta) and I can only recommend them.

It should be: std::optional<Timestamp> (or Optional[datetime] or equivalent in others languages)

If you're using a type system that is so poor that it won't easily detect statically places where you're not correctly handling the absent values, you do have a much bigger problem than using bool.

My thinking is that over time I can incrementally codify many of these individual "taste" components as prompts that each review a change and propose suggestions.

For example, a single prompt could tell an llm to make sure a code change doesn't introduce mutability when the same functionality can be achieved with immutable expressions. Another one to avoid useless log statements (with my specific description of what that means).

When I want to evaluate a code change, I run all these prompts separately against it, collecting their structured (with MCP) output. Of course, I incorporate this in my code-agent to provide automated review iterations.

If something escapes where I feel the need to "manually" provide context, I add a new prompt (or figure out how to extend whichever one failed).

The gcreep was a huge wake up call for Google, back in ~2010 when this happened. I can tell you that Google took very drastic action internally as a direct result of this (my estimate is that it spent about 100 engineer years, including some very senior SWEs, in this, though that's just a guess) to make it very unlikely for this (an SRE abusing production access) to ever happen again. I'd still say that one incident in 20+ years is a huge success given the scope.

Agree.

I try hard to push the validation to static checks, but it can't always be done. For example:

- a "probability" represented as a double must always be between 0 and 1

- A vector of values given to some group of functions must always be sorted (by some given order)

But even in those cases, using types allows me to ensure that this validation always happens (when the type instance is created). It also let's me avoid having to explicitly validate this inefficiently (e.g. redundantly in preconditions in functions that receive these values).

This doesn't change the fact that static validation is a better approach, but compliments it.

I wrote a bit about it here: https://github.com/alefore/weblog/blob/master/edge/correctne...

Not op, but for productivity, I'll mention one example: I use it to generate unit tests for my software, where it has saved me a lot of time.

Yeah, that's exactly my experience. After switching from managing to a senior (L7) IC position at Google, most of what this article mentions continued to apply to my work.

What does partying have to do with this? If anything, strong party goers are more likely to be night owls who sleep in?

Very cool!

I've also been writing my own terminal text editor for a while (just crossed the ten years mark!), so I know how much dedication this takes. :-)

One thing I did recently was start writing the lessons I've learned in my journey, I figured I'd share it in case it helps you, maybe you'll find one or two ideas interesting: https://github.com/alefore/weblog/blob/master/edge-lessons.m...

> I think a lot of people actually do get rich investing.

https://youtu.be/H5jPJQ5cVGU?si=KoXd4H3FOkLZ1y06 has an interesting counter-point. You need to fuel your returns with savings.

I guess it's a subtlety — in the end, since you said "for decades", and if you adjusted your wording sightly (such as "help you reach your financial goals", instead of "get rich"), the underlying message is similar. But I figured I'd share the link in case you find it interesting.

I think you're right. But I still think the quote from Graham is terrible writing: confusing, brittle, convoluted, almost as if it was designed to hide something from readers and manipulate them into a different understanding than what it actually claims.

The quote is, as you explain, technically correct due to its use of "always". Take this word away and the sentence is correct English, but the meaning now is incorrect (and would match the interpretation of the comment you replied to). Making the correctness hinge so directly in the subtlety of the presence of the quantifier makes the sentence brittle and convoluted.

It feels almost manipulative, as if the writer hopes the reader won't inspect the sentence so closely (and thus will miss this subtlety) and will understand something slightly different ("if you don't write, it's impossible to have clear thoughts"), so that the conclusion sounds much stronger. And readers do get the incorrect interpretation, as evidenced by the comment you replied to, which attacks the misunderstanding of that sentence.

So while I fully agree with you, I still think the sentence quoted is an example of terribly unhelpful and confusing writing. Especially because the full premise "writing down your ideas _always_ makes them more precise and complete" is debatable (you just need to find one counterexample).

(Incidentally, my recollection of Graham's writing is that this type of misleading sentences (that are technically correct but appear to say something else, something that isn't), as if they were deliberately cultivated.)

A much better sentence would be something like:

* "Writing down your ideas is great to make them more precise and more complete. It's hard to have fully formed ideas about a topic without writing about it." This matches the understanding of a quick glance of the sentence.

* "Writing down your ideas always makes them more precise and complete." Closer to the actual meaning, but doesn't do a slight of hand to hide the main point.

At least better editing than this terrible writing:

> Six hours she had been officially dead. Six times had the hour hand on the clock moved – and she had lain dead.

Especially when a few paragraphs below they say:

> If you want to exclude your Customer Data from helping train Slack global models, you can opt out.

So Customer Data is not used to train models "used broadly across all of our customers [in such a way that ...]", but... it is used to help train global models. Uh.

I'm from Colombia and mostly say "plátano".

OK, I've adjusted the output accordingly (https://github.com/alefore/knit/commit/b08f1d1957acf7b37c2cf...).

Oh, good point, I might swap them. I think you're right.

I sometimes print something like "8(K P)" where I think putting the number in front makes more sense. But yeah, I think if there are no parentheses, I should just print it as you suggest.

Thank you!

Thank you!

Mouse over each abbreviation and you should see a tooltip. This specific row would mean "2 knit, Knit Front Back, 6 knit, with yarn in front 3 slip."

This may also help: https://en.wikipedia.org/wiki/Knitting_abbreviations

Good point. I'll look into that. Thank you for the feedback.

(You can swipe left/right to change rows on mobile; though your suggestion still stands. Just mentioning it in case it helps.)

I absolutely intend to expand the scope to include other designs.

I happen to be knitting a double-knitting blanket right now, my first double-knitted project, haha. I was actually thinking yesterday that it would be super neat if we could just feed it a black-and-white image and have it generate the rows. ... just haven gotten around to it.

But, yeah, if you look at the implementation, you'll see that everything is fairly generic, and the only parts specific to sophie scarfs are contained in a single file: https://github.com/alefore/knit/blob/main/scarf_pattern_fact...

That said, I expect the pattern class will need some improvements to be able to accomodate double-knitting (e.g., for visualization and such).

Would love to hear if it works for her, or if she has any feedback.

Not very surprising. He had already been arrested, back in 2002, for selling illegal stuff on eBay. He was somewhat of an attacker of Bitcoin, promoting his "bcash" fork.

This comment reminded me of famous quote: "When someone says "I want a programming language in which I need only say what I wish done," give him a lollipop."

I though this was the case, but Googlers will receive Dividend Equivalent Units on unvested GSUs on each dividend payment date.