Live data from Hacker News

Software is made between commits

zed.dev

71–80 of 230 posts

Re: Software is made between commits

#71
post #43

Earlier quoted context omitted.

No I'm paid to write code.

Does that... Not imply thinking avout what you are writing???

Everyone probably has thought "what was the person thinking when they wrote this". Now you know that they probably didn't think (and since 2025 or so, it might not even have been a person).

Re: Software is made between commits

#72
post #63
post #59

Earlier quoted context omitted.

This sounds like it is more aligned with what I have created which is "We need to capture your conversations with AI". If you look at https://github.com/gitsense/gsc-cli/blob/main/internal/cli/r... you can see that every file has a code block header with a UUID and the AI that was attributed to it. With the UUID, I can tell exactly how the code came about. What they are working on will be more useful for AI code prov…

FYI your link 404s. Seems like you copied the ellipsified version, so what we get is https://github.com/gitsense/gsc-cli/blob/main/internal/cli/r

Fixed, thanks!

Re: Software is made between commits

#73
post #53

Earlier quoted context omitted.

This is why I use rebase before PRs, and despise squash. You are not going to remember why you wrote that code that way 2 years from now and all we'll have to understand bugs and identify Chesterton's Fence situations is the deltas and the commit history. If you squash them I have 400 lines of code you 'wrote' all at the same time and only have the feature request it was assigned to as context. Thanks for nothing. Th…

Probably coulda used an example that isn't itself a fourth amendment violation that essentially requires perjury to accomplish. Also less euphemistically called evidence laundering. Not really a neutral example.

A more charitable case is that the source cannot be disclosed because it's an undercover agent or informant. What the parent describes is indeed evidence laundering.

Re: Software is made between commits

#74
post #53

I really don't like this. The code I write between commits is my thinking. I think by writing some code out, deleting it, writing again. The code I write that's shipped in commits is written for others to understand, and is a product of that writing for thinking process. I don't want my thoughts to be serialized, version controlled and publicly accessible. https://www.nature.com/articles/s44222-025-00323-4

This is why I use rebase before PRs, and despise squash. You are not going to remember why you wrote that code that way 2 years from now and all we'll have to understand bugs and identify Chesterton's Fence situations is the deltas and the commit history. If you squash them I have 400 lines of code you 'wrote' all at the same time and only have the feature request it was assigned to as context. Thanks for nothing. Th…

Squash smaller commits?

Re: Software is made between commits

#75
post #54

Earlier quoted context omitted.

Fully agree, very icky surveillance vibes. In particular: > DeltaDB breaks your work into a stream of fine-grained deltas. Where Git captures a snapshot at each commit, DeltaDB captures every operation in between and gives each one a stable identity. I was curious about giving Zed a try, now that it has an emacs keymap. Not anymore. This is such a horribly invasive feature, I absolutely do not want my colleagues revi…

The more I think about it and your comment the more I wish it was local only. It could be useful to analyze your editing habits and interactions with AI but I want that for my own benefit not random coworkers

Yeah I really would not want all my convos synced up like this. I've been working on a personal version of something like this but it keeps all your conversations and notes in a separate Git repo that you control that's totally separate from the project repo - it's entirely designed for personal use:

https://github.com/modulecollective/moe

Re: Software is made between commits

#76
post #49

Earlier quoted context omitted.

Don't be afraid to show your thoughts when asked to. The best developers are those that can express their thoughts clearly at any stage throughout their process. This is one of the skills that shows to me the level of experience a developer has.

One of my professors in undergrad said: the most dangerous mathematicians are the ones that begin the proof with "Consider a case ...". He said that these mathematicians are the ones who don't share anything about how they got the case and they end up projecting this sort of "magician aura". I don't know how accurate that assessment it, but I think it captures something that never sat well with me. In my life, I've n…

Ugh, let's take a step back and make a distinction:

I don't need your fluff. No one cares how you arrived writing another crud line to save an object to database or sent yet another AJAX call.

If you wrote some genuine great compression algorithm that's a different take on compression, I would like to see step by step reasoning and eventual dead ends.

Re: Software is made between commits

#77

I really don't like this. The code I write between commits is my thinking. I think by writing some code out, deleting it, writing again. The code I write that's shipped in commits is written for others to understand, and is a product of that writing for thinking process. I don't want my thoughts to be serialized, version controlled and publicly accessible. https://www.nature.com/articles/s44222-025-00323-4

Aren't you paid to think?

No, you are paid to deliver. Whether you do that by thinking + hand-coding or just vibe-coding, or handing the task description to Cthulhu and waiting for him to materialize the solution on your disk, is immaterial.

Unless of course you also have to explain your thinking and problem-solving process in meetings, which happens quite a lot the more senior you get.

Re: Software is made between commits

#79
post #49

Earlier quoted context omitted.

Don't be afraid to show your thoughts when asked to. The best developers are those that can express their thoughts clearly at any stage throughout their process. This is one of the skills that shows to me the level of experience a developer has.

One of my professors in undergrad said: the most dangerous mathematicians are the ones that begin the proof with "Consider a case ...". He said that these mathematicians are the ones who don't share anything about how they got the case and they end up projecting this sort of "magician aura". I don't know how accurate that assessment it, but I think it captures something that never sat well with me. In my life, I've n…

OTOH polishing up the presentation can really improve the experience of a first-time reader of the work (e.g. your code reviewers). If the polishing is done with good intent and proficiency you can make something that was very convoluted and difficult to arrive at digestible with far less effort. It also aids your own understanding: "If we can reduce it to the freshman level that means we really understand it" (or similar I didn't look up the exact quote, attributed to Feynman). If you're polishing something up to make it understandable that's totally different than polishing it up to make yourself seem smart, right?

Re: Software is made between commits

#80
post #49

Earlier quoted context omitted.

Don't be afraid to show your thoughts when asked to. The best developers are those that can express their thoughts clearly at any stage throughout their process. This is one of the skills that shows to me the level of experience a developer has.

One of my professors in undergrad said: the most dangerous mathematicians are the ones that begin the proof with "Consider a case ...". He said that these mathematicians are the ones who don't share anything about how they got the case and they end up projecting this sort of "magician aura". I don't know how accurate that assessment it, but I think it captures something that never sat well with me. In my life, I've n…

I personally stumble upon many topics where I only care about the what. In that case all the theory is just a distraction I'm just wading through to get to the point. If it's optional, then looking into the how and why is certainly nice, but it should be part of an appendix or a commentary and not interspersed within the proof unless an uncommented version exists.
Post reply on HN