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.
You're Not a Better Engineer Because You Type Git Commands by Hand
91–100 of 157 posts
Re: You're Not a Better Engineer Because You Type Git Commands by Hand
#92> 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
#93At 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…
Re: You're Not a Better Engineer Because You Type Git Commands by Hand
#94"don't believe in yourself, don't deceive with belief"
(David Bowie)
Re: You're Not a Better Engineer Because You Type Git Commands by Hand
#95Re: You're Not a Better Engineer Because You Type Git Commands by Hand
#96What 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!
Re: You're Not a Better Engineer Because You Type Git Commands by Hand
#97Eh, 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
Re: You're Not a Better Engineer Because You Type Git Commands by Hand
#98Earlier 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…
Re: You're Not a Better Engineer Because You Type Git Commands by Hand
#99These 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…
Re: You're Not a Better Engineer Because You Type Git Commands by Hand
#100Commit 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:…