Skip to content

Instantly share code, notes, and snippets.

@geoffreyadebonojo-zz
Created August 7, 2018 22:15
Show Gist options
  • Save geoffreyadebonojo-zz/74b6a03b6aec897419bc61e433ae701b to your computer and use it in GitHub Desktop.
Save geoffreyadebonojo-zz/74b6a03b6aec897419bc61e433ae701b to your computer and use it in GitHub Desktop.

#“Pick out 3 behaviors that resonate with you in the list and describe why they resonate with you in a reflection (4-6 sentences).”

I chose four.

Microdecisions MATTER

Some of the very first code I wrote was javascript animation. I had just discovered variables, and I thought I was being economical by keeping everything short. Like, single letter short. I strung variables through arrays… it was bad. The animation worked, but that code is borderline unreadable now. I think maybe the ‘human readable’ part of programming languages are still under appreciated. Anything that reduces the cognitive load will probably improve the overall logical structure.

Code is cheap

Starting over is the opposite of failure— it means you’ve found an idea worth refining. It lets you to economize. “Hello World!” Is a really beautiful idea— just the smallest effect you can create. It unfolds from there: “…can I make it say that in reverse? How many characters long is it? Can I mix up the letters to make anagrams?” If the goal is deep learning deep learning, lines of code are the best investment on earth.

Error messages are useful.

We often don’t know just how incomplete our understanding is until it fails. I like ruby's error messages. I imagine it kind of like a soccer game— line 64 kicks it back to line 34, which kicks it to 18… Good, clear error messages aren’t just semantically helpful but can reveal information about structural problems in the code. Conversely, if you can't decipher your error messages, it's a sign of serious structural problems.

Don’t count Hours (count lightbulb moments).

Deep work involves making major structural decisions with complex interrelationships. Shallow work involves building, cleaning, and maintaining. It requires much less mental energy.

Not everyone finds a healthy balance between the two. If I am permitted to draw a comparison with the process of learning: you can only absorb so many vibrant new ideas at once. There is a rate. If you exceed this rate, as almost everybody has to at one point or another, it feels like you're not really getting it. I like to savor the new idea, give it space to breathe. Ask what if. "I wonder if I can..." It grows. And as it grows you have to maintain it with 'shallow' work, little practice modules or tests. You DRY it out, etc. You make the code cleaner-- in a very specific way. You want to make it easier to change, because it will change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment