Live data from Hacker News

You're Not a Better Engineer Because You Type Git Commands by Hand

minid.net

91–100 of 157 posts

Re: You're Not a Better Engineer Because You Type Git Commands by Hand

#91
post #76

Earlier quoted context omitted.

I disagree. Abstractions are not a convenience, they're a cognitive necessity , compressing large aspects of the problem space into easy to not think about blocks, allowing humans, with their limited working memory, to reason about larger problems. The only reason a seasoned developer can think at a high/system level is because of the abstractions/compressions they've formed in their heads. Technology exists to make…

There are plenty of people who understand the stack and ship actually fast software. This might be a skill issue that you’re choosing to frame as a “best practice”, because you do not want to put in the work. Our end users are who should benefit. You’re the pilot in the seat who doesn’t know what the throttle is and you’re telling the passenger it’s the plane’s fault it’s slow.

[deleted]

Re: You're Not a Better Engineer Because You Type Git Commands by Hand

#92
> Then, when it was time to review or merge something, we spent even more time digging through the code just to understand what the commit or PR was supposed to do.

> Now I delegate that work to AI.

> […]

> If one day passes and nobody on the team reviews the PR, we merge it

It’s not clear to me whether or not the author is reviewing the code their agent is committing on their behalf, so maybe I shouldn’t be surprised that they don’t seem to care whether or not their team is reviewing it either.

But I am surprised. The author says they used to spend quite a lot of time writing developer guides, hopefully by building consensus among their peers. It seems to me like a big shift if it’s now a workplace where they might not even read each other’s code changes.

Or maybe the dev guides were top-down directions on the way they want the team to do things, and now AI is super compliant and they’re living the dream.

Re: You're Not a Better Engineer Because You Type Git Commands by Hand

#93
post #48

At the end of the day LLM output is not deterministic, and the burden shifts from writing code to reviewing it. It makes sense to cover the review surface with deterministic checks/validations as much as possible - unit test, linters, static analysis tools, e2e integration test etc. one gap I noticed when it comes to such tools is that they are generally language/stack specific and don't cover things like file/direct…

I have my own tooling set in every project https://www.minid.net/2026/6/1/my-ai-workflow. I have couple dozens of make commands, that perform all the checks. I can do them manually after I finish coding or, I relegate these to the AI. If something is wrong, that's when I intervene. If nothing is wrong, that's because I've spent quite some time checking every single change.

Re: You're Not a Better Engineer Because You Type Git Commands by Hand

#95
Funny how all that stuff one spends so much time and effort learning was "a waste of time and effort" to everyone that has zero idea how anything works "under the hood", but the moment it breaks, you're always the guy that has to fix it in the end. I honestly believe that's one of the biggest contributing factors to "developer burn-out". Being ignored and ridiculed repeatedly (Shut up, Nerd. Nobody wants to hear you yammer about how to waste more time on backups and security.) until something breaks and then being called on to fix it like you're some sorta robot or something... (It's fixed? Great! Back to your cubicle now, code monkey!) And now all the scumbags at the top want to replace us all with "AI"? I mean, why even bother anymore? What's the point? Where's the reward for all the hard work and caring about doing a good job? What? Another kick in the nuts while I'm already down? That's the reward? Gee, thanks Boss... May I have another?

Re: You're Not a Better Engineer Because You Type Git Commands by Hand

#96

What is with all these people that are so interested in other people's workflow to the point of writing weirdly aggressive manifestos like this. "If you don't do it like me, you're wrong!" I would like to be the first person to state that I don't give a damn about your workflow . Do whatever you want!

screaming for attention really.

Re: You're Not a Better Engineer Because You Type Git Commands by Hand

#97
post #31

Eh, agents commits are always too verbose. I don't need a 3 paragraph mini novel. Design can go in a design docs folder, project info goes in the issue tracker. The commit should be a short summary <1 paragraph for quick context

I instruct the agents to do the commit messages they way i want them written. They don't produce a book everytime, they produce what I think it's useful.

Re: You're Not a Better Engineer Because You Type Git Commands by Hand

#98
post #71
post #26

Earlier quoted context omitted.

How do you justify it against all the other abstractions you've accepted and no longer know how to do (or never learned in the first place). Why are the current set of manual steps the right level to be permanently aware of?

I think it's a good idea to learn how to work through those levels of abstraction, even if only academically, since it yields a lot of insight into why our current abstraction level is the way it is. I don't personally use git CLI on a day to day basis (I use a gasp GUI) but I know what a rebase is and how to recover from a variety of bad states using CLI alone during an emergency. Being aware of how commits actually…

Manual knowledge of git to get out of tricky situations will be as passe as using log book for multiplication. It's just not required anymore.

Re: You're Not a Better Engineer Because You Type Git Commands by Hand

#99
post #40

These days, I am leaning heavily on Claude to deal with all the git issues that I never wanted to be bothered with. A rebase that can't just fast-forward? That's a job for Claude. A merge conflict that really shouldn't be a problem? Claude deals with it. These are things I never wanted to have to learn in the first place, and I don't feel like reserving a part of my brain to remember how to deal with these things is…

A rebase that can't just fast-forward? That you know what that is makes you the right kind of person to be delegating it to an LLM; you can be trusted to use the LLM for this sort of thing because you understand what the problem is, what the right outcome should be, and how to know when it's been done correctly. It's the person sitting behind you who doesn't understand any of those words who is going to do something…

I feel like if the logic in git were just a bit more sophisticated, many of these issues wouldn't even arise. Most of these are because someone foolishly (usually me) merged in the wrong direction for convenience's sake, and now I have a duplicated set of commits. It's not like Claude is doing anything very sophisticated; it's just looking at commit hashes and seeing what the unique changes are.

Re: You're Not a Better Engineer Because You Type Git Commands by Hand

#100

Commit messages now do double duty: log of the changes, but also signing off that you've read and understand the code, are taking responsibility for it under your own name. The second part is an emerging convention but it's fairly common from what I've seen. IDK maybe no one will be reading or writing code in 18 months but if they are we'll need to separate these two things. Secondarily but probably more importantly:…

[dead]
Post reply on HN