One of the best ways to debug is to talk it out with someone else. What if you don't have anyone else to talk to? You can talk to a teddy bear or a rubber duck.
Lonely wargamers have made up solo variants of their games. The simplest possible solo variant is self-play. You play as yourself, and also play the opponent as best you can. That is, you "put on the hat" of the opponent, and make their plays for them.
More complex solo rules give guidance as to how to play as the opponent. For example, David Weiss's guidance for play of the opponent in the game 7 Wonders (during the first Era), goes something like this (I may have gotten it wrong):
- If possible, play a resource card costing 1 coin.
- If possible, play a yellow card.
- If possible, play any other resource card.
- If possible, play the science card that involves paying the human the least amount in coins.
- If possible, and the opponent is equal or behind the human player, play the military card that involves paying the human the least amount in coins.
- If possible, play the next Stage of Wonder.
- If possible, play the blue card that involves paying the human paying the human player the least amount in coins.
- Discard a card for 3 coins.
It is not entirely obvious from this description, but there are still choices remaining to the human even with these mechanical rules. For example, the human chooses which card to discard at the last, lowest-priority rule. The human still occasionally needs to "put on the hat" of the opponent, just as in self-play, but they have much more guidance.
De Bono's thinking hats are descriptions of mindsets. For example, wearing the yellow hat means deliberately being optimistic and looking on the bright side of things, while wearing the black hat is something like playing Devil's Advocate.
So possibly a paper-and-pencil collaborator could be a prioritized list of rules, each having a condition and an action per usual, where the action is allowed to delegate back to the human player, via a description of a "hat" that the player is expected to "put on". For example:
- If you do not have a hat, put on De Bono's yellow hat.
- If you have just experienced a failure or backtrack, switch your hat: yellow->black, black->yellow.
- Otherwise, play using the hat that you are currently wearing.
I am not entirely certain, but I think the gamemaster's "move list" in D. Vincent Baker's Apocalypse World could be shoehorned into this framework as well.
Combining J. B. Rainsberger's model for improving names with his Simple Design Dynamo might be shoehorned into this structure as well.
- If there is clear duplication, eliminate it by introducing new abstractions. Note that this is a good move even if you do not have good names for the new abstractions.
- If a name is actively misleading, rename it to something nonsensical. For example, you might use traditional programmer metasyntactic variable naming such as foo, bar, baz, qux, quux and so on.
- If a name is nonsensical, figure out what it actually does and name it after that. For example, you might use "structural" names such as XFactory, YAdapter or ZRepository.
- If a name does not capture the FULL purpose of the entity (or your full INTENTION for that entity), rename it to something precise, even if it is considerably longer, or the new name contains helpers like "if", "and", "or", "but".
- Split objects that have multiple responsibilities (often signaled by long names containing words like "if", "and", "or", "but").
I am not sure about the order of these, and it's entirely possible that some non-prioritized system, such as "roll a die, follow the rule indicated if possible, repeat" would be just as good.
A crude problem-solving collaborator inspired by Knuth-Bendix completion might look something like this:
- If there is some datum given in the problem description (that is not crossed out), create an index card for it, put it in the todo pile and cross out the datum.
- Elseif there is nothing in the doing-now spot, pick up the top of the todo pile, read it, and put it in the doing-now spot. Also turn all the done pile face-up.
- Elseif there is nothing face-up in the done pile, put the card in the doing-now spot face down in the done pile.
- Elseif there is something A in the doing-now spot and something B face-up on top of the done pile, think about those two facts carefully, and write down on index cards all the facts you can conclude from them, and add them to the todo pile. Then turn B face-down.
A variant: Instead of building the initial todo pile by crossing out datums from the problem statement, start with one index card actually containing the problem statement, and five index cards containing each of the Five Thinking Tools from SIT face down in the done pile.
What would a collaborator inspired by breadth-first search look like? What about depth-first search? Conflict-driven clause learning?
This is one way of expressing Jackson Structured Programming:
- Draw system diagram. (This step may be omitted when obvious.)
- Draw data structures for program input(s) and output(s).
- Form program structure based on the data structures from the previous step.
- List and allocate operations to the program structure.
- Create the elaborated program structure with operations and conditions added to the basic program structure
- Translate the structure diagram into structure text or program code
In practice, of course essentially every step can, and does, jump backward to any previous step.
Is there a way to express JSP as a reactive paper-and-pencil collaborator? Is there a way to express all JSP-like processes (meaning, proceeding from step to step, with backwards jumps to any previous step) as a single set of rules, differing only by different initial "decks"?
Consider David R. MacIver's "How To Make Good Things" in this context.