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.
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:
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.
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.
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.
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.
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:
Understand the importance of bringing the right process to hard problems
Decide to read A Mind for Numbers and Deep Work.
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:
A spax screw. Notice the shape of the head.
One would use a Spax bit to drive the screw:
A philips screw bit looks like this:
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:
So, can you drive a Spax screw with a Philips bit?
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
A while back, I picked up a bug where when a customer tried to save certain kinds of data using Chinese characters, we were replacing the Chinese characters like 平仮名 with a series of ?.
This will be a quick dive through how I figured out what the problem was, and then validated said problem, and then what the actual fix is.
This isn’t just a story about character encoding, though. It’s a story about debugging. Debugging skills are valuable, and just like any other skill, they can be sharpened. I have built some competence in this domain, and I wanted to record some of the process, in the hopes that it might help others.
I perceive good debugging to go hand-in-hand with asking good questions. I wrote Asking experts, and gaining more than just answers about how asking good questions is hard, but done well makes it easy for someone else to help you, and leads to deeper understanding of the space.
Debugging, to me, is just a skill. It’s an analytical skill, but fundamentally it is a skill that can be learned and developed through practice: you identify problems, analyze the system to figure out what is causing that problem, and then figure out the changes necessary to correct the problem.
Finding the cause leads to the solution. The fix might not be practical from a business perspective. If fixing this bug requires overhauling the entire app, it might make better sense to leave it than to pay what it would take to fix.
Good debugging is also a particularly useful skill a developer could bring to their job, and you don’t have to be an experienced developer to be good at debugging. You could argue good debugging is based more on attitude than technical know-how, so if you’re just getting your start in the software development industry, making sure you’re good at debugging things and then telling potential employers this could be to your advantage.
Here’s some more thoughts on this, from other developers (quoted anonymously from the DenverDevs Slack channel):
For what it’s worth, I had most of this blog post written before even seeing these quotes.
dev_1:
There’s the tiresome old joke about “I’m not better at computers/coding/etc. than you, I’m just better at google!” Ha. So funny.
But a truly under-appreciated skillset that I think doesn’t get its fair share of mention from experts/teachers/celebrity-bloggers or attention by some developers is debugging.
There’s often so much mental headspace put into the idea of writing code, good code, functional code, that “what do I do when I don’t write working code” is rarely addressed.
Even well seasoned (yum) devs are constantly surprised by features of browser devtools, that console.trace() exists alongside console.log(), and more.
I think it’s often seen as a side effect of what we do so much that we learn the tools and techniques as we need them instead of as a crucial skill.
I think making mistakes in your code and figuring out why the error/mistake is occurring is a great way to further comprehension of a language, don’t get me wrong. But so many people are never told where to look first when they don’t know why or how an error is occurring. They just feel like they’re going to a doctor and saying “it hurts” they don’t know where, they don’t know how, just, ouch.
