undefined

points

[-]

Shouldn’t you be, in general, separating out new functionality from old fixes?

Shouldn’t those “fixing bugs we gained in the past” be their own MR that can be read, reasoned about and have evaluated test coverage?

by 0110001117 hours ago|

parent|

[-]

Sure and sometimes that is what happens. Sometimes it's not. We should be doing a lot of things, but have to triage issues and act pragmatically.

In the case of what I'm currently working on, filing bugs for every issue I found, and then factoring out each fix, and then running each change through the 8 hour ci/cd system, and hoping an unrelated issue doesn't get misattributed to me... No, I'd rather just wrap it up into one coherent refactoring change and be done with it because when I'm done there are several more like it waiting for my attention.

by t-writescode14 hours ago|

parent|

[-]

I don't know your exact situation; and there are sometimes genuinely valid reasons for an 8-hour CI/CD system; but ... man, reducing that down to like 20 minutes (which is possible and often common) would pay as many dividends as all the AI stuff that's been added. Man, like ... holy crap @_@

by 011000119 hours ago|

parent|

[-]

We're uh.. we're a well known and widely used piece of software. There is an insanely large amount of testing that needs to go in to each change across many platforms and configurations and we have a lot of devs hammering that system with changes to test. Even worse now because of AI...

by blub17 hours ago|

prev|

[-]

Too many comments about AI read like inadvertent admissions of incompetence or dysfunctional projects.

Couple of WTFs that come to mind:

* How many bugs did one have per commit, that commits have to noticeably grow in order to not have those bugs in the first place?

* How does one even do software engineering if the (best) developers can’t reason about the code?

by 0110001117 hours ago|

parent|

[-]

Code debt.

Software engineering is possible but largely a myth in practice.