Hacker News new | ask | show | jobs
by solomonb 138 days ago
> After I “Requested changes” he’d get frustrated that I’d do that, and put all his changes in an already approved PR and sneak merge it in another PR.

This is outrageous regardless of AI. Clearly there are process and technical barriers that failed in order to even make this possible. How does one commit a huge chunk of new code to an approved PR and not trigger a re-review?

But more importantly, in what world does a human think it is okay to be sneaky like this? Being able to communicate and trust one another is essential to the large scale collaboration we participate in as professional engineers. Violating that trust erodes all ability to maintain an effective team.

4 comments

Collaborative software development is a high-trust activity. It simply doesn't work in low-trust environment. This is not an issue with code review, it is an issue with maintaining a trust environment for collaboration.
It really demotivated me when this happened, I just kept seeing the PR open, but then I saw the changes applied before the PR was merged, which made me very confused. I then had an alert placed on every one of the updates made by Mike to make sure he didn't do this again. People were against "reset reviewers on commit" for "agility".
TFA wouldn’t blame ‘Mike’ but I definitely would. And ‘Mike’s Boss.

That’s not just a process error. At some point you just have to feed back to the right person that someone isn’t up to the task.

Yeah this never happened. This just sounds like an and everyone clapped moments, made to make a blog post. Most people on this planet are reasonable if not pushed.
I actually had someone like "Mike" in my most recent job (though he wasn't uncooperative, just didn't seem to care about writing proper code). He made some tool using AI and i took it over to clean it up and improve it, but he still worked on it too. He got occasionally annoyed when i suggested changes and sometimes i felt i was talking to ChatGPT (or whatever AI he used, i don't know) via a middleman. He didn't put any 1600 line PR (that i remember anyway) but he did add extra stuff to his PRs which were often related to other tasks and the code submitted was often much larger in "volume" than needed.

As an example there was a case where some buttons needed a special highlight based on some flag, something that could be done in 4-5 lines of code or so (this was in Unreal Engine, the UI is drawn each frame), but the PR was adding a value indicating if the button would need to be highlighted when the button was created and this value was passed around all over the place in the up to the point where the data that was used to create the UI with the buttons would be. And since the UI could change that flag, the code also recreated the UI whenever the flag changed. And because the UI had state such as scrolling, selected items, etc, whenever the UI was recreated, it saved the current state and restored it after it was recreated (together with adding storage for the state). Ultimately, it worked, but it was too much code for what it needed to do.

The kicker was that the modifications to pass around the value for the flag's state wasn't even necessary (even ignoring the fact that the flag could have been checked directly during drawing) because a struct with configuration settings was already passed through the same paths and the value could have been added to said struct. Not that it would have saved the need to save/restore the UI state though.

I'm not sure how to prove otherwise, but this actually happened to me. I don't understand this kind of comments saying "FAKE" for views or blog-posting. This is something that happened to me, and I can say for sure people were really pushed in this situation to ship faster every time.
I envy the type of career you’ve had if you find this sort of behaviour unbelievable.
I don’t know how you ever get the opposite, in been working for 12 years now at 6 different jobs everyone has been fine at the job apart from a cheeky hack here or there.