Skip to content

Instantly share code, notes, and snippets.

What would you like to do?
letter from Josh to parents about to begin 2005-be

this guide has resources that you won't find anywhere else, including answers to the ruby exercises questions and video walk-throughs that are not easily discoverable elsewhere. These things will all support your learning goals!

👋 and hello!

You're getting ready to start Turing's back-end program soon.

You've likely taken some (or all) of these steps, plus many other ones, to prepare for what's to come:

  • Quit your job (or already turned in your notice). 😱
  • Taken out substantial loans to fund your tuition and living expenses for the next year
  • Alleviated the concerns of inquiring friends/family. ("No, it's not strange to spend seven months in a basement." "A degree? No, but I'll have a sweet Github repo full of cool projects. Oh, Github is a tool that software developers use to...")
  • Told many incredulous people why you're doing all this.

You have some big goals. You know what the going rate is for "software developer", and you did the back-of-the-envelop math. This is a big commitment, and a big risk, but it's a reasonable commitment with reasonable risk.

So, lets talk about that risk.

What's the risk on the table?

Well, you could start Turing, and you could not graduate the program!

That's probably the biggest risk. Much less catastrophic, but still expensive and time consuming is having to repeat a mod.

There's nothing wrong with repeating a mod, but as much as possible, you should want to reduce the likelihood you'll have to repeat.

I "bucket" reasons for repeating into two categories:

  • forced repeats
  • unforced repeats

Forced repeats

If you get really sick (and Covid-19 is running around right now, so theres a greater-then-usual chance you get quite sick), missed a week or two of classes, that would probably mean you'd have to repeat, and that would be a forced repeat. You were forced to repeat by circumstances beyond your control.

Other examples, all of which have happened in recent modules:

  • Having to take care of a very ill friend/family member
  • A housing situation implodes, forcing someone to spend a lot of time and energy figuring out where to live
  • Flare-up of a chronic health issue (often these kinds of things are more likely in high-stress environments)
  • Plenty more examples

Unforced repeats

Unforced repeats are where the rest of this document is going to focus. Unforced repeats would be where you had to repeat a mod for reasons well within your control. These tend to materialize like:

  • Not realizing Turing is substantially different than college, and failing to adjust one's approach to learning the material
  • Bringing the wrong set of "learning tools" to the table, or applying the right tools innefectively
  • Disregarding best practices when it comes to "learning how to learn" and how to practice.
  • Not asking for help when needed. (Being stuck for 30 min is fine. 4 hours is not fine.)
  • Not helping the Turing community help you

I'm talking about this all because Turing is hard, and as much as it is in your control, I want you to be well prepared.

Especially because the more prepared you are for Turing, the more you'll learn throughout the whole program, and you'll be that much stronger of a developer when you graduate.

How to be particularly well-prepared for Turing

I want you to prepare well for Turing. Broadly, there are the three things that I think will prepare you well.

If you've not already wondered why to trust me, you might be starting to...

Josh, you're doing a lot of talking and making some bold claims. Why should I devote my scarce time and resources to doing what you suggest instead of all the other things I could be doing?

Great question.

  1. I've been working with Turing students since I graduated Turing in August of 2017. I've worked with dozens-to-hundreds of Turing students.
  2. For the last few months, I've had phone conversations with every single student who's had to repeat mod 1 of the backend program. Literally. 30 minutes, at least, during intermission week before they started mod 1 the second time, and once again, week six, after they found out they were moving on to mod 2. (so far, all have graduated the mod their second time around.)

I was always trying to uncover in their own words what went better the second time around than the first time.

Every single resource I've put together for you is directly informed by time I've spent with students in your shoes, with an emphasis on interventions that may have allowed a student to not repeat the first module.

I could pick more reasons I think you should trust me, but I won't list them until I know what I find compelling. So, if you, reader, read this line, and still don't find my arguments compelling, lets sort this out!! We'll hop on a call in slack, and we'll chat. If I can convince you to that I'm correct and trustworthy, you'll be better off for now having a trustworthy guide, and I'll update this spot of this document to convince future similarly-skeptical readers.

1. Have correct mental models of how to learn

I cannot emphasize this enough. Quoting wikipedia

A mental model is an explanation of someone's thought process about how something works in the real world. It is a representation of the surrounding world, the relationships between its various parts and a person's intuitive perception about his or her own acts and their consequences. Mental models can help shape behaviour and set an approach to solving problems (similar to a personal algorithm) and doing tasks.

Lets expand on one of those lines:

It is a representation of the surrounding world

Would you like your mental representation of the surrounding world to be accurate or innacurate?

Here's the same question phrased differently:

Would you rather understand the sun to revolve around the earth, or the earth to revolve around the sun?

Understanding why the sun rises in the east and sets in the west is much easier with a correct mental model of the world.

Here's how to pick up the necesary mental models:

Read or listen to these books:

  1. Deep Work: Rules for Focused Success in a Distracted World
  2. A Mind for Numbers: How to Excel at Math and Science (Even If You Flunked Algebra)

Rent them from the library, buy the book on Amazon, get the audio book from the library or Amazon, I don't care. If you cannot get a copy, and don't have money to buy a copy, tell me and I'll buy you a copy, and I'll expect payment only in that you give the book to another Turing student later.

Josh! OMG, no, I'd never ask an internet stranger to just buy me a book...

The time and emotional labor that I would spend trying to help you avoid repeating the mod (or, god forbid, failing out of Turing) will be vastly more costly to me than the few dollars of me buying you that book.

I'm not kidding in the slightest. If you read this document, and later find out you're failing the mod, and ask for my help, I will help you, but I'll be disappointed you didn't bother implementing my recommendations when it could have been much more beneficial to you.

2. Apply those correct mental models to the actual work of learning

Work through all of my backend prep guide.

You'll find that this guide has you soon working through the ruby exercises repo. There's plenty of confusing things inside the repository.

It is imperative that if you get stuck on something for more than 30 minutes, you reach out in slack. DM me, or use the 2005-be-parents channel and float a request for help there.

I'm working hard to get you all prepared for the mod, and it's very possible that information I've given someone in that channel will benefit you when you run into a given issue.

3. Using these mental models, get a lot of practice writing code

Here's a suggested order to work on the ruby exercises. The structure is folder/file, so the first item shows that strings.rb is inside the data-types folder/directory:


Josh, these explanations are confusing, and I'm having trouble getting started

GOOD! Please tell me when you run into trouble.

How long to struggle on something

Thirty minutes.

If you hit the 15 minute mark, head to and start taking notes. Here's what to include:

  • the file or exercise you're working on
  • what you're trying to do
  • what you've done
  • what sort of output and errors you're seeing

Then make the gist, toss it in slack to me or in the 2005-be-parents channel and ask for help. you will receive help.

here is much more information on why it's worth asking questions well

Josh, 30 minutes sounds like a short time. I'm supposed to "embrace the struggle" and something, so isn't this just giving up?

No. Any answer/help I (and anyone else) will supply would help you get unstuck, yes, but will also give you information on how to find the solution (or a similar solution) for yourself in the future.

The shorter the feedback loop, the better.

Cheats and walk-throughs.

Here's the stuff that some folks will be uncomfortable, knowing I've shared it.

  1. My solutions to the ruby-exercises

I've got answers to most of the ruby-exercises that you're working through, and you can view them here.

That link takes you to a forked version of the ruby-exercises repository, and I've pushed up a branch of my solutions. So, navigate the repo, find the exercise in question, and you can see my solution.

  1. Advanced video walk-throughs of the ruby-exercises

I've got a lot of video walk-throughs to the ruby-exercises directores. You've likely crossed paths to some of them, but here are some not in the Turing curriculum:


This comment has been minimized.

Copy link

@Arique1104 Arique1104 commented Apr 22, 2020

Thank you! I've realized that I've been stalling way too long between getting stuck, taking a break, and asking for help. Most of it is the back and forth need b/c of scheduling and wanting to be in front of the computer at the same time. Another thing is that taking the time to write out my question feels burdensome. Like, now I have to go back, hope I didn't clear the terminal, and run through all the things that I tried (add a little guilt here because you want to somehow prove you've suffered enough to "earn" help) and wrap it up with fucking formatting and you might start to see why I'd just rather not.

I think what has been helping me now is writing stuff down on the Technical part of the Josh files. It's been helpful for me to just track my thought process, compare what I've done, copy+paste from my terminal as I go, and if none of it worked, then I have an awesome chunk of information that I can either ask you to review or copy and paste onto a slack channel. That's been my preferred mode of working right now as I also try to more fully embrace the unlocked potential I have around rubberducking.

Speaking of rubberducking! Here are my peeps!

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