> The nihilist programmer starts from these axioms and then decides what to do. What to do? The least amount of change possible. I don't think there's a deduct

> The nihilist programmer starts from these axioms and then decides what to do. What to do? The least amount of change possible. I don't think there's a deductive chain from those axioms to that choice of action. If you're a "nihilist programmer" (not a fan of this usage of nihilist/optimist) in this sense, there's nothing in your ethos that says it can't be better. Sure, it will always be crap, but you can make it better crap. You can do that in small bits or big bits. The analogy I use for legacy production software is that it's a tire fire, one should endeavor not to make it worse (by unnecessarily adding more tires or fanning the flames), and if possible make it better (spray water on the thing), but it's never going to be an Eden even if you managed to put out the fire since you've still got a stack of tires that could reignite at any moment. If you start out with an Eden in the beginning, maybe you can preserve that, but even if it's ever been done it's not done most of the time. The best is the enemy of the good, but the good is the enemy of the better. There are few things more irritating to someone with a "nihilistic programmer" mindset as seeing some self-satisfied "optimistic programmer" with their Good crap, that's still crap and could be made better. Not seeing any chance or value of improvement from good is the inverse to seeing no chance or value of improvement from broken, the problem with either view is that doing better isn't tried.