Introducing Learn Prime: Subscription access to everything we teach.

Today we’re happy to announce Learn Prime, a subscription service which gives you access to everything we teach. Your monthly $99 subscription gets you ongoing access to all of our books, screencasts, and even all our in-person and online workshops. Our workshops alone are normally over $1,000 when purchased individually!

In addition to our existing materials, we’ve created a new stream of articles only available to subscribers called Learn Bytes. We’ve already published Bytes on using subdomains in Rails, tricks for finding where a method is defined, and faking out a remote service using rack-test, with much more to come.

Subscribers also receive access to something we (humbly) consider the best resource of all: our team. Got a burning Ruby question? Need help testing something tricky? How about another set of eyes on a pull request? Head to our private Campfire room or send an email, and a thoughtbot developer will help you out.

Our goal is to create more great designers and developers. We hope this new subscription service makes our workshops and other learning materials available to even more people.

We’re are also introducing Prime for Teams. For $1999/month your entire team of up to 25 people can get access to everything provided by Prime. That’s less than the cost of your team’s daily pourovers! And for a limited time, as a special launch discount, the price for Prime for Teams is only $1299 per month!

We hope you’ll join the community of people who have already subscribed to Learn Prime. Find out more at Learn.

Introducing learn.thoughtbot.com

Back in May we released the Trail Map a collection of straightforward, structured answers to questions like: “How do I learn Ruby on Rails? Vim? Test-Driven Development?”

The Trail Map came out on top of all of the great learning material you could already get from us: this blog, the new podcast, the playbook, the Backbone.js book, several screencasts and videos, and in-person workshops in Boston and San Francisco. Some of this content is paid, and some of it is free.

We started to think about a grand unified theory of learning from thoughtbot, and today I’m happy to announce the release of just that: learn.thoughtbot.com.

On this one website you can now find a directory of all of our educational references, purchase all of our paid products and register for our in-person workshops.

learn.thoughtbot.com contains content we’ve created but also lots of content created by others that we’ve curated. Many of our resources link to third-parties that you may already rely on: PeepCode, Pragmatic Programmers, O’Reilly, and others.

We plan on continuing to actively create and curate content. If you have something you think should be added, please email us at learn@thoughtbot.com.

Trail Map

> How do I learn Ruby on Rails? Vim? Test-Driven Development?

Someone asks us these questions weekly. We think we finally have good answers.

Extracting answers from apprentice.io

apprentice.io is a program designed around 1-to-1 mentor-to-apprentice relationships with a heavy emphasis on pair programming.

However, each apprentice additionally has extra time each week to study topics of their choice. They set goals with their mentors and are held accountable to reaching them by publicizing the goals in an internal wiki.

Example goals include:

• Read chapters 14 and 17 of The RSpec Book.
• Review and merge a pull request on an open source project.
• Write blog post about anonymizing data.

One curriculum does not fit all

We’ve been calling each apprentice’s wiki page their “trail map”.

To us, the “trail map” metaphor relates to hikers, bikers, and skiiers:

• start in different places
• want to go to different places
• often change direction mid-journey

Likewise, apprentices (and anyone learning a topic):

• have different past experiences
• have different learning styles
• change their goals mid-process

Announcement!

With 12 apprentices in the apprentice.io program, we’ve noticed common patterns in each apprentice’s trail map.

So, we’ve consolidated trails into a default trail map and we’re pleased to now announce its release under a Creative Commons Atribution license.

You’re free to use the trail map however you’d like, even commercial training.

Initial trails

The trails exist as a single git repository on Github named Trail Map:

• Git
• Postgres
• Rails
• Refactoring
• Ruby
• Test-Driven Development
• Unix
• Vim

We hope learners everywhere will fork these trails for their own learning purposes and submit improvements via pull requests.

Each trail has three sections:

• Critical learning
• Validation
• Ongoing reference

Critical learning

This section lists things like books or blog posts to read, screencasts to watch, code to read or write, and koans or tutorials to complete.

In each topic, we aren’t aiming for greatest depth, but rather the most efficient way for the learner to become productive.

For example: we suggest chapters, rather than entire books, to read.

Validation

This section lists simple tasks the learner should be able to perform during routine development. We’ve never liked quizzes or certifications, but some hueristic is useful for assessment. We think self-assessment is a simple, fast, and low-stress approach.

For example: we say you know everyday git when you can (among other things), “stage a file, create a commit, and push to a remote branch.”

Ongoing reference

This section lists things like man pages and API documentation which we’ll always reference regardless of experience. Many things are not worth memorizing.

For example, we suggest that a developer refers to man git-rebase during a project.

What’s next

This is a work in progress. We plan to add and edit trails as new resources are released or people tell us better ways they’re learning a topic.

We’d love to get your feedback in the form of Github Issues.

Written by Dan Croak.

I Suck at Testing

Testing is widespread in the Rails community, which is awesome.  For most new developers, learning to test is not simple.  New developers often think testing should come naturally if you can code well. I mean, I wrote the code, I should be able to write a test for it, right?  Over the past 2 months at thoughtbot I’ve come to learn why this is false and now I’m learning to test.

Testing is Hard

Testing is like any other skill, you have to practice to get good at it. Good test driven developers use previous experience to figure out what tools to use when presented with   new challenges. Don’t get discouraged when you don’t know how to test something, just take a step back and evaluate the problem. Improving your testing skill also requires discipline and persistence.

Testing is a discipline

No matter how dedicated you are to testing, there are times when it will slow you down.  At that point, its really easy to skip testing, just this one time.  It takes discipline to make sure that doesn’t happen.  Take the extra time, invest the extra effort and find out how to test it, and then in the end your development process will speed up.

Ask for help

The Rails community has tons of people willing to help.  If you get stuck on testing something, google first, then check out the Rails forums or the Rails IRC channel.  Don’t hesitate to comment on blog posts which come close to solving your problem, but fall short.  I’ve found the Rails community to be very helpful so don’t be afraid to ‘drink from the firehose.’

It gets better

Learning to be a good at test-driven development is hard, but being a developer is hard in general and testing skills must be practiced.  Once you start writing tests more regularly, you also learn how to write code that is inherently easier to test.  I joined apprentice.io to become a great developer and learning to test well is half the battle.  It’s ok to suck at testing when you begin, but practice makes perfect.  A great place to start learning is our Intro to Test Driven Rails Workshop, we have a course coming up later this month.  Soon enough, you will think in tests before thinking in code.

The vim learning curve is a myth

I’ve been speaking about and teaching people vim for several years now, and I’ve noticed a surprising pattern: people are literally afraid of learning the editor.

Over the years, the popular mythology around vim has become that it’s insanely difficult to learn; a task to be attempted by only those with the thickest of neck-beards. I’ve heard dozens of times from folks who are convinced it will take them months to reach proficiency.

These beliefs are false. Here’s what’s true:

You can learn to use vim in 30 minutes.

Go to your shell and type vimtutor. The tutorial that’s presented is excellent and you’ll be through it in no time. Once you’re done, you’ll have the rudiments needed to get your work done. You won’t be fast yet, no; but you’ll be competent. And even after those 30 minutes, you’re going to start grasping the ideas that make vim so amazing: the brilliant design decision that is modal editing, the composability of commands, the clever mnemonic naming of commands. These will be enough to make you want to learn more.

Learning vim is fun because it’s game-like.

No one ever says “I’d love to learn Street Fighter 2, but there are just so many combos!” People don’t say this because learning a game is enjoyable. You start off with just the basic kicks and punches, and those get you by. Later, you learn more advanced moves, maybe even by accident.

Learning vim is like this. At first, you do everything as simply as possible. Then you start to wonder if there are faster ways to get things done, and there are! If you chain those commands together they just work! You bump into things accidentally, or maybe you spend some time in the extensive help files. Over time, you burn a few advanced tricks into your muscle memory.

Soon, you realize there are many ways to accomplish your edits, and you strive to do them in as few keystrokes as possible. This can be incredibly satisfying, particularly to us technical-types that seem to have a higher-than-average appreciation for efficiency. It may be hard to believe that trimming one keystroke off a command will one day trigger a dopamine response, but I swear it’s true. Just ask these guys.

You’ll be faster than your old editor in two weeks.

If you use vim all day and make an effort to use it well, you’ll be editing code faster than you did in your old editor within two weeks. A couple tips to help you on your way: keep a cheat sheet of commands you’re trying to commit to memory, find a friend that’s an experienced vim user for the many questions that you’ll have in the beginning (ask in #vim if you have no such friend), and pay attention to things you do that feel inefficient (there’s almost definitely a better way). If none of that works, reach out to me on twitter and I’ll try to help you out.

It’s effing worth it

There’s a reason everyone at thoughtbot is using a 20-year-old text editor. There’s a reason I’ve flown to other countries to try to convert more vim users. There’s a reason people love this editor. Maybe you should find out why.

Good luck! And happy vimming.