The Tutorial Anti-Pattern

Here’s a scenario: you’re applying for your first tech job. You’ve found a bunch of hands-on tutorials and you’re speeding through them. When you finish, you upload the code to Github and add a new line to the ‘Projects’ section of your resume. Maybe you even deploy the code as a production website. My advice: stop.

Tutorials are fun: you get to work through tough problems, like building an application with authentication, social posts, and tests, and learn to deploy to production. It feels like you’re accomplishing something.

I call this an anti-pattern, which Wikipedia defines as “a common response to a recurring problem that is usually ineffective and risks being highly counterproductive.” There are better ways to invest your learning time during your first job search, and beyond, than tutorials.

So what’s wrong with tutorials?

Zero Sum

When preparing a portfolio, we want to stand out from the competition. Tutorials don’t support this.

Anybody who can type can complete a tutorial. In fact, some tutorials include links to a finished repo, so a person could fork the project and deploy it as their own attributed or unattributed work. The easier a job search technique is, the less distinguishing it will be.

I’ve spent years hiring developers; I tend to ignore tutorials on a resume because they tell me little about a developer’s potential.

Missed Learning Opportunities

When you follow somebody else’s completed project, you learn less than doing something even much less ambitious yourself.

For every contrived problem in a tutorial there’s a simple and proven solution right the page. You miss out on a ton of learning. The person who created the tutorial earned that expertise by solving the problems themselves.

Further, when you get into the field, not knowing is a constant. Start getting comfortable with it now.

Missed Conversations

Tutorials rob you of valuable conversations that might lead to a job, or possibly save you months of beginner mistakes.

When a new developer writes their first lines of code, it’s guaranteed to be filled with opportunities to improve. This job is a craft and everybody has to earn their expertise.

I love seeing code like this. It initiates a conversation between two practitioners that makes us both better. When you ship a tutorial, you miss this conversation. I don’t get to see who you are as a developer.

Mental Model Mismatches

Programming is abstract; we don’t get to hold our creations in our hands like a woodworker. And so a vital tool for learning and talking to other developers is mental models. Mental models how we turn those abstract ideas into working software.

When you follow a tutorial you are trying on somebody else’s mental model instead of building your own. To me this is an extra challenge.

Errors in Source

Often the source code in a tutorial, especially a printed tutorial, is wrong! A single typo can introduce a momentum-destroying distraction.

I’ve spent hours stuck on a single line of a tutorial, trying to parse a cryptic error message. Go through any popular tutorial and you’ll find pages of online posts with titles like “Fix for RSpec test typo, Rails Tutorial Chapter 2.2”. Think about that: dozens of people spent hours working around a single typo in a tutorial. What a waste.

Exceptions

Tutorials are okay for brand new programmers. And I do read the official ‘Get Started’ guides on popular open-source projects. Once you’re past either of these steps, I think tutorials hold you back.

Conclusion

So, what’s the path forward? Randall Kanna calls this Tutorial Hell, and she offers a great solution:

Start building now.