Hacker News Reader

Comment by fukuwata | Hacker News Reader

I'm still surprised that there'd be an element of uncertainty. Wouldn't you want to be sure that your code would pass before pushing it out for others to see? What if you pushed and the CI gave you a red X, wouldn't you then feel bad when your coworkers see that and think you are a poor coder? Seems to me it'd be best to be absolutely sure everything would pass before letting anyone else read the code...

View on HN

"Absolutely sure" isn't an achievable level of surety, because everything has a chance of failure, however small.

You could go for "NASA sure", which is when you spent 100x the effort of the average tech company making sure only some of your spacecraft explode on launch, or you could go for "Github sure", which is when you spend a large chunk of your $200+ million ARR to ensure your core product only has a couple of major outages every year, or you could go for "startup sure", which is when your test coverage is 5% and you throw random stuff into production to see who complains, but you can't ever achieve "absolutely sure".

It's worth noting that you can absolutely apply every level of "sureness" within the same company - and such gradation can be very effective if applied smartly.

A failing CI build should not be taken as indication of being a "poor coder". As others have said, in complex systems running every single tests locally can be very time consuming, or even impossible. In my opinion, if you work in an environment where being seen as poor coder because of failed CI builds is a real concern, that speaks more to the potential toxicity of the work environment and/or insecurity of the coder.

I think you are missing the whole point of CI. It has nothing to do with detecting if you are a poor coder (though it will do that too). CI catches issues in the working of multiple components together in your app, presumably coded by different people, possibly but not necessarily geographically apart, as fast as possible - hence the continuous. The key point is integration - there might be issues that your unit tests that you run before pushing the code won't catch, which CI will.

I would go out on a limb and say that the dev teams you have worked with have cultural issues about openness and saving face, and/or you have not worked on big enough (in terms of devs, LOC, distributed-ness) codebases. I might be wrong.

All kinds of strange things happen that cause a build to Work On My Machine and not work on the server. The most common cause I’ve found for things to build on my machine and not the build server are external dependencies that were mis referenced.

Reply on news.ycombinator.com