Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

minid.net

Post reply on HN
Print view View original

71–80 of 157 posts

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

#71

Post by munk-a »

yulker wrote: post #26
alex_x wrote: post #8

All above comes at a cost of author slowly starting to understand less and less code in their own projects. Then in other projects as well. After the initial boost is over they will have to pay money just to stay afloat because they have already outsourced their thinking. I’m not anti AI, but I’m very worried about this bragging “you are not better engineer if you do things yourself”. Yes, you are, it all comes in sm…

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 works lets me know when I can rebase, squash and manipulate history in a safe manner and when such manipulations are likely to cause headaches to those around me.

The window of what steps technical people should understand in our stack of abstraction is always changing - there is no permanent window we should hold as sacred (outside of a cursory knowledge of the lowest of low levels - being passingly familiar with how machine code works is valuable to everyone) but the levels we should be aware of should exceed the levels that we casually interact with - we should at least be rather comfortable with the level one deeper than the one we often interact with.

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

#72

Post by rspeele »

thunderfork wrote: post #14

Picking on a particular nit here, but I think it is indicative of the broader flaw with this argument: To rename `PostgreSQLClient`, I press F2 and type the new name, and I'm done. I don't have to wait for an agent to "perform the refactor, update references, run the tests, fix the missing pieces, and mark the relevant checkboxes in the ticket" (btw, what checkboxes..?) I press a key, type my change, and I'm done. Wa…

Despite having long valued statically typed languages, and IDEs with excellent refactoring tools (VS + ReSharper was a godsend back in the day before MS implemented most of the must-have features themselves)... I sort of disagree.

The problem is the IDE refactor->rename updates the code but the agent's "rename" will also catch developer-facing documentation in text files, comments, etc. that referenced the old name. It will often even catch reflection code that referred to the old name in a string. And it will do the mental work of disambiguating "this reference is something else that shouldn't be updated, that one is really pointing at the thing that got renamed and should be updated". If asked to, it can catch things like "var postGresClient = new PostgreSQLClient()" and change them to "var dbClient = new DatabaseClient()".

My preconception was: the IDE feature is deterministic and works every time. The LLM may hallucinate and fail to correctly do the rename, so it's both slower and worse.

My actual experience has been: So far, I've never actually seen Opus or GPT5.5 hallucinate and fail at a simple refactoring task like this, but I have had numerous instances where it caught extra stuff that a deterministic rename never could, and therefore did the task slower and much better.

I hate it because it feels lazy and stupid to type "do this trivial thing for me" into a prompt box. But dammit, it works too well.

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

#73

Post by nimih »

Something I've personally noticed over the years is that when I take the time to hand to write thoughtful commit messages, the overall quality of my technical work tends to increase as well. My theory is that the process, while boring and time-consuming, forces me to think holistically about how my current task fits within the system and find gaps in my own understanding and implementation. I sympathize with the author's impulse to ignore these tedious details (I, too, love slacking off at work), but, at least for myself, my decades of (admittedly unstructured) A/B testing "how good is the software I write if I don't do this" unambiguously points to it being a somewhat load-bearing piece of my effectiveness as a software developer.

Of course, if you're just optimizing for the amount of slop you can shove into github each week to appease your manager/PM, then yeah just let the chatbot write the commit messages too.

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

#75

Post by EliRivers »

CyLith wrote: 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 dangerous at LLM-accelerated speed I'm concerned about.

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

#76

Post by nomel »

TheSamFischer wrote: post #44
yulker wrote: 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?

Abstractions are convenience. They’re not free, there is a cost to any work you ask the computer to do. Just staying at the surface level and never understanding what’s under the top level is why software is slow and bloated today. You’re supposed to move beyond the abstraction, understand what you need underneath and use what you really want to do the task. No wonder we boot up entire browser engines to write simple…

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 it so we don't have to think about/put time into low level things, so we can do more interesting things instead. Not thinking about banal things is the foundation of progress.

AI seems to be the give us an abstraction I've been waiting for: a method to write code at the level of libraries , with libraries working with/adapting to other libraries.

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

#77

Post by ajju »

alex_x wrote: post #8

All above comes at a cost of author slowly starting to understand less and less code in their own projects. Then in other projects as well. After the initial boost is over they will have to pay money just to stay afloat because they have already outsourced their thinking. I’m not anti AI, but I’m very worried about this bragging “you are not better engineer if you do things yourself”. Yes, you are, it all comes in sm…

Your statement is technically correct (and mirrors my initial feelings) but the comment below that notes that we accept many other abstractions seems more “meaningful” in the larger scheme of things.

For instance, a software engineer who also understands how to design microprocessors would indeed in my own evaluation be a “better engineer” than me (someone who does not). Yet, I wonder if they would be meaningfully more productive than a good software engineer who “just” understands how microprocessors work..

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

#78

Post by meerita »

alex_x wrote: post #8

All above comes at a cost of author slowly starting to understand less and less code in their own projects. Then in other projects as well. After the initial boost is over they will have to pay money just to stay afloat because they have already outsourced their thinking. I’m not anti AI, but I’m very worried about this bragging “you are not better engineer if you do things yourself”. Yes, you are, it all comes in sm…

[flagged]

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

#79

Post by meerita »

brunooliv wrote: post #29

So on one hand it states: Delivery is becoming a sequence of checks, not a ritual The same thing happens when it is time to deliver. First, I invoke my /definition-of-done skill. It checks whether the implementation covers what was stated in the PR and in the plan. It checks tests and the other validations I care about. It tells me when something looks unusual, broken, or missing. When everything looks good, I invoke…

I wrote software before Stack Overflow existed, before Git existed, and before most of the tools I use today existed. I think I will survive an API outage :)

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

#80

Post by TheSamFischer »

nomel wrote: post #76
TheSamFischer wrote: post #44

Earlier quoted context omitted.

Abstractions are convenience. They’re not free, there is a cost to any work you ask the computer to do. Just staying at the surface level and never understanding what’s under the top level is why software is slow and bloated today. You’re supposed to move beyond the abstraction, understand what you need underneath and use what you really want to do the task. No wonder we boot up entire browser engines to write simple…

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.

Post reply on HN