jkaptur

Putting cynicism aside (there's plenty of that here already): there is a theory that people invest in index funds because they don't want to pick individual stocks. They want exposure to "the public stock market as a whole". I think there are good arguments on both sides of including SpaceX in such an index.

When you say you support "all Excel formulas", which version of Excel do you mean? I assume you don't support CALL and REGISTER... https://support.microsoft.com/en-us/excel/using-the-call-and...

The other thing to keep in mind is that if you have a policy of considering 98% to be "close enough", then it only takes 35 of those decisions to remove over half the population. And it'll be exceptionally difficult to work your way back up, because each improvement will be minimal!

(Of course, this assumes that each decision is independent, which, when you're talking about browser support for CSS, is certainly not the case.)

I’m not an expert here, but it sounds like you’re forcing a first-order logic problem into a propositional logic box.

A “native” first-order logic solver like Z3 might be something to try.

> I personally don’t know any colleagues who were good engineers just because they wrote code faster.

However, the best engineers I know are usually among the quickest to open an editor or debugger and use it fluently to try something out. It's precisely that speed that enables a process like "let's try X, hmm, how about Y, no... ok, Z is nice; ok team, here are the tradeoffs...". Then they remember their experience with X, Y, and Z, and use it to shape their thinking going forward.

Meanwhile, other engineers have gotten X to finally mostly work and are invested in shipping it because they just want to be done. In my experience, this is how a lot of coding agents seem to act.

It's not obvious to me how to apply the expert loop to agentic coding. Of course you can ask your agent to try several different things and pick the best, or ask it to recommend architectural improvements that would make a given change easier...

It's interesting to contrast "Measure. Don't tune for speed until you've measured" with Jeff Dean's "Latency Numbers Every Programmer Should Know" [0].

Dean is saying (implicitly) that you can estimate performance, and therefore you can design for speed a priori - without measuring, and, indeed, before there is anything to measure.

I suspect that both authors would agree that there's a happy medium: you absolutely can and should use your knowledge to design for speed, but given an implementation of a reasonable design, you need measurement to "tune" or improve incrementally.

0: https://gist.github.com/jboner/2841832

Canonical essay on this sort of technique: https://www.joelonsoftware.com/2005/05/11/making-wrong-code-...

To be fair, many of those films do not portray human drivers in the best light.

(I'm not an expert. I'd love to be corrected by someone who actually knows.)

Floating-point arithmetic is not associative. (A+B)+C does not necessarily equal A+(B+C), but you can get a performance improvement by calculating A, B, and C in parallel, then adding together whichever two finish first. So, in theory, transformers can be deterministic, but in a real system they almost always aren't.

https://www.jkaptur.com - I have some plans to add more content, but who doesn't? :)

There are two extremes here: first, the "architects" that this article rails against. Yes, it's frustrating when a highly-paid non-expert swoops in to offer unhelpful or impossible advice.

On the other hand, there are Real Programmers [0] who will happily optimize the already-fast initializer, balk at changing business logic, and write code that, while optimal in some senses, is unnecessarily difficult for a newcomer (even an expert engineer) to understand. These systems have plenty of detail and are difficult to change, but the complexity is non-essential. This is not good engineering.

It's important to resist both extremes. Decision makers ultimately need both intimate knowledge of the details and the broader knowledge to put those details in context.

0. http://www.catb.org/jargon/html/story-of-mel.html

Another point is that the world is always changing. If you work slowly, you are at much greater risk of having an end result that isn't useful anymore.

(Like the author, of course, I'm massively hypocritical in this regard).

I think that there are three relevant artifacts: the code, the specification, and the proof.

I agree with the author that if you have the code (and, with an LLM, you do) and a specification, AI agents could be helpful to generate the proof. This is a huge win!

But it certainly doesn't confront the important problem of writing a spec that captures the properties you actually care about. If the LLM writes that for you, I don't see a reason to trust that any more than you trust anything else it writes.

I'm not an expert here, so I invite correction.

"Couples often flake together. This changes the probability distribution of attendees considerably"

It's interesting to consider the full correlation matrix! Groups of friends may tend to flake together too, people who live in the same neighborhood might rely on the same subways or highways...

I think this is precisely the same problem as pricing a CDO, so a Gaussian Copula or graphical model is really what you need. To plan a great party.

I've heard this called "A Duck"

https://blog.codinghorror.com/new-programming-jargon/#:~:tex...

PowerPoint actually fine

  - bad communication possible in any medium
  - pptx in NASA even today!
  - issue is managers/SMEs communication differences
    - issues with technical papers
      - long
      - boring
  - vs word, excel, pdf...

(Next slide please)

Manager/SME Differences

  - context vs conclusion 
  - tell a compelling story
    - but give away the ending FIRST 
  - inherent personality differences
  - motivations/incentives/mindsets

(Next slide)

Learning from disasters

  - medium guides message and messenger
  - blame tool - binary choice?
  - presentation aide vs distributed technical artifact

(Next slide)

Questions?

"... if all knowledge were stored in a structured way with rich semantic linking..." this sounds a lot like Google's "Knowledge Graph". https://developers.google.com/knowledge-graph. (Disclosure: I work at Google.)

If you ask an LLM where you can find a structured database of knowledge with structured semantic links, they'll point you to this and other knowledge graphs. TIL about Diffbot!

In my experience, it's a lot more fun to imagine the perfect database like this than it is to work with the actual ones people have built.

This essay would benefit from results from computational complexity.

P vs NP, of course, but also the halting problem and Rice's theorem: non-trivial semantic properties of programs are undecidable.

In other words, if you say "this is the solution to that sudoku puzzle", that's easy to verify. "This sudoku puzzle has a solution" is almost certainly much harder to verify. "Here's a program that can solve any sudoku puzzle - impossible (in general).

Google was founded in 1998 and you could buy ads on the search results page in 2000. https://googlepress.blogspot.com/2000/10/google-launches-sel...

Beyond "very likely", it's right there in the paper:

https://snap.stanford.edu/class/cs224w-readings/Brin98Anatom...

"The research described here was conducted as part of the Stanford Integrated Digital Library Project, supported by the National Science Foundation under Cooperative Agreement IRI-94 11306. Funding for this cooperative agreement is also provided by DARPA and NASA, and by Interval Research, and the industrial partners of the Stanford Digital Libraries Project."

Really? That’s very surprising. You can see what this says? https://docs.google.com/document/d/1uYM0vyZiDJbo-5mXmU_6Xtrz...

> If you aren’t sure what your cofounders are doing, trust your git instinct.

That's good advice to not lose your HEAD.

Validation can serve the purpose of communicating that one person deeply understands the other's problem.

Including https://xkcd.com/2128/

I'm interested in learning more about the benefits of MECE - I've never heard that before. In particular, it seems radically different from Divio's system [0], which presents the same information in many different ways.

0: https://docs.divio.com/documentation-system/

I think that’s the rose colored glasses again. What made you choose Toy Story as an example rather than Waterworld or Cutthroat Island?

Ah ha! Thank you for explaining.

How does the verifier gain confidence that the prover has solved a particular instance of a sudoku puzzle?

I can't wait to read that blog post. I know you're an expert in this and respect your views.

One thing I think that is missing in the discussion about shared data (and maybe you can correct me) is that there are two ways of looking at the problem: * The "math/engineering" way, where once state is identical you are done! * The "product manager" way where you have reasonable-sounding requests like "I was typing in the middle of a paragraph, then someone deleted that paragraph, and my text was gone! It should be its own new paragraph in the same place."

Literally having identical state (or even identical state that adheres to a schema) is hard enough, but I'm not aware of techniques to ensure 1) identical state 2) adhering to a schema 3) that anyone on the team can easily modify in response to "PM-like" demands without being a sync expert.

I didn't quite follow how you can actually prove that you've solved a sudoku via reduction to graph coloring. If I understand correctly, an important part of the graph coloring protocol is that the prover permutes the colors between each round (otherwise the verifier can just iteratively learn the color of every node).

But all sudoku puzzles have the same graph structure - a puzzle instance is a partial assignment of colors to nodes.

So can't a verifier can gain knowledge about the prover's solution by asking for edges that correspond to known values?

(I found a different ZKP protocol for sudoku, but I don't think it relates to the graph coloring protocol: https://www.wisdom.weizmann.ac.il/~naor/PAPERS/SUDOKU_DEMO/)