IntermediateRuby     about

About

👋 I’m Josh!

You want to be a better software developer.

You know the basics.

Maybe you went to a bootcamp, maybe you’re self-taught, but either way you’ve got at least a few months of paid work experience in Ruby/Rails.

And you think “there has got to be a quicker way to learn all this stuff!”

Pretty much every experienced developer I speak with, I ask some variation of:

How did grow to become a better software developer? What do you recommend to others as they pursue improving their skills?

I get answers like:

  • “Read lots of source code”
  • “Work on side projects”
  • “Make open source contributions”

This never has sat right with me, though, for a few reasons:

These answer select against anyone who isn’t able or doesn’t want to spend non-work hours coding.

For example, most unpaid labor in the world is done by women1, so the recommendation of

work on side-projects and make open-source contributions”

Selects against women.

Aside from the free time to work on side projects problem, I learn things slowly. And I love to learn things quickly. I want to learn more, and faster, and I want to help you learn more, and faster.

Surely, someone out there would have figured out some means of explaining more advanced software development principles in a way that conveyed the knowledge quicker than it was acquired.

It’s this “convey knowledge quicker than it was acquired” piece that enables highschoolers to understand and appreciate cutting-edge scientific advancements that happened in the 1800s, and then build on those advancements to accomplish even more.

I don’t quite know the final solution, but so far, this project will involve:

  • Lots of test files, so your learning will be measured by making pre-written Minitest assertions pass
  • Dissecting the decisions senior developers make, so that we can understand the reasons they made it.

These two elments align with the current understanding of how humans learn hard things, namely Deliberate Practice and Purposeful Practice.

I’ll explain the difference later, but know that Deliberate Practice is the gold standard of skills acquisition, but cannot be implemented for software development 2. Purposeful Practice is the closest we get.

Purposeful Practice is still pretty good, though. Check out these critera:

  1. Purposeful practice has to be focused. You should not be able to think of your next meal (nuggets!) while undertaking it.
  2. Purposeful practice should take you out of your comfort zone. It should feel painful to do. As [the author] mentioned earlier, playing a piece of music you already know how to play — for instance, during a musical performance — does not count, and writing a program that utilises techniques you already know to use also does not count for the purpose of mastery. Practice that makes you better should take maximal effort, and thus feel terribly unpleasant to do.
  3. Purposeful practice requires feedback, and adjustments to technique after getting the feedback. In its most general form, [another author] notes that feedback need not be immediate — but it is most effective if the feedback loop is short.
  4. Purposeful practice has well-defined, specific goals. You don’t want to “play this musical piece”, you want to “play the complicated second section that requires unorthodox finger placement”. You don’t want to “code iPhone apps” you want to “implement the nested MVC model from scratch”.

​source​

The first “purposeful practice” project I’ve made so far is a obstacle course for parsing webpages with Nokogiri. I spent about thirty hours learning Nokogiri, and the way it’s packaged, you can learn most of what I learned, in about 4 hours.

You “get” thirty hours of my learning time for four of yours.

There’s lots more to come. Enter your email below, and lets get started.

-Josh

  1. Invisible Women: Data Bias in a World Designed for Men
  2. The Problems with Deliberate Practice