Hi, I'm Richie

This site is where I document what I learn about coding.

A picture of this site's author.
I don't normally wear sunglasses indoors, I promise.

I didn't come from a traditional software engineering background (CS degree, programming since I was a newborn, etc.). I graduated from a coding bootcamp (R.I.P. Dev Bootcamp Chicago 🫗), and software engineering is my 3rd career (previously I was a travel agent and an ESL teacher in Shanghai).

The coding bootcamp taught me how to use Ruby, Rails, MySQL, etc. More than that, it also taught me the value of a "growth mindset". Instead of saying "I don't know how to do XYZ, guess I'm stuck that way", I could say "I don't know how to do XYZ yet."

This was by far the biggest benefit I got from my time at bootcamp, and was an order of magnitude more valuable than learning any given language or framework.

Getting 1% better everyday

At some point, I remember reading James Clear's blog, and I saw this chart:

A chart showing that, after 1 year, a 1% daily improvement results in an exponential total gain.  The reverse is also true- a 1% decline in performance results in 3% of the original performance level.
Chart recreated by me, based on the one here, by James Clear.

It said:

If you get one percent better each day for one year, you'll end up thirty-seven times better by the time you're done.

For me, this meant that if I was faced with learning some huge, unapproachable codebase, I could simply break it down one line of code at a time, and after awhile I'd understand an entire file. And with enough consistency, over time I'd understand all the files in a directory, and eventually the whole codebase.

I decided to put this into practice, starting with the codebase for RBENV, one of the most popular version managers for the Ruby version language.

How do you build a house? One brick at a time.

A man laying brick.
Photo attribution #2 here.

I started with the entry point into that codebase (i.e. the first file in the code's execution path).

Along the way, I took notes in a Google doc. This was a critical part of the process, as it forced me to explain what I thought the code was doing, as if I were pairing with another engineer. If I couldn't verbalize what I thought was happening, it was a sign that I didn't yet understand the code well enough.

Over time, I started recognizing more and more of the commands and techniques I encountered in the code. As I acquired more and more knowledge, it became easier to parse the files I read. Soon, reading 1 line of code per day turned into reading 1 block of code per day. Then one file per day. And so on.

"Don't Break The Chain"

A chain with a broken link.
Photo attribution #3 here.

The key to this was consistency. I had to be diligent about showing up every day. My inspiration for this came from comedian Jerry Seinfeld:

Software developer Brad Isaac was an aspiring comedian when Jerry was still touring at the start of his Seinfeld fame. One night they happened to be at the same club. "Do you have any tips for a new comic?" Brad asked Jerry.

"The way to be a better comic is to create better jokes," Jerry replied. "And the way to create better jokes is to write every day." Then Jerry shared his secret for sticking to such a schedule:

  • He hung a large wall calendar in a conspicuous spot so he'd see it all the time.
  • Next to it, he placed a colorful marker.
  • Each day, after he completed his writing task, he put a large X in the box on the calendar associated with that day of the week.

"After a few days you'll have a chain," Jerry explained. "Just keep at it and the chain will grow longer every day. You'll like seeing that chain, especially when you get a few weeks under your belt. Your job is not to break the chain."

He paused.

"Don't break the chain," he repeated.

Source here.

It's hard to overstate how motivational it was for me to look at a calendar and see a large-and-growing chain, representing the progress I was making toward my goal.

The Result

After many months of writing, the result was this series of blog posts. It starts with the shim file (i.e. the first file in the execution path, which I mentioned above) and then moves on to each of the commands that RBENV exposes, such as rbenv version, rbenv init, etc. Lastly, it looks at some of the support files included in the repo, such as the Makefile and the .github/ directory (which contains the setup for Github Actions as well as the Dependabot config file).

While I know not everyone is as interested as I am in reading an entire codebase cover-to-cover, that's not the point. By putting this work online, I can look back at it and see what I've learned and how far I've come since my days as a bootcamp grad. That's pretty meaningful to me.

How To Reach Me

You can email me at richiecodes2024 [at] gmail, or find me on LinkedIn here.

Photo Attribution # 2

Title: Bricklayer 3

Author: John Keogh

Source: Flickr

License: CC BY-NC 2.0 DEED Attribution-NonCommercial 2.0 Generic

Photo Attribution # 3

Title: bigstock-a-chain-with-a-broken-rusted--37045324

Author: Aqua Mechanical

Source: Flickr

License: CC BY 2.0 DEED Attribution 2.0 Generic