Josh Thompson     about     archive     tags

Turing Prep Chapter 3: Moar Mythical Creatures

Index of this series:

I’ve made a few more videos, focusing on the Mythical Creatures exercises.

Mythical Creatures: unicorn.rb

Once you’ve finished the strings, arrays, hashes, etc… you may want to take a spin at the infamous Mythical Creatures!

These exercises will give you lots of practice with “object oriented” programming. You will define an object (like a Person object) and create instances of that object that have certain behaviors and methods of interaction.

This is a lot to wrap your head around, and “object oriented programming” is a topic that fills dozens of books, hundreds of conference talks, and you’ll spend the rest of your life building a better understanding of. So don’t feel any rush to grasp it all in the next ten minutes.

Start with this guide: LaunchSchool: The Object Model

Read it carefully, but don’t worry that it all won’t make sense. Take notes, run the code examples. Take an hour on it. When you’ve gone through it once, tackle the first mythical creature.

It can be tricky getting set up, so here’s another video of the very first mythical creature:

A quick aside - as you work through these exercises, and all of the exercises to come, you’ll perhaps notice a constant tension between “results” vs. “process”. Here’s what I mean by this, explained in a conversation with a Turing student, working through this exact guide:

They said:

[…] In other words, there is more than one way to achieve the result, so do I focus on process or product? I am not expecting there to be a single “right” answer, but I am curious as to how Turing is going to evaluate us. Are the steps used more important than the outcome?

I responded with:

Your intuition is leading you well - the steps and the outcome, are important.

I’d recommend de-emphasizing the Turing evaluations in your mind, though, and just focusing on building the right kind of skills that will serve you well for the rest of your career as a developer. And, from that lens, there will always be tension between the best I know how to do right now and the best that can be done, ever.

Obviously, as you grow your skill-set as a developer, you would be able to go back and improve prior bits of code you’ve written. It’s rare to crank out a “perfect” project, no matter how small.

So, optimize for learning, which basically means… when you find something that works, use it, but next time you come across a similar kind of challenge, you might use something slightly different. I don’t know if any of this makes sense. It basically means don’t sweat not getting exposed to every single ruby method, but be open to using new ones as situations arise, and you get more comfortable with the ones you know.

Or, in summary:

There may be multiple ways to achieve the required outcome; use what you now know; be on the lookout for other methods that achieve the same result.

>> Read more

Turing Prep appendix: Troubleshooting Errors

Index of this series:

As you run into problems (and others) let me know. I’d like to collect a broad swath of the errors folks run into, and the solutions, so they don’t get too caught up.

Here’s a quick index of what’s in this guide:

Traceback... cannot load such file -- pry

This seems like an intimidating error message at first.

It’s not. The error just says:

Dear user, you’ve asked me to import code to run these tests, but I cannot find the code you require.

The code I was looking for (and cannot find) is called pry

Pry is an amazing tool. You’ll soon come to love it. In the mean time, just install it. It’s a ruby “gem” so you use the gem install <gem_name> command.

In your terminal, run gem install pry and then run the tests again.

Cannot open atom from the terminal

You may need to install the Atom Shell Commands. Atom makes it super easy to do this:

install shell commands

>> Read more

Turing Prep Chapter 2: Run your first tests (and make them pass)

Index of this series:


A warning - the hours ahead that you spend on this will be chock full of error messages. Embrace googling error messages! When in doubt, google it, even if it’s meaningless to you! Somewhere on the internet exists hints and clues about what to do.

This skill set (googling for hints, using those hints to improve your googling, testing those assumptions, not giving up, etc) is known as technical sophistication.

Every time you encounter something unfamiliar, and google your way to an understanding and/or solution, you’re building technical sophistication:

In technology, a similar skill (or, more accurately, set of skills) [as mathematical maturity] exists in the form of technical sophistication. In addition to “hard skills” like familiarity with text editors and the Unix command line, technical sophistication includes “soft skills” like looking for promising menu items and knowing the kinds of search terms to drop into Google… along with an attitude of doing what it takes to make the machine do our bidding.

These soft skills, and this attitude, are hard to teach directly, so as you progress through this and subsequent Learn Enough tutorials you should always be on the lookout for opportunities to increase your technical sophistication… Over time, the cumulative effect will be that you’ll have the seemingly magical ability to do everything in every program.

- Michael Hartl, https://www.learnenough.com/command-line-tutorial

Technical sophistication aside, I’ve put together a list of trouble-shooting steps for errors various students have run into, and I’ve helped them resolve. If you hit a problem, check here to see if someone else has seen it too.

If you don’t see your error on this list, please ping me in Slack (@josh_t) (or email, if you’re not in the Turing Slack) and we’ll sort it out. Once it’s all fixed, I’ll update the troubleshooting guide.

>> Read more

Turing Prep Chapter 1: Make Mod 1 Easier Than It Otherwise Would Be

This is the first of a several-part series. I’m converting this gist into a series of pages, cleaning up the formatting, making it a bit more bite-sized and re-doing/adding some video walk-throughs.

If you’re impatient with the pace at which this guide is being published, read the above gist. Otherwise, sit tight and I’ll publish the rest soon.

This guide is a work-in-progress, so I hope you will reach out if you get stuck on anything. I’m in the Turing slack as @josh_t, or ping me via email at thompsonjoshd + google’s popular email service. Or, get your Github practice on by opening an issue on the Github repo that backs this website.

If you are working through this guide, and have a problem/hit a snag/get stuck/get really frustrated I’d like to hear from you.

I intend for this series to be started after finishing Turing’s Mod 0 program and Mod 0 capstone

If you don’t have enough time to work through these resources, no problem. Don’t work through it. This is simply a guide to make Turing a little easier than it otherwise will be. Most Turing students have done just fine without these resources.

Index of this series:

Why this series exists

This collection of articles is a guide that will make Turing’s mod 1 much easier than it otherwise would be.

We’ll do this by working on, (and completing) a few dozen small Ruby exercises.

You might be thinking:

Josh. This already sounds like a lot of work. I just finished my prework, and I know Turing’s gonna be brutal. Why should I do all of this optional work, instead of enjoying my last few days of freedom?

Good question. The answer is a digression and tortured analogy on the topics of:

  • screwdrivers
  • how to learn hard things
  • why you should do drills

By the end of this particular post, I have a few objectives for you:

  1. Understand the importance of bringing the right process to hard problems
  2. Decide to read A Mind for Numbers and Deep Work.
  3. Understand that spending a few dollars and hours learning how to learn is a fantastic start to Turing prep, where you’re spending a lot more than a few hours and few dollars to learn a difficult craft.

Driving Screws

If I handed you a Spax screw, and told you I’d pay you $1000 to screw it into a piece of wood, and then handed you a Phillips screw driver, what would you do?

Spax screws look like this:

spax

A spax screw. Notice the shape of the head.

One would use a Spax bit to drive the screw:

spax bit

A philips screw bit looks like this:

philips bit

Notice the shape of the head. This is shaped like a +, the spax is shaped like a *

Philips bits are for driving philips screws, which look like this:

philips screw

So, can you drive a Spax screw with a Philips bit?

Not easily.

>> Read more

2018 In Review & Thoughts on 2019

I find a lot of value in other people’s reviews of their years. It’s the time of year to be contemplative and reflective on the last 12 months, so here we are.

Note to reader: I’m posting this in May, 2019. I wrote it in late December, 2018, didn’t get around to finishing it up and publishing until… today. I actually like this phenomena, as I can now see goals I’ve had for 2019, and now that we’re almost half-way through 2019, I can see what I’ve accomplished. I’ll in-line a few other comments where appropriate

I’ve done annual reviews a few times now:

I wish I had 2012-2014 reviews, but never wrote them. Therefore, I will write one for 2018 (and future years, most likely).

Annual Review Process

Hacker News surfaced this post a few days ago. I like the format:

  • Look through your calendar, week by week, over the last year
  • Find the things that you found most valuable, and most disliked
  • Figure out how to do more of the things you found valuable/enjoyable/meaningful, and less of the things you disliked or found least valuable.

So, this in mind, my last year falls into a few broad categories:

  • Relationships/friendships/community
  • Rock climbing
  • Software development
  • Reading
  • Travel (which dovetails into the first two categories)
>> Read more