Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I hope this doesn't come off as snarky, but you and your team may find many benefits from making infrastructure changes that prevent anyone from breaking the build. One way we do this is to have CI run for all pull requests, and prevent merges if there are any test failures, and the other is that we have a staging site where we run even more tests to ensure mistakes don't go to production (very often).

The interesting thing is that we programmers still make just as many mistakes -- but there are no angry feelings or animosity when they do because it doesn't hurt anyone else. If I make a pull request that fails linting, or breaks a bunch of tests that I forgot about, it won't affect my teammates, won't get to production, et cetera. It transitions the interaction from "You broke my stuff!" (which causes hurt feelings) to a robot (callously? uncaringly?) informing me that I have more work to do before my stuff is of a caliber that merits merging with the rest of the codebase. Somehow, that doesn't hurt feelings nearly as much.

This also requires the codebase to have extensive enough test coverage that you can trust the tests to catch any breakage -- which requires code review to notice if one forgets to add a test for functionality. The upside is, having that kind of coverage means that you can refactor fearlessly, and can really trust an automated deployment workflow.



Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: