Guildlines

These are not hard rules. They are guidelines. Staying from them when it makes sense makes total sense.

• Get to code that actually does something as fast as possible

• Make the initial explinations as short as possible

• Focus on how not why at the start.

• Maybe: cycle through concepts (e.g varaibles with numbers, then if/then, then variables with booleans, then if/else., the variables with Strings, then if/else if/else)

• You don't have to explain everything all at once. (e.g. you don't have to explain floats in order to talk about integers and you don't have to talk about the bits an integer can take up or the signed vs unsigned versions when you first start.)

• Run off the idea that folks will go through the entire book. So, you don't need to explain everything all at once. (see also the other note about that)

• Only show one way to do something (e.g. with ranges instead of showing (1..10) and then explaining that if you want to actually get to ten, just show (1..=10).

• Don't worry too much about explaing the syntax. That is: Show. Don't Tell.

• Avoid talking about what you'll show later. Wait until you get there. (This is a continuation of show don't tell)

• Avoid statements like "which we haven't talked about yet". If the person thinks about it at all, they'll know that's the case so there's littl point in mentioning it.

• Don't dig into every possible option at the start with edge cases. e.g. "In Rust, the main() function is used to kick things off" works find without having to. "In most programs, except for these types when its... whatever") It's like taking an 80/20 thing where the statement needs to be accurate but not all inclusive. Details of the different cases can be dealt with later.

• You can also use lanage like "basic variables are defined like" instead of "variables are defined like".