Recode Reflection

January 29, 2022
IMA Blog
/
04 Spring 2022
/
Recode!
/
Recode Reflection

This class has been a great opportunity to 1) revisit work that was abandoned at the proof-of-concept stage and 2) start doing some more design reflection and meta-examinations on code as a medium.

Upon reflection, I realized that the moments that I am most frustrated with code are often connected to cognitive overload. It is really hard to try hold on to the complexity of the problem, while simultaneously holding on to the complexity of code. So I need to embrace anything that can be done to reduce the complexity of the problem or the code.

Write it down

The first thing that I started doing that was helpful was to literally write down what the bug or problem is, as a title. (Writing it out in an attempt to better articulate is a separate, also helpful strategy! This one is simpler/stupider.) I found that when I was context-switching between managing the code/trying a fix and then observing the performance of the code, I struggled to remember or recall what I needed to be looking for. Simply having the name of the bug written down next to me helped me reduce the need to actively work at orienting.

Obvious and Predictable

I also developed a two-word mantra for both the code and the problem. Is it obvious? Is it predictable? When debugging, I rarely if ever was able to just fix the problem right off the bat. The way I've been able to debug things is by slowly making both the code and the problem more obvious and more predictable. You keep doing this until the bug becomes crystal clear and there is no confusion about why it was there in the first place.

Making code more obvious:

  1. Renaming variables to better align with what they are/are not. // let sandwichStuff; → let bread; let jelly; let peanutButter;
  2. Ditto for functions // eating() → takingABite(); chewing();
  3. Decoupling functions so that they are doing less. // makeASandwich(); → getIngredients(); spreadIngredients(); cutSandwich();
  4. console.log with clear labels for what you are logging // console.log( "numberOfHungryPeople: ", numberHungry);

Making code more predictable:

  1. Doing something simple and comment out the complexity, you can get to it later. // if (hungry) { makeASandwich() }; → if (hungry) { sayIAmHungy() };
  2. Start with what is working and comment out anything you don't understand.
  3. Replace calculations with round, easy to use numbers; // if (numberHungry) < (ingredientTotal)... → if (10) < (ingredientTotal)...

Making bugs more obvious:

  1. Ask the bug for all of the information you can get, and pay attention to the information about the information from it. Did it console log multiple times per click, when you were expecting just one? What line did the bug fire on? What happened right before/after the bug gave you info? What didn't happen?
  2. Use extreme values. If a bug is affecting the size of something, try making the size 0, 100, 1000. What results do you get at scale?
  3. Use simple colors. (If "a", then that square is red. If not, it's green.) This is an easy way to quickly get info.

Making bugs more predictable:

  1. Only ask the bug yes/no questions, while you get to know it.
  2. Turn code off and on until you can isolate where in the program flow it is occurring.
  3. Can you repeat the bug? Can you change it in anyway? What affects it and what doesn't?

Refactoring

Refactor in public. I don’t know why this works. Refactoring is hard and when I try to do it in the safety of my own home, I found myself far too easily distracted. Sitting somewhere else in public was the key for me. I also realized that recognizing that you need to refactor is one problem and figuring out how to refactor is another. I'm hoping that this becomes easier for me with practice. Refactoring is daunting to me because you have to take something that is (maybe) working and rip it apart. I keep thinking about how you have to get all of the clutter out from a drawer, if you really want to see and organize it.

The biggest indication for me that it's time to refactor is that coding stops being fun. Repeatedly now, when I find that I am dragging my feet and am unexcited about adding functionality, that usually means I need a clean out. Also, post-refactoring coding is the most fun type of coding there is and I'd like to continue to chase that high.

Favorite Tricks

My two favorite debugging tools:

  1. “red” (predictable and easy to spot)
  2. mouseX (predictable AND gives you an easy to change range of values!)

‍

No items found.