HackerLangs
TopNewTrendsCommentsPastAskShowJobs

jkaptur

2,467 karmajoined 12 वर्ष पहले
Contact: [email protected]

comments

jkaptur
·3 दिन पहले·discuss
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.)
jkaptur
·2 माह पहले·discuss
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.
jkaptur
·2 माह पहले·discuss
> 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...
jkaptur
·4 माह पहले·discuss
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
jkaptur
·5 माह पहले·discuss
Canonical essay on this sort of technique: https://www.joelonsoftware.com/2005/05/11/making-wrong-code-...
jkaptur
·5 माह पहले·discuss
To be fair, many of those films do not portray human drivers in the best light.
jkaptur
·6 माह पहले·discuss
(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.
jkaptur
·6 माह पहले·discuss
https://www.jkaptur.com - I have some plans to add more content, but who doesn't? :)
jkaptur
·6 माह पहले·discuss
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
jkaptur
·7 माह पहले·discuss
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).
jkaptur
·7 माह पहले·discuss
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.
jkaptur
·8 माह पहले·discuss
"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.
jkaptur
·8 माह पहले·discuss
I've heard this called "A Duck"

https://blog.codinghorror.com/new-programming-jargon/#:~:tex...
jkaptur
·पिछला वर्ष·discuss
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.
jkaptur
·2 वर्ष पहले·discuss
My hypothesis would be that companies with poor operational practices are more likely to underperform the index and have data breaches - in other words, that the study confuses cause and effect.

This wouldn't be that hard to test. I suspect that the breached companies underperformed in the six months before the breach as well as the six months after.
jkaptur
·2 वर्ष पहले·discuss
Sounds like this person: https://en.wikipedia.org/wiki/Richard_Ragan
jkaptur
·3 वर्ष पहले·discuss
To be fair, that's basically the only way to play Diplomacy.

https://grantland.com/features/diplomacy-the-board-game-of-t...