Implies that OP is correct. In order to penalizing yourself you need to do something you consider a punishment. In this case donating to charity...
Fortunately it isn't working because as others pointed out, "penalize himself" and "donate to charity" concepts aren't directly tied together. Where the donation actually goes is immaterial, so it's not possible to argue that "punish himself" implies "donate to charity" is punishment.
mistake > punish himself > donate to charity to punish himself
Donating to charity as a method to achieve the punishment goal is precisely material in this case.
GP is asking if this method, which contains both a gain and loss, actually results in a punishment with an intended loss.
But to make it worthwhile (aka the reward part of the punishment), the donations are directed to charity since they need to go somewhere. So that's a small reward built into the punishment.
When I play a game with my buddies, I try to win, but even if I lose I still have a good time.
This is a very similar concept. Also, don't assume that this is the only money he gives. Games are fun.
Incidentally, I somewhat envy people who are capable to pull such strategy off. It requires some amount of suspension of disbelief, forgetting for a moment that you're the game master and playing the game by the book way past the point it's become uncomfortable. I don't have that. I tried many times, but my mind just refuses to participate in self-trickery.
That doesn't make sense. Penalties aren't fun. Building software isn't a game (generally).
And there sure seems like there's a real possibility of wasteful behavior, e.g. someone 'spamming' the build system to effect a large overall donation.
I would go one step further and pick an amount that I want to donate and then each fail action moves a unit of money from the "good" to "bad" bucket. ie start with $100 and each failed build puts $1 into the Big Endian / Kodos / Republican and each successful build the dollar goes into the Little Endian / Krang / Democrat charity bucket.
As a programmer I can sympathize with wanting to get my head out of the clouds once in a while. Sure, my customers use my software, but my internal build processes are invisible to them.
If a build fails, nothing changes in the production environment. The developer can troubleshoot and fix the build. Pretty much like when local compilation fails due to a syntax error.
Why does such a routine thing as a build failure need to be rewarded or punished?
We're (mostly) past those times now, but "breaking the build" is still in the mind of many devs as a negative behavior.
Breaking a build once, for whatever reason, probably isn't a big deal. But breaking a build frequently certainly could be.
Some human interactions are only a few A/B tests away from turning into a Black Mirror episode.
Social mores are actually huge efficiency boosters for humans. They remove the overhead associated with coordination, transactions and ensuring trust.
I understand that a lot of these don't scale to cities of millions and civilizations of billions, but some do, and we shouldn't be quick to replace them with the "newest and shiniest" (essentially replicating them at scale by burning energy).
In the case of the daycare, the price wasn't intended to encourage parents being late at all. The actual price the daycare workers would probably want to charge is not a market clearing price, but a price so high the market doesn't clear. They probably felt trapped into haggling once they put any price on the practice at all.
"Staying open later and charging your customers for the service they receive during that time" isn't exactly a business secret. It also can be detrimental to the quality of life of the employees that are unsure of when exactly they'll be able to end their shifts.
Set it to something really high like $600  and parents' behavior will change, problem solved :)
Kind of like introducing a defect lane on your factory line makes the workers feel like it's OK to have defects, and deters from quality.
The economic premise of the kindergarten is already that parents would rather pay money than spend time with their kids.
But it guess if it is just for fun who cares :)
Another approach is donating to a charity you despise. Some friends of mine use a mutual donation pact to get things done. Each sets a goal they need to accomplish by the end of the month, and hands the other a signed check for $50 for a charity or political campaign they hate. If they don't accomplish the goal, the other person drops the envelope in the mail.
It's very effective. :-X
For instance, stickK sets up its commitment contracts with the option to donate to an "anti-charity":
It also allows you to donate to fan clubs of sports teams you despise :)
It would be way more effective if you were donating straight to a competitor, or a political organization you do not support at all.
So many people focus on how often the build is broken. That’s not the important part in CI. The important part is how often (% of day) the codebase is broken.
It’s not how often you break the build that kills the team. It’s how long it stays that way. Breaking it twice a week for five minutes each is better than breaking it once a month for an hour or two.
The point of CI is to identify integration issues, not a blame assignment system (the loaded way you ask the question is really not helpful). So we can work faster. Not so we can spend all day second guessing our push being afraid we will make the build red.
Any commit can have integration issues. With enough people committing, there is a build going on all day long. It won't always be ships passing in the night.
I guess that it's possible that your code merging workflow allows everyone to work completely independently but some teams don't (and others probably can't). So a broken build is an impediment to other working being done.
Are you talking about a scenario where people are just freely pushing to master without a review/CI step? If you recognize the problem with this, why is “deter people from breaking a post-merge CI process” better than “make your CI process pre-merge”?
I never merge something to master, or any branch that I expect other people to use without knowing that it's going to pass, but I don't see any harm in having failing builds on a personal branch (particularly if I later clean up my commits to ensure that no individual commit that gets to master ever fails).
Generally if I'm moderately sure things pass I'll just push to CI. Even sometimes when I'm sure they'll fail I'll push to CI, then work on something else while it runs the build, then come back to check the output.
Donating to charity, while an incentive, won't help me see the detailed lesson a year from now.
Does seem like a neat idea, but you'd probably be more likely to avoid failed builds if (a) the donation was immediate and irreversible; and (b) went to a charity or organization you vehemently disagreed with.
One of the founders of Saxo Bank motivated himself in a weight loss challenge, by pledging to donate ~30.000EUR to the danish communist party, if he did not make his goal.
(It worked, he made it).