Background

• I asked mid-level core course instructors

  What tools should CS students know about early?

• I expected development tools like grep and git, but that’s not what I got…

Tools for CS Students

1. Your Brain
2. Debugging
3. Big design, small code
4. Plan to throw one away
5. Version control
6. Keyboard not mouse

1. Your brain

You have a brain.

It is complicated.

Two parts of your brain strongly impact your learning.

1a. Working memory

• If you are consciously thinking about it, it is in working memory.

• Working memory is powerful but limited (∼ 3 ideas).

• Working memory shrinks when tired, malnurished, ill, stressed.

• Distractions also occupy working memory.

1b. Schema

• Your subconscious automates what it can.

• Each conceptual automator is called a “schema”.

• Schema shrink complicated ideas into simple pieces that fit in less working memory.

1c. Learning

• Learning is largely buidling or refining schema; requires some working memory.

• Ideal cognitive load:
  old idea 1old idea 2new idea

• Problematic cognitive load:
  old idea 1aold idea 1bold idea 2a   overload

• Usually, trouble with task n means didn’t fully learn from task n − 1.

• Using tools to do things (calculators, copy-paste, LLMs) doesn’t build schema.

• Memorizing doesn’t build useful schema (unless you’ll use it many times).

• Repeated exercise with varied instances does build schema,

  especially if you design the instances yourself.

2. Debugging

1. Identify that there is a bug.

2. Understand what should have happened and what happened instead.

3. Locate the bug within the code.

   There’s only one way to do this too:

   1. Pick a location in the code.

   2. Predict the expected value of all variables there.

   3. Check to see it they have those values (with debugger or prints).

   4. Pick a new location: earlier if wrong there, later if right there.

4. Change the code to remove the bug. This might involve

   • Fixing an error in computatation or API use (easy)

   • Splitting two related ideas from one variable into two (medium)

   • Bring new data to that location by adding variables or data structures (hard)

3. Big design, small code

To code without needing much debugging:

1. Start with correct but featureless code.

2. Add the smallest additional feature you can.

3. Test that small addition (and retest everything before it).

   Some recommend swapping steps 2 and 3: writing the test before starting to code.

4. Return to step 2.

Works best given a list of features to add before you begin (a design).

If it seems like the next feature is big, refactor.

4. Plan to throw one away

If your code feels messy and complicated…

…throw it away and start over.

If your code is finished by not beautiful…

…throw it away and start over.

If doing the assignment felt uncomfortable and tricky…

…throw it away and start over.

If you plan to deploy your code with real clients and need it to work reliably…

…throw away the first version and start over.

This was one of the first software design principles to be identified and published (by Fred Brooks in 1975) and remains widely recommended today.

• In school, this helps reinforce your schema, makes all future work easier.

• In industry, this reuslts in safer, more reliable, more efficent software.

5. Version control

Disk space is cheap.

Experimentation is easy.

Recovering from a bad experiment is only cheap if you have old versions on hand.

Options:

• Manual snapshotting: after adding each feature, make a copy of your source code.

• IDE history logging: many IDEs have a “timeline” feature.

• Version-control software: git and its peers can automatically store many versions.

• Undo is not a viable option: can easily lose history.

Pick one. Learn it. Use it.

6. Keyboard not mouse

Mice are slow and hard to automate with schema, but easily learned.

Keyboards are fast and easily automated with schema, but harder to learn.

Become a Power User. Use the keyboard.

1. Almost every command has a keyboard shortcut. Learn 1 or 2 each week.

2. The terminal/command line/console/shell is designed to be keyboard-only.

   It has orders of magnitude more capabilities than any other application I know of.

   Learn it on your own, for example by using the following:

   • https://web.mit.edu/mprat/Public/web/Terminus/Web/main.html (in-browser)
   • https://overthewire.org (in your terminal over network)
   • https://github.com/entrity/Spell-Quest (in your terminal locally)