>Your users to don’t care how your code gets onto your server. I don't like arguments like this. This is true for any number of tasks that a layman wouldn't ca

>Your users to don’t care how your code gets onto your server. I don't like arguments like this. This is true for any number of tasks that a layman wouldn't care to understand. You still will do them anyway, regardless of whether or not your user cares. It doesn't take a lot of experience to see the correlation between poor engineering practices and poor user experience. Now, I don't think the author was using this argument to pitch poor engineering, but there are good reasons for setting up resilient and consistent build deploys, as he addresses. I think the only real takeaway is "dont over-engineer your infrastructure" which is just an extension of generally "don't over-engineer." Every time infrastructure gets talked about on HN the conversation gets so sidetracked. The real problem is that people don't think about infrastructure in the context of a holistic view of a project. The hours you spend setting up your project with resilient and consistent CI builds are many times more valuable down the road. I think people need to not be so afraid of spending time on infrastructure. People already err on the side of spending less than more time on infrastructure. I don't think it's wrong at all that the author spent hours building an automatic build process for his project, especially because now that he's set it up he can refer to it in the future. Maybe with his newfound knowledge and experience on the problem means that he can leverage it with little effort in the future. None of this is a bad thing especially if you think about your engineering career on a macro scale instead of week to week.