Code Immersion Handbook
Welcome to Code Immersion
First Mentor Meetings
Mentor Meeting Notes
When to Google
Asking for Help
Debugging is Science
Breakpoints and Debuggers
Rubber duck debugging
Driver & Navigator
Top Down Design
Projects are better than problems
Start concrete. Then abstract.
Where to Start
Git & Github
1. Validate emotions
2. Be less helpful
2a. Ask more questions
2b. No feedback unless requested
3. Don’t mess with flow
4. Escalate quickly
Finishing the program
Welcome to Code Immersion. We are likely unlike any program you’ve done before so this Handbook will help you learn how we work and how to be successful here.
We want you to get started on your first day on the right foot. We'll introduce you to your mentors and add you to our group Slack so you can get your bearings before you even walk in the door.
One week before your program starts, we will reach out to introduce you to your Staff Mentor and Peer Mentor. You will schedule a time to chat with each of them 1:1 over Skype or Google Hangout before you arrive for your first day at the program.
At the same time, we will add you to our team Slack so that you can introduce yourself and we can all say hi.
In #introductions, tell us a bit about yourself and what you’re hoping to get out of the program. We will all welcome you with emojis! Scroll back on that channel to see the introductions of those that came before you.
#questions is the Slack channel where you can be helped by the staff and your peers asynchronously whenever you get stuck.
#pairing is the Slack channel to ask for a coding buddy to help you with a new technology or debug a tricky issue. You can also volunteer yourself to pair if you’re looking to take a break from your own work. More on this below.
#review is the Slack channel to ask for a code review from your peers and the staff. Especially in the beginner, we recommend that you submit almost every piece of code you write for review. More on this below.
You will meet with your Staff Mentor a minimum of 2x each week. Your first meeting will be towards the beginning of the week, usually on Mondays, to set the direction and goals for the week. The second meeting will be at the end of the week, usually on Fridays, to review your progress and begin thinking about next week.
The aim of your Staff Mentor meetings will be to suss out your goals in learning to code and craft a path towards accomplishing them. To this end, Staff Mentors will ask questions like:
Everyone’s goals are different. To give you an idea of the wide array, students say things like:
When articulating your goals in your Staff Mentor meetings, let your curiosity guide you. Have you always wondered how a computer works deep down? How about the differences between programming languages? Have you been harboring the next big app idea and want to bring it to life? Do you desperately want to know how to hack your ex’s computer to rekindle the relationship? Just kidding on that last one.
From there, your mentor will help you brainstorm a list of projects to tackle. The projects will be crafted with increasing difficulty so that you can build your skill over time. You might start with a simple project that takes a few hours, move to a project that takes a full day, and end the week with a multi-day effort. Through these meetings, we co-create your curriculum each week in what we call “project playlists” to help you build your skills towards accomplishing your goals.
It can be embarrassing to bring your daily challenges to a expert programmer. It’s less intimidating to ask silly-seeming questions to someone that just asked those questions a few weeks ago. That’s why we pair you with a Peer Mentor that’s slightly ahead of you in the program.
Every morning that you don’t meet with your Staff Mentor, you’ll meet with your Peer Mentor to guide you throughout the week. Your peer mentor meetings help you re-center at the beginning of each day, keep you productive during the week, and moving forward through your project playlists. If you stall out without much forward progress for a day or two, your Peer Mentor will help you triage the problem, be it by tweaking your weekly playlist, pair programming through a tricky technology, or debugging a persistent bug with you.
After you’ve been around for a couple of weeks, you will be paired with a mentee of your own. Through mentoring, you will be able to pay forward the wisdom you received and reflect on how far you’ve come in a few short weeks.
Now, I’m going to let you in on the BIG SECRET. This program is not about coding. Suprise! Programming is simply the wax-on and wax-off of a much deeper skill. It’s all in your head. No really. We think that the most important thing you can do is have the right mindset.
If you’re reading this, you may be overwhelmed about the thought of learning to code. You may even wonder if you’re smart or naturally talented enough to cut it. That’s understandable. Learning something new is intimidating.
The cornerstone of a positive mindset is belief. You have to truly believe in yourself, even when it’s frustrating and it seems like you’re never going to get it. Unfortunately, it’s not that simple. If only I could say “believe in yourself”, and you did, then we could all go home.
But seeing is believing. If you can do something today that you couldn’t yesterday, you will be able to feel your progress and your mindset will adjust. Through learning to code, you will cultivate an optimistic, gritty, and growth-oriented mindset. When you leave here, you will be confident in your ability to learn new technologies, protocols, frameworks. You will truly believe in yourself.
But don’t get me wrong, you do actually learn to code here. That’s the point. You develop the right mindset through coding. But the coding is key. No coding, no progress. No progress, no belief, No belief, no mindset.
There are three dimensions of pessimism, the three P’s:
With practice, you can catch yourself being pessimistic and turn each P around optimistically:
The scary thing about your mindset is that whatever you believe has a tendency to come true. If you believe you are stupid, are bad at math, or cannot learn to code, you’re right. If you believe you can improve with effort and become amazing at anything you set your mind to, you’re also right.
Growth mindset is a muscle and reflex you build over time. It’s the replacement chanting “I’m bad at this” or “I’m stupid” or “I’m never going to get this” in your head with “I am going to get better at this” and “I’m smart” and “I will get this if I just keep trying.”
Even if you have a growth mindset towards some things, that doesn’t mean you’ll have the right mindset towards others. However, we find that you can leverage a growth mindset in one discipline to develop one in another. You can reflect on how you were able to learn something that you thought impossibly hard, which means that you can do it again with this new thing in front of you that seems even harder. This is the cornerstone of our program: we see coding as a hard thing for you to learn to prove to yourself that you can learn any hard thing.
That’s why you must reflect. If a new coder learns something in a forest but does not reflect on it, does it make a sound? No, it does not. Nor does it help you adjust your mindset.
Reflection is the most important part. That’s why we have dedicated times every day, twice a day, for reflection, once during your morning mentor meeting, and once during your afternoon journaling.
Your development journal is the source of truth for all information regarding your program. It will contain your weekly playlists set in your Staff Mentor meetings, your daily plans to tackle them from your Peer Mentor meetings, any amendments to your playlists from your Peer Mentor meetings during the week, your daily reflections, and your big end-of-week reflection with your Staff Mentor.
We set aside 15 minutes at the end of each day for you to reflect in your journal. You are welcome to keep it on a number of tools, including blogging platforms like Blogger or Medium, or document tools, like Google Docs or Evernote. While it’s not terribly important whether or not your blog is public to the world, we ask that you share your posts with your mentors so they can track your progress throughout the week and reach out to help when they see the need.
The main question you will reflect on in your journal each day is:
We also ask that you reflect on the following questions in your journal, but you don’t need to address each question every day:
We also ask that you keep your journal open to take notes during your mentor meetings, so that we can track your playlists and the progress you make on them all in the same place.
The vast majority of your time here will be spent programming. In order to become a good programmer, you need to develop the following practices.
Beginner programmers often chide themselves for not remembering syntax and having to repeatedly look it up. When a beginner watches a senior engineer code, they are surprised to see that they reach for Google just as frequently as they themselves do. Programming is too large and fast-moving for you to learn it all. The best you can do is learn the core concepts and know how to find what you need when you need it.
Googling is most useful the more specific you can be about what you want to accomplish. For example, “center a div with css” is better than “center the page” which is better than “make a website.”
You don’t need to type a full sentence with a question mark into Google. Just give it the relevant keywords. Be sure to include name of the technologies you’re working with or their abbreviations, like HTML, CSS, JS, React, etc.
Most of the time, what you’re looking for will be in the top three Google search results, but you may have to try all three to find it. Pay special attention to results from Stack Overflow, W3Schools, and developer.mozilla.com.
If none of the first three links look helpful, tweak your keywords a bit. If you can’t find what you’re looking for after a few searches, ask a friend to help you pick better keywords. Over time will develop a sense of what keywords will help you get what you want.
Technologies change quickly. That’s why it’s paramount that you know how to read technical documentation and teach yourself new technologies as quickly as the industry moves. Don’t be put off if you don’t understand everything (or even most of it) the first time you skim through a new documentation. Most programmers have to read through documentation multiple times before they have a firm handle on a new technology. If you’re having trouble, try explaining how it works to a friend who knows that technology so they can help you correct the gaps in your understanding.
When you first arrive, we recommend that you ask for help early and often. Don’t worry about asking too many questions. If we think you are asking a question that you can figure out yourself, we will tell you and leave you alone to tinker with it. Don’t waste hours and your precious mental energies battling with silly syntax errors on your first few days. Over time, we will push you to spend longer and longer periods of time puzzling out issues by yourself.
Contrary to what you may expect, only a small amount of your time programming will be actually writing code. Most of the time you’ll be debugging the code you’ve written to get it to work properly.
The most important thing to remember is that the computer only does what you tell it to. This means that if the computer isn’t doing what we want it to, we need to figure out where we tell it to do that, and how we can change it to reflect what we want.
As explored in Zen and the Art of Motorcycle Maintenance, it can be helpful to think of debugging as a scientific exercise. First you have to generate a number of hypothesis about what could be causing the bug. Then you come up with ways to test those hypotheses and carry out the tests. You repeat this process until you’ve found the bug, and you can begin work on fixing the bug.
If you get tired of littering your code with print statements, most programming languages have debuggers that can serve a similar purpose. They allow you to set a breakpoint in the code, which will cause the code to pause in time when it gets to that line.
If you’re having trouble finding the bug in your code, one technique you can use it commenting out large sections of your code until the bug goes away. Then you can uncomment your code chunk by chunk until the bug comes back. When it comes back, you can use this technique within that larger chunk to further isolate the bug to the line(s) that are causing it.
When you ask for help on a problem, you will often find that you figure out the issue yourself before they even get a chance to say anything. This is because articulating your problem is often halfway to solving it entirely. So if you don’t want to waste another person’s time listening to a problem that you won’t need their help solving, you can try the Rubber duck debugging technique, where you explain your problem to a “rubber duck” to help yourself better understand your problem. You can also explain the problem to an imaginary person in writing if you don’t want to look like a crazy person, and that way you can send it to a friend if you still need help.
As they say at the Recurse Center, the one mistake you can make here is not doing enough #paring. You may never again be in an environment so perfectly suited for collaborative learning. Take advantage of it. When in doubt, do more pairing. At a minimum, you should be pairing twice per week.
When pairing, it’s useful to explicitly state who will be the driver, the one with hands on the keyboard and mouse, and the navigator, the one directing where the project is heading. The navigator gives directions and the driver drives the car.
However, there are a number of collaborative software tools that allow you to both have your “hands on the keyboard.” For example, Cloud9 has a google-docs-like interface that allows many programmers to edit the same files at the same time. In these situations, it’s less important to designate who’s driving and who’s navigating, but it’s even more important for both programmers to “think out loud” and not make any edits to the code without narrating them out loud for the other programmer to hear.
Collaborative pairing is when you pair with someone at a similar level of expertise with the given technologies as yourself. In this context, it makes sense to switch driver and navigator roles every 30 to 60 minutes. Set a timer so that you don’t forget.
When you are trying to get a handle on a new technology, it can be useful to seek out someone knows that technology to pair with. We recommend that the less-knowledgeable programmer take the driver role to start, so that they can better control the pace of progress and be sure to understand every line of code written. Only after the less-knowledgeable programmer demonstrates a reasonable understanding of the technology’s concepts and syntax do we recommend switching roles.
We ask that the more-knowledgeable programmer adhere to our “Ask more questions,” maintaining a Socratic dialogue. Instead of pointing, “You forgot a parenthesis there,” you would ask, “What line do you think the error is on?”
Debugging is a skill that’s as much emotionally taxing as it is logically straining. Well before you reach your wits’ end, reach out to #paring for a debugging buddy to help you through it. Oftentimes, you don’t even need a real person to serve as your debugging pair, because just the act of talking through and explaining your problem helps you see its solution.
Big problems are hard to solve. Top-down design is a technique where you break down big problems into smaller and smaller problems. Eventually the problems get small enough that you can solve them each one by one.
In practice, you can do top-down design by breaking your code up into functions. Start by writing code to solve your main problem that relies on functions that you haven’t yet written. It may feel strange to use functions that haven’t been written yet. Ignore this feeling and pretend that any function you can imagine exists -- all you have to do is name it.
Of course, you eventually have to pay the piper. You then go to and define each of the smaller functions you referenced and write their definitions. Here again you can refer to other “helper functions” whose definitions you will write later. The key to this strategy is that when you finish writing all of the smaller functions, they will fit perfectly together well -- at least in theory.
Especially in the beginning, it’s important to have a more senior developer review your code so they can spot bad practices before they turn into habits and lead you in the right direction. We recommend that you get a pair of eyes on each line of code you write to start.
You can find peers and staff members to review your code in #review. It makes it easier to review code that’s in the right platform, like Github. If not, your reviewer will probably have to create a new version of your code with their notes scattered throughout your code as comments.
After you’ve been around for a couple of week, we recommend that you take time to review others’ code. It’s a great way to develop an eye for good code vs sloppy code.
At the beginning of each week in your Staff Mentor meeting, you will create your Project Playlist for the week. These projects will be of your own design and mapped to specific learning goals that you want to achieve.
Our program has a strong preference for projects over problems. Firstly, project-based learning leads to a much deeper, useful and lasting knowledge because it’s contextual learning. Instead of learning the basics of coding abstractly and devoid of any real-world context, with projects you learn to code in the service of making something real. This way you’re guaranteed to be learning something useful, and you’re also much more likely to remember what you’ve learned because it means something to you more than just a “right answer.”
We find that projects are much more intrinsically motivating to stick with and finish, while problem-based platforms like Codecadmey or Khan Academy as tough to see to the end in the absence of any external validation. You want to finish your project simply because you want to create something to be proud of that you can share with the world. Projects help you build out your portfolio of work, which can help you reflect on your progress and communicate what you’ve learned to peers, parents, and potential employers.
When trying to learn something, we recommend starting with the most concrete and simple things first. Then once you have a handle on the basics, you can build up to the more complex topics.
There are many tutorials online that claim to teach complex topics in a simple way. We call that the Monad Tutorial Fallacy. Building up an intuition about complex topics takes time. It’s hard and frustrating to try to skip to the end. Take your time and build up to it.
There are all sorts of frameworks that help you do things faster and easier than without them. It’s part of what makes programming so fun. However, we recommend learning to do things the hard way, the old-fashioned way before starting with frameworks for a few reasons. Firstly, frameworks change. If you learn a framework before learning the underlying concepts, you may be stuck when the industry moves on. Secondly, frameworks are leaky abstractions. When frameworks don’t do exactly what you need them to, you’ll often need to use the underlying technologies to close the gap. If you don’t know what those are, you may end up flailing. Most importantly, starting with the underlying technologies helps you intuit the problems and potential solutions for yourself. That way, when you go to learn the frameworks, you’ll understand the problems they solve and why they are set up the way they are
For example, we advise against starting with Ruby on Rails. We’d recommend starting with Ruby, then moving to a simpler Ruby web framework like Sinatra, and finally moving to Rails if you still think you need it.
Code Immersion was created by the team behind The Coding Space, an after school program for kids to learn to code. We believe that the same curriculum we use with kids can be useful for adults, especially if you’re brand new to coding and unsure of where to start. You can find the entire curriculum at http://coding.space.
If you’re brand new to coding, we recommend starting with a drag and drop platform so you can master some of the basics before worrying about syntax, like Scratch. These platforms are designed for children so they may seem childish, but if you can see past that, they are a wonderful place to start.
Once you have a handle on programming basics, there are a number of wonderful technologies you can move to next.
Ruby and Python are very popular scripting languages that you can use for a variety of tasks, like web scraping, data processing, web servers, and general automation.
We recommend starting with simple server frameworks to start, like Ruby’s Sinatra, Python’s Flask, or NodeJS’s Express.
At Code Immersion, you control the pace that you progress through different technologies and concepts. In mentor meetings, we can help advise you on what projects could be good for you to try next, but you always have the last word on what you want to work on. Sometimes you’ll move on to a project that’s too hard for you too quickly and want to come back down to a simpler project. This is common in a self-paced environment, because how else will you know if you’re ready to move on until you try it? Often times you’ll go up and back a few times between technologies until you feel comfortable enough to move on to a new platform, so we call this phenomenon “yo-yo-ing.”
We prefer using cloud-based coding platforms because there’s minimal setup and your code will automatically be saved to the cloud. Many of these platforms also make it easier to share code and collaborate.
Scratch.com and woofjs.com are good online platforms that are utilized in our beginner curriculum, coding.space.
For writing simple back ends, we recommend WebScripts. For getting more complex back-end projects off the ground quickly, we recommend Glitch.
For more complex projects, we highly recommend using Cloud9. It’s a text editor, file explorer, and terminal in one. Moreover, it allows you to collaboratively edit your files simultaneously with friends, and automatically create previews of your web projects as you develop them to share with for quick feedback. They require a credit card to sign up but will not charge it as long as you remain on the free plan, which works plenty well for beginners.
Most professional programmers set up their workspaces by downloading and installing software. We recommend starting with a simple setup with a text editor (either Sublime Text or Atom) and your computer’s built in terminal (unless you’re on a PC in which case you need to find one).
Some programmers invest a lot of time into learning an advanced text-editor like Emacs, Vim, or IDE like RubyMine. You are welcome to give these platforms a try as well.
Soon after you move to a full coding platform like Cloud9 or a Desktop setup, we recommend getting a handle on Git and Github, tools that enable a robust development workflow and seamless collaboration. You can start with this git tutorial and then move to creating your own project. Once you get the git basics down (adding, committing and pushing), you can move on to to branches and pull requests, and finally to advanced concepts like bisection and Github Pages.
We don’t bite. Everyone here has been extensively interviewed to ensure that we have a warm and welcoming environment. We all wake up every morning excited to come into the space.
In order to maintain this environment, we all follow a few guidelines.
When someone comes to you with emotions, “This is impossible. I’m stupid. I’m never going to get it. I’m not good at coding.”
Your first reaction may be to invalidate their thoughts, which has the effect of invalidating their emotions. “It’s not impossible. You’re not stupid. You are going to get it. You are good at coding.”
Resist that impulse. Instead validate emotions. “That sucks. I know how you feel. I get so frustrated when I code sometimes too. It feels like I’m never going to get through it. Let’s go grab a drink of water to clear our heads.”
If you’re reading this, you likely pride yourself on how helpful you are. Wonderful, we want helpful people in the space! However, sometimes the way to be the most helpful is to be less helpful.
Instead of telling someone the answer to their question, or even worse, doing it for them, can you ask a question that will lead them on the right path?
Unsolicited feedback can feel harsh and kill the excitement of a young project. Don’t give feedback, unless directly asked. If you’re really eager to give your two cents, you can ask “Would you like feedback at this time?”
Long stretches of uninterrupted time are a programmer’s greatest asset. If someone is looking at a computer screen, assume they are seven levels deep into a debugging session.
Don’t break their concentration by calling out their name from across the room or tapping them on the shoulder. Instead, you are welcome to Slack anyone at any time. That way, they are able to decide when to respond to you when they have a free minute. You are always able to zone in and focus by setting your Slack status to Do Not Disturb.
If there’s a problem, let us -- your Staff Mentor, Eli, Nicole or myself -- know as soon as possible. Don’t let things fester.
We don’t have artificially-determined program lengths, so you come for as long as makes sense for you right now. Everyone needs Code Immersion in different doses at different times in their lives. Come for as long as you want to, leave as you will, and return as you may.
Many students feel the urge to put together a portfolio or capstone project as their final effort before they leave, but this is not required. If you’re looking to get a job as a software engineer after the program, be sure to let your mentors know so you can learn the appropriate technologies, prepare for interviews, and begin your search.
The Recurse Center was a strong inspiration for our program and The Recurse Center Manual was the inspiration for our own Handbook. They, in turn, were inspired by the Unschooling movement led by John Holt and John Taylor Gatto.
Seymour Papert is the father of teaching children to code. His work with LOGO and Mindstorms set the stage for everything we do. We recommend reading The Gears of My Childhood and Teaching Children to Mathematicians to start and his first two books if you’d like to learn more. Steve wrote a eulogy for him when he died in 2016.
Learnable Programming is Bret Victor’s landmark piece about how to make programming intuitive for beginners. We treat it as our bible.
We draw on the works of positive psychologists Angela Duckworth, Carol Dweck and Marty Seligman for theirs insights on about grit (Grit), growth mindset (Mindset), learned optimism (Learned Optimism), respectively.