> Thoughtcrime? That's an unexpected and intriguing direction to take. Let's just assume that "disincentivize thinking" is a euphemism for "prosecute thoughcr

> Thoughtcrime? That's an unexpected and intriguing direction to take. Let's just assume that "disincentivize thinking" is a euphemism for "prosecute thoughcrime" and put it to the test. A project I maintain has a monstrously complex build system. Part of my MO was to fix and improve it to the point that a mere mortal-- and even a newcomer-- can build the software without being a build systems expert. Some of the work was a time-consuming pain. When I got behind users would come up with clever yet complicated workarounds which would propagate through the forums. At that point I had essentially two choices-- either call user workarounds "good enough" or actually fix the bugs so that compilation remains easy. The first option would inescapably lead to an I-had-it-worse-so-suck-it-up rite-of-passage for compiling the software. E.g., if you are compiling on platform V and want to use X, download Y and do command Z. As evidence, stacks of such workarounds characterized the build process before I improved the build system-- phrases like "not for the faint of heart" and "will probably take you a day" were good descriptors. Newcomers were dissuaded from learning it (learning it, i.e., you had to do something more than configure and make) and just depended on binary packages. And the ones who already knew the build system didn't have an incentive to mentor someone who wanted to improve the system-- they already had a mental map of the workarounds and knew that any change to the monstrous system would cause problems and be a time-consuming pain. It was much easier to just to pass on the workarounds. (Plus at some point there were actually zero developers who understood the system well enough to mentor anyone.) The other option was to fix the bugs in the build system. Because I had to slog through a harsh build environment and hated it, I improved it so that it would be easier for newcomers to build. I made a decision that made it less likely for the imperative "suck it up" to appear in the forums wrt to compilation. (Userbase is nice so I don't think they would have put it this way, probably something more like, "Yeah it's difficult, but that's just part of learning the system" or something like that.) At the same time, the people who built the workarounds didn't complain. Instead they said, "Thanks." As I see it I made a decision to improve a system. That decision almost certainly made it less likely for the following argument to be used: "I had it worse (or at least as bad) and did ok, so suck it up." This decision made it possible for more people to enter the developerbase in less time. Lots of positives, not so many negatives. That's a good outcome for what I see as clear ethical behavior on my part. Here's the question then: if "disincentivize suck-it-up thinking" is a euphemism for "prosecute thoughtcrime," don't we have to conclude that it is both ethical and beneficial to prosecute thoughtcrime?