skydhash

15 ms·

331.
by skydhash 3mo ago
> Sure, you can probably comb the complete 100 or 1000 or 10,000 line PR to find the exact lines that caused that regression, you've narrowed down already to one useful haystack But the PR is one single atomic changes. even if it 10
332.
by skydhash 3mo ago
“make the foobar extensible” has no value without also “adding baz”. If I need to remove baz, I can’t just revert “adding baz”. The extensible foobar needs to go as well because it’s a unused abstraction.
333.
by skydhash 3mo ago
The common stance is that people try to use said API without reading the docs. Like the first paragraphs of the git-rebase description Transplant a series of commits onto a different starting point. You can also use git rebase to reorde
334.
by skydhash 3mo ago
> you have an opportunity to drill down into the even smaller specific change inside that PR that introduced the issue. But what would be the point? Let’s say you found an issue in the first commit of the PR (assuming it’s curated and ev
335.
by skydhash 3mo ago
Yep, the curated history is the main branch, which the PR targets. The commit log in the Pr reflects the workflow of the author, which I have no interest in. As the reviewer, I’m only interested in the content (the description and the compo
336.
by skydhash 3mo ago
The only point not addressed by reviewing changes at a PR level instead of a commit level is 7. Break up large changelists First a PR shouldn’t introduce scope screep, where you are actually introducing more than one change. And seco
337.
by skydhash 3mo ago
In most business settings, the ticket is the unit of value to the business. If a ticket is to big, the best way is to split it into several ticket. Then you create a PR for each. There can be some automation that update the status of the ti
338.
by skydhash 3mo ago
Not really, because that one commit represent a logical changes to the codebase. It’s either in or not. Splitting it would be only cosmetic. That’s what a good PR in my opinion. Presenting a series of patches is good in an email format beca
339.
by skydhash 3mo ago
For me (I know you used most, not all). A PR is an atomic thing. Either one bug or one feature. Commits inside it are mostly time snapshots, and fixing formatting and linting errors. If I where to properly present the PR, it will also have
340.
by skydhash 3mo ago
> which is "ours" and which is "theirs" "ours" is always HEAD, usually meaning the state of the working_tree, "theirs" is always the commit that is going to change the working_tree. When merging,
341.
by skydhash 3mo ago
Git store whole files. The diff and the merge algorithm works by line by default, but that's because line is a rough unit of code (statement, expression, and definition happens mostly within one line).
342.
by skydhash 3mo ago
> Working with lots of changes in parallel on git can be painful. You end up juggling branches and commits, and running scary rebase -i commands that can leave your tree in a half-broken state if you so much as sneeze. I think that only
343.
by skydhash 3mo ago
I kinda love it, because verbosity means you have to rely on completion and that has a negative impact on retention. And the terseness is good when you’re familiar with the code.
344.
by skydhash 3mo ago
> You tell me what to do with that. That if you polish it a bit, you can probably write a short story. /s The thing is, making claims like that doesn’t prove anything. You have to either show the result or prove that is reproducible
345.
by skydhash 3mo ago
Reaching the correct outcome is easy. That’s what happy path means. The time sink is all the error cases, ensuring that one of the transition in the system does not result in an unsatisfactory outcome. That’s why we read code. Because only
346.
by skydhash 3mo ago
> I often spend hours with an LLM refining architecture, exploring alternate directions, trying to find alternate directions in the first place, clarifying design questions, Is that something recent? I’ve been doing this for years, even
347.
by skydhash 3mo ago
They don’t care about the switch and it seems they’re actually happy with it. What they care about is the implied messaging that Zig has issues that the rewrite in Rust solved. Andrew highlighted that they had bad engineering practice, the
348.
by skydhash 3mo ago
> Just because people can get away with using AI to make A apps that are "good enough" or pass test suites That requires some proof, because the trend is that users of A apps dislike the lack of engineering that comes with AI i
349.
by skydhash 3mo ago
I trust myself to write good code, but I’ve been under pressure to rush things and extra features in Java, C#, TypeScript are really great on those occasions. I love C and Perl, but as you say, there’s not a lot of safety harness. A lot of
350.
by skydhash 3mo ago
Lol, I just don’t rush into coding when I could talk with the customer/user (or Product). And I shape my codebase into something I can easily experiment upon. Which means I try for it to be modular with suitable abstraction that I can
351.
by skydhash 3mo ago
> Who hasn't come up wit the most perfect elegant design, only to come up against three reality of implement and an "oh we forgot about that" aspect The mistake here is trying to come up with the most elegant design. You s
352.
by skydhash 3mo ago
> Weird bugs, surprising behaviors, spec ambiguities, library defects, mysterious test failures, etc. Stuff that requires intense debugging and building out a mental map of code that might not even be yours And those issues often appears
353.
by skydhash 3mo ago
> Rust, strong types, enums, fantastic interfaces, brevity. That's not what suitable data structures/algorithms mean. What you stated are mere helpers and still pertains to the realms of coding, not design. Coding isn't an
354.
by skydhash 3mo ago
> My output sometimes rivals that of entire teams' I've been part of, mostly because I get to just code to my heart's content. The fact is that often I code less than most of my peers. Because I prefer spending some time
355.
by skydhash 3mo ago
> The truth is that no one in management cares about your perfect code, they only care about the projects you deliver, the features you push out and the meeting KPIS.. Your customers don't care about your perfect abstractions either
356.
by skydhash 3mo ago
If there's one thing I've remarked, even before LLM tooling, is that there's a class of people that is ready to try things for weeks until it magically work (with no guarantee it will hold), instead of spending one hour desig
357.
by skydhash 3mo ago
> The article talks about this from the users side, how there is a class of user who enjoys learning all of these “extra” features, even though they ultimately provide less value than the core features. With Vim, Emacs, Git,... there&#x2
358.
by skydhash 3mo ago
> That visual feedback is EXTREMELY useful because I learn of the edge cases to what I am editing in bulk (usually formatting code or tables or whatever) as I am editing it I do not disagree with that > When you do a macro, you have t
359.
by skydhash 3mo ago
One of the things about Emacs and Vim is that you have commands that does things. They all have the same conceptual model. In vim, you have the text objects, the motions, and the counts (and more advanced ones like line and pattern addressi
360.
by skydhash 3mo ago
The things about multiple cursors is that you think about the processing while doing it, while most people using macros looks at the structure of the text first and then devise the macro. I wouldn’t say the latter is faster, but it’s a diff

More ›