
Accountants Don’t Use Erasers (2007) - tosh
https://blogs.msdn.microsoft.com/pathelland/2007/06/14/accountants-dont-use-erasers/
======
SAI_Peregrinus
On a somewhat related note, a piece of advice for students: Don't use an
eraser on tests. Write in pen, cross out mistakes with a single line through
the middle. It will show the instructor your reasoning, so even if you get the
final answer wrong there's a chance you'll be given partial credit. It won't
hurt (as long as you have space) and it can certainly help. Even if you don't
get partial credit your instructor may indicate that something you thought was
a mistake was the path to the true solution. I used this tactic all through
high-school and university, it works well and makes learning from mistakes
easier.

~~~
todd8
I had always used pencil in high school for math, figuring that I would
occasionally need to correct or start over on some portion of my work; I
graduated in 1969. At MIT, I learned as a freshman from an upperclassman to
switch to using a pen. Every minute counted and simply crossing out was much
faster than erasing . To this day, I rarely use a pencil. For scratch work I
write on typing paper with a pen.

While working on more complex problem sets in my recent graduate math and CS
courses I developed a couple of additional tricks:

(1) Do your home work on plain paper sheets. _Write on only one side;_
flipping sheets of paper back and forth to find something will drive you crazy
and slow you down.

(2) After obtaining a solution, copy it from the work sheets (that may be full
of dead ends) to the sheets to be turned in. _Then fold the work papers in
half, brining the top edge down to the bottom edge and set aside._ This keeps
your workspace clean for the next problem while still preserving any work for
subsequent parts or problems. I also fold the papers that I will turn in, but
I fold them with a vertical fold (left edge over to right edge), this keeps
the to be turned in papers from being mixed up with the work in progress or
the set aside work sheets that I'm finished with.

(3) _Papers to be turned in should be lightly tinted and or written in an
unusual ink color._ This accomplishes two things, it's easier to find your
work when returned in a big box or stack by the professor, and secondly, the
graders will start to recognize your work. My theory is that in these classes
I'm usually at the top of the class the graders will start to grade my papers
more charitably because they expect that I am getting the correct answers.

------
jasode
_> 1) You don't really ever delete ANYTHING. As a matter of fact, you don't
update anything either..._

It's a good article but it has the common shortcoming of leaving out
_tradeoffs_.

Append-only architecture:

a) requires more disk space

b) can have slower performance: e.g. double _writes_ of (1) to the immutable
log and (2) summary cache -- and both operations must be sync'd in a
transaction ... or other option of skipping the writes to the summary cache
which means all subsequent _reads_ must "re-materialize" what the "current"
data looks like by re-applying history of deltas repeatedly

For some domains like financial accounting, those tradeoffs are immaterial and
you absolutely need immutable history for auditing and system debugging.

However, for other purposes (e.g. os filesystems like NTFS), the better
tradeoff is to mutate data in-place and forego history to save diskspace.
(E.g., You want to modify 2 terabytes of data on completely full 8 TB
harddrive that only has 100 MB free.)

The tradeoffs are why many database engines offer a "generate no rollback log"
option for bulk update commands. The opposite example is bolting on a "history
log" on top of a mutate-in-place file system -- which is what Mac OSX "Time
Machine" backups do.

~~~
thomascgalvin
Yeah, append-only computing is only a good solution in a field where you need
to be able to thoroughly, accurately audit the state of the system with 100%
non-repudiation. Financial and medical data are probably the two biggest
areas, though there are others.

And you're right, this is a performance killer and a disk eater. I work on
backend services that handle financial data, and about 50% of the internal
network traffic is the various audit widgets doing their thing.

------
brian-armstrong
On a similar note, don't be tempted to erase parts of your commit history.
There are some modes of using git rebase, push -f, commit --amend etc that
attempt this. It's almost never a good idea. If the issue is just that
something was a typo and you don't want your mistakes out there, just don't
worry about it.

~~~
_Wintermute
Unless you have a password or secret token in there.

~~~
Simon_says
At that point, it's better to change the secret if at all possible.

