dreeves
commented
1 year ago Me in Slack today, when Adam mentioned scales that try to factor in past readings to smooth out your weight graph and Nicky mentioned their dad weighing the Christmas turkey by standing on a scale while holding and while not holding the turkey:
gah, that is a beautiful example of why violating anti-magic is bad and wrong! how else are people supposed to weigh xmas turkeys??
(i really am proud of the anti-magic principle. maybe mostly because of how stupid past-me was with auto-widening roads and odometer resets and ... god there's an embarrassingly long list of anti-magic violations from the early years of beeminder. but even now it continues to help me. i'm perpetually tempted to make things "smarter" and then i think "ok but juuuuuust suppose i wanted to be dogmatic about anti-magic" and so often that points me at a better design that doesn't need the bit of "smartness" i had been tempted to add. like i still don't know how helpful it is to anyone else but it really helps me.)
(and, actually, i guess i don't think it's just me, though possibly my formulation of it is too specific to me. like the programmers of the scale adam tried to weigh an 8 pound thing on via taring were like "what about the use case of someone weighing in multiple times in a row? we can improve the accuracy by taking a mean to average out the noise! let's see, if time_delta less than, say, 100s then ..." and alarm bells need to be going off in their heads. no if-statements! no arbitrary thresholds! no magic!)
(from a daily beemail)
We learned the hard way that when creating a new Beeminder goal, the defaults have to get you on the hook immediately. We used to start all new goals with a week of safety buffer by default. Which makes sense because you can't change anything within the akrasia horizon, and if you messed something up during setup (like picking an unreasonable rate) then you'd be stuck with it for a while.
It makes sense but turned out to be bad. We need to harness the immediate excitement implied by bothering to set up the goal in the first place. We don't want to waste that initial week for the user, and we want to hook the user while they're hot, when they'll be more motivated to invest the energy to figure all this stuff out. If a user creates a goal and then forgets all about it for a week, that tends to not end well.
But what to do about users who were baffled or galled that Beeminder was expecting them to do something tomorrow when they explicitly said they were committing to such-and-such per week (or per month or whatever)?
For quite a while we thought the solution was going to be to change the default amount of safety buffer to match what the typical user would expect. If you chose "2 per week" then we figured a user would expect to be able to go 3.5 days or maybe a full week before they'd have to do anything. So we figured we could default to that much initial safety buffer (they could still explicitly choose a different amount) and then the user would not be so surprised.
Spoiler: Focusing on minimizing user surprise is not the right thing to do.
We just didn't know how else to avoid the common confusion of people's first beemergency being sooner than they expected. We even spent a silly amount of time describing formulas mapping chosen rate and rate units to default amount of initial safety buffer. Eventually we solved the immediate problem by forcing the user to convert their rate to a daily rate, though that's not great either.
I think this is a nice illustration of how our Anti-Magic Principle -- blog.beeminder.com/magic -- is better than the Principle of Least Astonishment (POLA). Trying to minimize the surprise users were experiencing really led us astray. When there's one case where the right thing is happening (user creates a daily goal and wants to be on the hook right away) and another case where the wrong thing is happening (user creates a weekly goal and doesn't expect to have to do anything for the first week) it's tempting to add an if-statement to make the right thing happen in each case. But our hard-won anti-magic lesson is that if-statements are bad. We did better (though not yet best) to hack off a branch of that if-statement altogether and force everyone into the case where the right thing happens. Namely, you just have to specify your goal with a daily rate.
Again, not the ideal solution but a huge step up from trying to solve the problem with new layers of duct tape.
PS: The ideal solution is waiting on some infrastructure work we're doing to make it easier to have more dynamicness in our UI. Like you should be able to specify your commitment how you like and the UI just very clearly, in real time, shows both what daily rate that implies and exactly when your first beemergency will be.
PPS: Another instance of "if-statements are bad" be helpful on 2023-04-07:
Obviously the new solution was better regardless but I think the if-statement aversion is helpful in nudging us toward those better solutions.
Transcript in case it's an interesting case study
DR in the #beedroid channel: Replicata: 1. tap widget that has a default value set, call the value X 2. tap submit 3. datapoint of X is submitted 4. value field is cleared out Expectata: Previously the value field kept the value of X set so I could hit submit multiple times in a row for sending multiple +X's to the graph. Resultata: But now in dev3 I can't do that. Workaround: do the swipey thing to actually exit the beedroid app and tap the widget again. Then the X is pre-filled again. AW: do you know when you did that last and had it work how you wanted it? DR: based on datapoint timestamps, it worked per expectata around 11pm on Apr 5 AW: there weren't any changes to anything in DataEntry in dev3, maybe not in any of the alphas. it's possible that its related to immediately submitting the datapoint rather than scheduling a sync. this is utterly horrific. yeah, that's what it is. it doesn't look like it has anything to do with default values. do you want me to add an if so that it erases the value field on successful completion only if it didn't come from a default value widget thing? (edited) DR: so gross but, yeah, sounds like the alternative is spending more time than it's worth rethinking everything :( or (and cut me off if i'm still thinking about this in 5 minutes) could it be like: 1. always erase the value on successful completion, that's a useful indicator that the submission happened. 2. always fill in the X when the widget is tapped. (AW: i think that's what it does now. DR: no, see workaround in resultata above. it only works if i cause the app to actually exit.) DR: so i can no longer hit submit multiple times in a row but that was a little weird anyway. at least i can pretty quickly tap the widget, hit submit, jump back to home screen, tap widget, hit submit again, etc. AW: oh, hmm. task affinity. that may be a 2 minute fix.
Tangentially related thing: Boolean Blindness
ifs-are-bad thing is for the design stage, not implementation but zzq pointed me to this delightful thing for haskell programmers: > "This [boolean] being true means that e and e’ are equal, whereas this other [boolean] being false means that some other two expressions are not equal." Keeping track of this information (or attempting to recover it using any number of program analysis techniques) is notoriously difficult. The only thing you can do with a bit is to branch on it, and pretty soon **you're lost in a thicket of if-then-else's**, and you lose track of what's what. Evolve the program a little and you're soon out to sea, and find yourself in need of SAT solvers to figure out what the hell is going on. from https://sboosali.github.io/mirror/boolean-blindness.html For reasons expanded on in that article, zzq says he'd prefer "booleans are bad" to "ifs are bad".
Another internal case study -- super classic, blatant anti-magic violation: https://github.com/beeminder/beeminder/issues/1313 (The story is we decided to suppress click-to-toggle in a case where we anticipated it not making sense (cumulative goals) and where it seemed to add confusion for newbees. In isolation that seemed correct. If we'd treated Anti-Magic as a constraint then it might've forced us to reconsider the atrocity that is click-to-toggle and rethink the UI. Which would've been much better!)
The odometer reset feature never should've been allowed by the Anti-Magic Principle. It is admittedly very powerful and useful but there's a much, much better way to do that (explicit tare tags).
not sure anymore what this is actually referring to but it sounds like a legit case in point:
BEE: is it smart about generating references the first time you run it and stuff?
DREEV: i think so
(the fact that you have to ask is another anti-magic testimonial. the dumbest possible thing it could've done was "ERROR: difference from reference: changed from NULL to blahblahblah" and in one sense that's annoying cuz it should know it needs to generate initial references in that case but in another sense it's nice to have no ambiguity. you're like "ok, so i need to do 'regenerate all references'". no mysteries, it's doing nothing more nor less than what it's been asked to do, all is clear.)
Cognata
68
213
212
205
Verbata: if-statements are bad, anti-magic, yagni, software engineering principles,