The Dev Bootcamp Rap Recap Repository

Here are all the Dev Bootcamp Rap Recaps I’ve uploaded to date. Thanks in advance for listening and pulling your friends over to your screen of choice so they can listen too.

Look for a new one each weekend here or at my homepage.

WEEK 1 (Full post with lyrics here.)


WEEK 2 (Full post with lyrics here.)


WEEK 3 (Full post with lyrics here)


WEEK 4 (Full post with lyrics here)


WEEK 5 (Full post with lyrics here)


WEEK 6 (Full post with lyrics here)


WEEK 7 (Full post with lyrics here)


Ten Things to Expect from Dev Bootcamp’s Phase 1

I made it out of Phase 1 in one piece, and now all I want to do is look back. That’s probably not the healthiest impulse, considering the likelihood that next week’s pace will make my last three seem like warmups. In the interest of moving forward, I’m going to pack my entire phase into one retrospective post so curious readers can see what it’s like at the beginning of Dev Bootcamp.

Word to the wise – your mileage may vary! Every cohort is different, and instructors group off in different ways each phase. And you are unique; you’ll bring to this experience a particular set of skills and expectations that will determine what you get out of your first phase on campus. I’ll try to stick with the big concepts in a way that doesn’t spoil any cool surprises. Hopefully you’ll find something useful here, something to help make you into a better coder someday, or at least help you make a decision about how you’ll be spending the next six months of your life.

Here’s what you should expect from the first three weeks at DBC.

Expect the first week to kick your ass. It’s a system shock akin to being thrown into Lake Michigan in May. While you’re asleep. And mostly naked. You’ll hit the ground running on your first day, bouncing between welcome meals and things-you-need-to-know lectures and personal introductions and code. Yes, there will be code. And it likely won’t be code you enjoy writing. The first week is basically about building algorithms, the little script machines that work under the program’s hood to manipulate data and generate results. It’s a lot of math-y stuff, like telling a computer to look at a list of integers and spit out only those that are evenly divisible by 17, or figuring out how to take a number and convert it into a different type of notation.

There are also a lot of activities that deal with string manipulation, and you’ll even dip your toes into regular expressions, which are basically chunks of gibberish that isolate relevant patterns with the precision of a Google search. When you hear about regexp’s, you’ll be scared and want to avoid them. Do that if you want, but it will cost you a ton of time and energy better spent learning the new tool, and eventually you’ll learn it anyway. This cycle – fear, intentional ignorance, reluctant engagement, begrudging acceptance, and then habitual usage – is at the core of the DBC process. Get used to it, and try to skip ahead to the reluctant engagement part as soon as you can.

By the time you’re done with the first week’s challenges, you’ll have gained a new appreciation for some of the more powerful methods in the Ruby arsenal. To put it another way, you don’t really love your staple remover until the day someone makes you pull out a hundred staples with your fingernails. A lot of boots say the first week of Phase 1 is one of the hardest weeks overall because the material is dry and largely unrelated to the work you’ll actually end up doing as a web developer. But it’s there for a good reason, and you’ll have to learn it if you want to be solid during the rest of the phase, so strap in and hold on tight. You can make it. Even through Sudoku, you can make it.

Expect to stay classy. There’s this thing called object-oriented programming, and it’s all about getting parts of your program to play nicely with one another. That means making sure each part does exactly one thing and doesn’t spend too much time prying into the business of the other parts. After you get past the algorithms from the first week, your focus will shift to OO design practices almost immediately. This will make you dizzy. You’ll be trying to keep track of a class you created, what its variables are, what it inherits from, how to call methods from it, and then all of a sudden you’ll hear, “Oh, make sure you don’t put that there. It’ll work just fine now, but your program will be really hard to upgrade later if you do it like that.” If this was an English course, you’d be learning the basics of nouns and verbs while trying to match rhyme and meter. It’s daunting stuff.

And once you get the hang of it, it’s also the most rewarding stuff so far. Harness the power of Ruby objects, and you’ll be able to build facsimiles of real world systems in code, which is mindblowingly cool. You can make a Band object that contains a bunch of Musician objects and then call something like awesomesauce.kick_out(narcissistic_lead_singer) to make your group sound better. You can make a Congressperson class that inherits from the LazyBully class and add a lot of unfortunate dependencies to it. As I type these words, I notice that each of my arms happens to be an instance of the Gun class. 

The point of all this is to stop thinking of programs as singular things that run in a set order, and start thinking of them as groups of objects that talk to each other in specific ways. This mindset shift is at the core of the OO movement, and it can be hard to wrap your mind around if you come from another school of thought. Don’t worry. You’ll get plenty of practice learning design by making real-ish things and then realizing why they’re not working right (hint: you didn’t whiteboard enough).

Expect to stretch. I have some bad news for you: you have no idea what you’re capable of. Luckily, Dev Bootcamp is here to help you fix that. To unlock your maximum learning potential, they will do everything they can to shake things up and keep you on the outer edge of something called the stretch zone.

Picture a slice of cake, because cakes are circular and delicious. At the tip of the slice, the center of the circle, is your comfort zone. You know exactly what’s going to happen when you take your first bite. It won’t fall off the fork and you won’t bite off more than you can chew because that first part of the slice is so darn thin. In the comfort zone, results are utterly predictable, contentment is totally guaranteed, and growth is absolutely impossible. You don’t want that. Everyone will know you as the person who only takes the first bites of cake slices, which is kind of weird and more than a little pathetic.

At the other extreme is the panic zone, the outer edge of the cake that’s basically all frosting. Have you ever noticed how cloyingly bitter cake frosting can be all by itself? It’s terrible. Once again, you’re not eating cake, but you’re probably thinking all about it, wishing you could go back to a better cake/frosting balance, even if it means being the “first bites only” weirdo. When you’re panicking from overwork and lack of understanding, your brain shuts down and seeks comfort. But you didn’t pay 12 grand for a cake to nibble at frosting and skinny slice tips. You’re trying to eat some cake here!

So Dev Bootcamp sets you up in the sweet spot, that outer-middle ring of cake where the batter isn’t undercooked and the frosting is just starting to get deliciously thick. That’s the stretch zone, where you’re getting the most calories per fork-bending bite. Except instead of calories, it’s aha moments and hours of focused practice and opportunities to grow in groups. Less delicious, but ultimately more fulfilling. DBC wants you to be safe while you’re here, but safe isn’t the same as comfortable. There will come a day in your first phase when you’ll feel like there’s too much work to do and you’ll never get it done, and you’ll reach out for something, anything you can understand. And then you’ll look at your hand and see that you’ve grabbed on to the thing that made you this afraid yesterday, because in 24 hours your phobia morphed into your security blanket. That quick learning turnaround can only happen when you’re living in the stretch zone.

Expect to stretch. That’s not a typo. You’re going to do some yoga. It’s only five sessions over the first three weeks, but it’s still exercise, and it’s morning exercise, and it will probably make you sweat. You’ll want to bring a change of clothes unless you’re some kind of fitness monster. The practice itself is invigorating and relaxing. Lots of stretching, focusing on the lower back and shoulders (where programmers hold a lot of stress), and core exercises for balance and…organ health, I guess? I’m not totally sure why they have us do this.

Ok, that’s a lie, I think I’m pretty sure. Yoga teaches mindfulness through focus on the breath, grounding practitioners in a present moment that resurrects itself with each new inhale. You’ll want a good handle on mindfulness practice because it helps you recognize your thoughts and emotions while you’re having them. That’s an invaluable skill when you’re working at a fast pace and starting to get stuck. Mindful programmers debug faster because they can catch their poor assumptions as they speak their expectations to themselves. They code cleaner because they have the stillness of spirit necessary to sit back and write good pseudocode before leaping into class creation. And they work better with others because they don’t let their emotions dominate them during times of conflict.

Also, we’re more than just brains in jars. Most of the students here like to work really hard. That’s expected and encouraged. What gets lost in translation is the distinction between hard work and self harm. There is no nobility in skipping meals or depriving yourself of sleep or exercise in order to spend more time coding. You’ll end up burning out somewhere down the line, and it will cost you double the time you thought you’d been saving. Take care of yourself. Remember that your brain is attached to a body. And if you forget, there will be yoga to remind you of how painstakingly connected your brain and your body really are.

Expect pizza on Tuesdays. And expect the deep self-analysis that comes right before it. Engineering Empathy will ground you in reality and encourage you to speak your truth. These are closed-door group sessions where emotions can get raw and people can get uncomfortable. It’s OK. You can handle it. Just come prepared to be honest with yourself and your cohort-mates about how things make you feel. It may seem corny or unnecessary, but consider the companies where you’ll eventually apply. They interview a lot of people who know how to code, probably a lot of people who can code better than you’ll be able to after 9-15 weeks. When they consider you for employment, they’ll be margining how you’ll add to the culture. Are you a positive and welcoming person? Do other people do better work when you’re on the team? Can you look deep enough inward to detect and address your emotions as they shift, or are you constantly flying off the handle and needing to apologize for getting scared or frustrated or pissed off? Can you address a client with empathy and help them feel like their experience and knowledge is valid and valuable?

There’s not enough time to explicitly ready you for all these situations, but you’ll have a fair shot at learning some of the basics of emotional self-regulation and empathy, fundamentals that will allow an apprentice to contribute to a company’s culture long before they’re able to contribute to that company’s code. That’s value that pays dividends, and you’ll want to be able to provide it, so embrace the discomfort (at DBC, ALWAYS embrace the discomfort) and give each 90 minutes your best shot. 

A counselor, who helps facilitate the EE groups, is also available for half-hour private sessions funded by DBC. It’s up to you to sign yourself up if you feel you’d benefit from the space to get away and be totally honest with someone who will never look at your code. Personally, I think everyone should give it a chance at least once. I check in with the counselor once a week just to make sure I’m processing everything in a healthy way. There is so much to learn, so many personalities to get used to, so many expectations that get tested and torn down and rebuilt every day. You don’t need to go it alone. Use the first phase to reach out and seize every resource available to you. Especially the ones that take a minute to ask you how you feel and if they can help.

Expect to work with others. If you already know Rails and Angular and Node and Swift, and you only have experience working on projects alone, I’d still recommend that you try Dev Bootcamp. The relationships alone are worth the price of admission. Anyone can conceivably sit at a computer and teach themselves how to code, but DBC ups the ante by making you code next to a peer for more than two thirds of the time you spend on campus. This has benefits and drawbacks, and why the heck would you want to learn what they are in an environment where struggling with interpersonal issues could cost you a job? It’s safe here, so get used to it here. 

Get used to being the slow pair. Get used to asking tons of questions and admitting when you don’t understand the answers. Get used to feeling sad that you didn’t know more today and letting it drive you toward pushing harder tomorrow. Get used to watching someone better than you do something well, and get used to practicing their tricks and shortcuts on your own time while the lessons are still fresh. Get used to expecting their normal to become your normal someday. Get used to raising your expectations each time you code with someone strong. Get used to navigating, explaining your understanding of the code out loud and pulling up docs on your laptop to support the driver with researched answers to questions that come up. Get used to driving, plodding along as fast as your slow fingers will let you while your more experienced friend helps you make the most efficient decisions possible. In short, get used to something like being an apprentice in the real world.

And get used to being the fast pair. Get used to having your knowledge checked by a barrage of questions, finding new and painful humility each time your answers don’t quite match up. Get used to feeling sad that you went slower than your optimal pace today and letting it drive you toward pushing harder tomorrow. Get used to putting your methods where your mouth is and showing another person all your secrets, doing your best to lead by example without screwing up too badly. Get used to practicing your shortcuts and tricks on your own time before your workflow is under scrutiny and you share responsibility for someone else’s progress. Get used to being upset when your pair didn’t learn as much as you hoped they would, and asking yourself how you could have been a better leader. Get used to the art of teaching by asking questions, tracing back your own learning to guide someone else along until they arrive at the same understanding. Get used to driving, showing your pair how you do things and taking frequent breaks to make sure they understand why you did them that way. Get used to navigating, patiently (so patiently!) easing your teammate through the process you understood in minutes, even if it takes hours. Get used to getting the most out of your friend in a way that makes them feel like they matter, like they can contribute, like they made the right choice to be here. In short, get used to something like being a team leader in the real world.

Expect to work weekends. The atmosphere is different in here on Saturdays and Sundays, and you won’t want to miss it. Everyone’s laid back, but everyone’s focused. There’s a lot of joking and YouTube video sharing, and there’s also a lot of shop talk and review of the week’s material. It’s likely that you’ll enter your first few weekends with some unfinished core challenges from the week before. The weekend is your time to catch up or get ahead. You’ll have some weekend challenges to dig into, and your instructors will highlight the stuff from the past week that they think deserves the most attention. Redo lots of challenges. Build lots of toys and break them and rebuild them. Pair up with someone (or if you’re really feeling feisty, try grouping up) and work through a project from start to finish. Don’t skip the whiteboarding step, because the weekend is the best time to check your fundamentals.

During Week 2, my cohort had to build an app that generated winners and losers at random. Did we put our names into it and see who was the best one Saturday afternoon? You bet we did. Did we put real money down on the game and get really jealous of the winner? No comment. Rest assured that the weekends are awesome and you’ll want to be here to soak in that awesomeness. You’re trying to immerse yourself in code, why would you take a day off? if you want to relax at Dev Bootcamp, I think you’re better off timeboxing your day and finding a couple hours to work out or read or (ahem) blog multiple times throughout the week, rather than working like a fiend for five days and only having time to sleep and do laundry after the gong rings on Friday afternoon. 

Expect to ask for help. The pace is fast. The language is foreign. But you’re smart, right? Always the quickest kid in class, the best speaker in the meetings, the comfortable master of whatever past domain you lorded over, perched atop whatever throne you used to claim. Yeah, um, get ready to get blood all over your crown. Everyone here was the smart kid. Everyone. Chances are, you’re in for a rude awakening if you expect to coast on your own awesomeness. You’re going to struggle to keep up here, and you’ll struggle a lot less if you admit that you’re struggling. So just admit it and get some help.

There will be instructors, junior instructors, TAs, boots from the advanced phases, and brilliant peers all around you at all times. All that’s asked of you is that you raise your hand and expose your ignorance. People think the secret to success at DBC is an insane work ethic and ungodly hours, but that’s mostly true for those who would rather bang their head against a problem from 2 hours than ask an ignorance-exposing question and get help in 5 minutes. Your time is valuable and your money is valuable, and you’re trying to spend a lot of the latter to save a lot of the former, so why waste minutes being stuck when there are so many unstickers handy? 

I can’t stress enough how much my work improved after I started asking for help. My first week, I burned out in three days by trying to prove to myself that I was smart enough for this, as if I had signed up to know things rather than to learn them. My second week, I asked so many questions and signed up for so many mentoring sessions that I pissed off my pairs and got a warning message from an instructor telling me not to be a help hog. Week 3, I found my happy medium and I’ve never felt so relaxed about getting so much done in my life. The discomfort’s still there (are you seeing a pattern yet?), but now it’s more like a petulant but good-hearted roommate, and I get to enjoy this process way more than I did when I was killing myself trying to solve things better than my instructors. I’m not that guy. You’re not that person. Save time and a headache and be the one who asks for assistance when they need it.

About those mentor slots: there’s this great thing called Pairing is Caring, where coders in the community, many of them DBC grads, stop by for a few hours and help people understand things better. You’ll be able to schedule an appointment with someone dedicated to working on what you need to work on, and that 60-90 minutes will help you accelerate your learning in the best way possible. Imagine pairing with someone way faster than you who isn’t impatient and wants you to drive the whole time. It’s such an awesome way to gain understanding. You might even come away feeling really strong about something you thought you sucked at, like I did when I sat down to work at a challenge with a mentor and realized that all my initial instincts were the right ones for the project.

If you miss out on PIC mentors, take advantage of the weekend pairing board, where students from Phases 2 and 3 write their names and available weekend time slots. Take an hour on a Saturday (because you’re already here, right? Right???) and link up with someone who recently finished that nasty challenge you’re stuck on. Not only do they know one possible solution right off the bat, they probably remember their thought process and can help you along the same road. There are so many ways mentoring goes right and so precious few ways it can go wrong. Take the plunge. Get a mentor. You won’t regret it.

Expect to make friends. I came to Dev Bootcamp thinking about the things I’d need to learn and worrying about whether I’d have time to learn them all. I’ll leave Dev Bootcamp thinking about the people I’ve met and worrying about whether we’ll keep in touch. At tonight’s graduation party for the exiting Coyotes, a few of us started talking about how hard it normally was to meet new people, especially new people who weren’t like the people we already knew. And yet here we are, with our vastly different ages and backgrounds and experiences, and we’re all becoming really good friends. This place is not normal.

I’m not saying I’ve forged a deep bond with every single person in my cohort, but we’re all connected nonetheless, and there are already at least 10 people I’d make plans to hang out with even if we had to connect over something other than code. They say the acceptance process is so selective because DBC is looking for certain types of people they think will flourish in this strange environment. I believe that theory 100%. To a person, all my fellow Bobolinks have a strong drive to learn and succeed, coupled with this deep-seated optimism and openness to try new things. The whole space is like a resonating chamber for positive human energy, and it’s helped us form the kind of bonds that don’t happen by accident. Simply working together for three weeks doesn’t explain our level of camaraderie. This is something deeper, and it’s really special, and I’m grateful to be a part of it. Learning code alone gives you a sense of accomplishment. Learning code at Dev Bootcamp gives you that plus a sense of belonging. Get ready to sink into it, and stay wide awake so you can enjoy every second. Get everybody’s phone number in the first three days and create a DBC group full of the best buddies you don’t know you have yet.

tweet TWEET! #JustBobolinksThings

Expect to succeed. Always, always, always expect this. You wouldn’t have signed on for this journey if you didn’t believe in your potential or the program’s, so trust your initial thinking and see it through. Work every single day. Get done with every challenge you can and try to venture into the stretch challenges too. Stay late enough to finish what you started each day, and get home early enough to give yourself a real shot at a fresh start in the morning. And trust the process. You are good enough for this, and you’re ready enough for this, and all that’s left is for you to get started and see how much fun you can have while being awesome.

Repeating is not failure. Not knowing something is not failure. Screwing up on a challenge or assessment is not failure. Being the slow one in the pair is not failure. Failure is quitting, and it’s nothing else. And if you were planning on quitting, we wouldn’t be having this hypothetical one-way conversation right now.

So if you’re scouring the web trying to get more ready for this thing, I’m here to tell you that completing Phase 0 means you ready right now. Anticipating more outcomes feels safe, but safety isn’t where your growth zone is. You won’t get hurt by trusting the process and jumping right in. Just keep it simple. Pat yourself on the back for getting your submissions done, show up on time on Day One, and come expecting the ride of your life.

OO – It’s Magic, You Know…

Aaaaaand there it is.

They say it eventually happens to everyone who does this. You’re sitting through another lecture about mixins or watching someone assign instance variables during a coding demonstration, and suddenly something snaps and it’s all objects.

Everything is a object.

This post is an object that contains a string. The phone I’m writing it on is an object that receives messages from Twitter. The pillow under my head is an instance of the Pillow class, which in turn inherits some characteristics of the ThingsKidsFightWith class. (Did it have to inherit those things? I’ve been told inheritance should be avoided unless it’s absolutely required by necessity or design.)

My typing thumb is an object that receives messages from my brain object telling it to watch out in that lower left corner of the iPhone keyboard object, or else the microphone button object will send a message to the phone speaker object and I’ll end up with this annoying beep object that I can’t keep from initializing even if my phone is on vibrate, unless I remember to tell my volume button object to send a message to the ringer object and disable its function.

What did the lawyer say when the witness refused to swear on the Agile Manifesto?

“I object!”

There’s a mock assessment object in the “tomorrow’s events” hash. I have to receive a bunch more messages from this ebook object before I pass out tonight.

This post is short because I’m studying, and because I’m exhausted, and because this post never needed to be long from the start. It’s enough for me to write the Minimum Viable Post and add features to it later, based on my next conversation with my readers. Tell me how you’d like this post to evolve and I’ll see if I can address your concerns in its next release.

That’s actually not a joke. The comments are down there for a reason. Consider this as an experiment


oh, dammit. Make it stop.


Today was all about communication. When my group was good at it, I was having a blast. When we weren’t, I was only able to keep from crying by concentrating on not throwing up. Total emotional roller coaster today.

This will be a shorter post because I am exhausted. Week 1 kicked my butt with boots on, and I’m glad it’s technically over. I say technically because I still plan to spend eight hours onsite tomorrow.

But that’s tomorrow. This is today. And today I learned that if I can’t write a program in plain English, I damn sure can’t code it. I was at a mental standstill until I took a step back and plotted my course. Once I did that, I started working out the solutions to my problems at a good clip, no problems, no stress.

They call it pseudocode. It’s a hybrid between saying what you want a program to do and actually coding it. Line by line, you work through the steps of your program until all you have to do is convert your instructions into syntax. It’s a great habit to get into because it makes it possible to implement a solution in a variety of different languages. I think. Right now I’m only just getting comfortable with the one.

But Ruby is a lot like plain English, so the transition from pseudo to code is quicker. As an example, let’s say I wanted to write code that displays a basic greeting. The idea is to say hi to a person by name. Here’s one way I might pseudocode it:

Define a method called greet_by_name that takes a string as an argument.
Create a variable called name that stores the value of the string.
If the value of the name variable is the same as “Duke Greene,”
Display a greeting that says hello to the value of the name variable and asks how the blogging is going.
Otherwise, display the same greeting and ask how the blog lurking is going.
Close the method.

Call the greet_by_name method on “Duke Greene”.
Call the greet_by_name method on “Jamie McBloglurker”.

At this point, my work is cut out for me. Line by line, I can read through my instructions and translate them directly. If I get stuck, I probably just have to take another look at my pseudo and rewrite it. So my greeting example might code out like this:

def greet_by_name(string)
name = string
if name == "Duke Greene"
puts "Hello, #{name}. How's the blogging going?"
puts "Hello, #{name}. How's the lurking going? You know you can comment, right?"

greet_by_name("Duke Greene")
greet_by_name ("Jamie McBloglurker")

That’s going to return

Hello, Duke Greene. How's the blogging going?
Hello, Jamie McBloglurker. How's the lurking going? You know you can comment, right?

just like I expected it to.

The hardest part about solving today’s challenge wasn’t getting along with the computer. It was getting along with each other. Everyone had their own solution idea and it was a real struggle to agree on one implementation. To make matters worse, we didn’t write any pseudocode until after 5pm. Oops. We could have saved so much time if we hadn’t just plunged in without a map.

Lesson learned. It’s late and I’m tired. Phase 0 boots, they’re not playing when they tell you to pseudocode. Practice the skill now because you’ll definitely need it later.

Day One at Dev Bootcamp

Author’s note: This post is way more epic if you start playing the embedded video before you start reading it. Trust me.

7:14 am They told us to get there ten minutes early and I am right on time. I’m seated facing the rear of the train, barreling towards a future I can’t see. The sun is battling the morning clouds for sky space. I think it’s winning. I hope it wins. I’m struck by the realization that everyone on this train has a reason to be here and a place they’re going. For all I know, each silent stranger is also going somewhere today that will change their lives. I send out as many good vibes as I can muster. I’m not sure if they’ll stick. I hope they stick. I am listening to This Will Destroy You at full volume. It’s not a soundtrack. It is a promise. The music shimmers, swells, soars, stills, shakes, sunders. I am ready to be destroyed. I am ready to rebuild myself. Everything I have done leading up to today is gone. My memories are just the stories I tell myself about how I got  here. I feel underprepared this morning, because I have told myself a story of opportunities missed. I did not remember to write down the small and huge victories that kept me up late at night, smiling at the progress I was making. Wherever I actually am, I am much closer to where I’m going than I was nine weeks ago. This feels like the first day of school. This feels like the first day of summer camp. My lunch is packed. I have forgotten my mittens. I wonder whether the teachers will be nice. I wonder whether I will make new friends. The train veers and comes close enough to the one next to it that for a moment I can see another room full of lives, moving as fast as mine, and my awareness expands and I realize the world will be alright no matter what I accomplish today. I will be alright too. And now we are underground. I am walled in but moving fast. My path is laid out and it will take me exactly where I’m meant to go. I put away my headphones and focus on my breath. This is not meditation. This is a warmup. This is my stop. This is it. 9:19 am I’m in the bathroom and there are ten more minutes of waiting before everything starts to happen. We all entered the DBC space at 8am, greeted by a volley of high fives and Gangnam Style blasting on the PA. After a few icebreakers, we spent an hour introducing ourselves one by one: name, cohort mascot, quirk. New boots (what up, Bobolinks!) and TA’s shared the reason they were here. The Salamanders and Coyotes, respectively starting Phases 2 and 3, shared tweet-sized advice for the newbies: Work your hardest. Remember why you’re here. Always be asking questions. Get sleep. Eat food. Enjoy the experience. And never ever push a commit to the master repository. That last one was phrased “Don’t push the master or you’ll get slapped” and for a moment my eyes were darting around the room, looking for the coder whose mastery had sparked a violent streak. Then I realized the guy was just talking about GitHub. Between the intros and this stillness was a catered Day One breakfast and a bit of time to mingle. I took the opportunity to ask everyone I could about what Week 1 would be like. “They pile so much on you, and then you work late to try and understand it all, and then you wake up and they pile so much more on you,” went one reply. So now I’m in the bathroom writing notes, barely following the letter of the “no phones” rule, which unfortunately seems to extend to Wi-Fi device permissions. Oh well. I’m sure I’ll be too busy coding to care about Twitter. 2:11 pm So many introductions, so many walkthroughs, so much controlled chaos. I’m starting to realize I’ll need to hold back at least a few concrete details of my experience in this blog, so as not to spoil surprises or give away answers. Still, there are moments that stand out, even without detailed explanation. A classic get-to-know-you name game got tweaked into a group refactoring challenge. There was a brief discussion about how to stay outside our comfort zones without slipping into panic as the weeks progressed. Boots gave impromptu talks on pairing, open source code, proper gong technique, speed skating. We learned about personal truth and why The Boy really Cried Wolf. An experienced coordinator cheerfully informed us that she would be here for us, whatever we needed. An experienced boot gleefully informed me that I was going to just LOVE this weekend’s group coding challenge. I’m looking forward to my inevitable Sudoku nightmare tonight. We are out of the gates now, and we’re coding. In Phase 0 we paired with one another in hour long sessions, tackling one challenge before parting ways. Now we are split into four-person groups and told we’ll be pairing with one of our groupmates for the entire day. There are six core coding challenges to complete, along with two “stretch” challenges for those who finish early or stay late. My partner is new to the Mac environment and rusty on version control. Not a problem. He gets to practice the basics, and I get to practice explaining them clearly and concisely. We’re both doing our best and scratching our heads and fist bumping when we figure things out, and it doesn’t even matter that we might be a little behind the average pace, except it kind of does, because I’ll need to get home by 11 if I want to sleep for more than 6 hours. I shrug off the stress and resolve to focus only on the present challenge and give it all I can. Things will work out. Help will come if I ask for it. 5:02 pm Pair programming is like playing a multiplayer video game that rewards you constantly for hours and then hits you with a difficulty spike so gnarly that you wonder whether the rewards were some kind of elaborate and sadistic setup. We were trucking along, plowing through engaging but basic material, and then suddenly 90 minutes had gone by and there was a cluster of TA’s looking over our shoulders and I can’t remember whether they dropped more F bombs or we did but there were a lot of F bombs being dropped. Turns out we had veered off course early on by changing two things when we only needed to change one, and the test file had assumed we would never change the second thing, and so we sat stuck until we thought to start from scratch and do the one thing, after which there was much “oh my GOD”ing and “you gotta be SHITTING me”ing and wailing and gnashing of keyboards. I couldn’t stop grinning through the whole thing though. I love a good challenge, and that was one hell of a good challenge. Afterwards, I’d learn that most of the pairs had gotten stuck on that finicky piece of code, and I felt good for not beating myself up when I had the chance. At this point, my partner was exhausted from the mental effort and ready to turn in for the day. But first, we had to attend our introductory Engineering Empathy session. The topic was feedback. Great companies thrive on it, failing companies stumble over it. A.S.K., actionable specific kind. The instructor stresses that the kindest feedback can be the hardest to hear. Kindness is not niceness. Kindness is loving and fearless. Kindness is respecting your fellow boot enough to tell them that it’s gut check time, that they will wash out at their current pace. It’s telling your partner that their pairing style is crippling your effectiveness. It’s admitting that you might not have the whole story, while standing firm on the validity of your piece of the story. Parallels are drawn between the Compass of Shame and the ways we can choose to deal with feedback. The instructor is given a tissue box. It’s full of feedback that’s difficult to process. He hits himself over the head with it, attacking himself. He throws it at the giver, attacking others. He refuses to take the box, avoiding any confrontation. He drops the box and walks away, withdrawing from the stress. Then he takes one tissue out of the box. It’s the part of the feedback that he can actually use. He does not actually use it. So far, we are all hale and hearty here at Dev Bootcamp. 9:13 pm My partner was tapped out at 5:00. That left me alone and eager to see how much of the code I could understand all by myself. I mostly flew through a basic refactoring exercise with one baffling capitalization requirement. Ditto for the first half of a method chaining exercise. I took a brief break to FaceTime with my daughter. We blew raspberries at each other for five minutes and then I told her a made-up story about Pikachu. My wife had gotten her hair done and she looked fantastic. For the first time since I’d left, I felt a little homesick. We hung up and I ascended the elevator to the seventh floor, ready to get back into my rhythm. Then came my second difficulty spike: an inscrutable chain of methods, a single-line gauntlet that needed a cleaner look. Prime numbers were involved. Squares too. It was a mess. Again, I shortly found myself joined by a bemused trio of instructors, and I felt no performance pressure because this was now our code and we were going to solve it together, damn it. We teased out an artful solution and patted each other on the back, having gained a deeper understanding of array iteration and deletion methods. It was getting late now, and I felt a pang of pressure at the realization that the day’s final core challenge was still untouched. Luckily, it was a challenge I’d already completed by overachieving during Phase 0 prep, and once I worked up the courage to ask a Phase 3 boot to pair up, we knocked out a solution that was elegant and D.R.Y. (Don’t Repeat Yourself; if your code uses the same line or a version of it multiple times, you can write it better). I’m heading home earlier than I expected to, and I’m almost shaking with joy. I made it through my first day without slipping behind. Walking down Grand, I whipped out my phone and scheduled a mentoring session for tomorrow, because one of those stretch challenges I missed looks too juicy to pass up. I’m doing this. I can do this. 11:38 pm In bed, fading, I click Publish on my blog post and put my laptop away. This will almost certainly be my last long blog post for at least a week. Maybe until this is finished. But maybe not. Where I’m from, it’s already tomorrow. I’ll try not to get too far ahead of myself.

Ten Things to Expect from Dev Bootcamp’s Phase 0

You’re excited and anxious and completely in the dark. Phase 0 is coming up, and you think you might be prepared enough, but there’s not much time left and you wish you had a better lay of the land. You’re curious about the entire Dev Bootcamp experience and wondering why you haven’t heard more about the nine weeks that lead up to the on-campus Phase 1. You’re trying to make your transition into web development the best it can be, and you’re hungry for all the information you can get.

If one of those people is you, this post is for you.

For the last eight and a half weeks, I’ve been frantically learning how to code. Soon, I’ll head to Chicago’s Dev Bootcamp campus, where the pace and the pressure will reach a fever pitch. Graduating boots tell tales of 100-hour workweeks, ridiculously high expectations, deep self-discovery, profound emotional growth. For nine weeks, my life will be eat-sleep-code-improve, and they say I’ll be dreaming about code during the sleep part.

Sounds like fun!

During this final week of Phase 0, as I review what I’ve learned so far and get ready for what’s next, I’ve realized how far Dev Bootcamp has helped me push myself beyond my comfort zone. I want to give a little something back by paying forward a piece of the guidance I’ve received and demystifying some of the Phase 0 process.

Without further ado, here’s what I think you can expect from your Phase 0. Keep in mind that DBC changes their curriculum based on triweekly student feedback, so the older this post is, the less accurate it may become. To avoid that, I’ll try to stick to the broadest concepts. Let’s get started.

1) Expect a time commitment.

It wasn’t until the middle of my fifth week that I realized a lot of boots don’t work during Phase 0. I’ve been juggling work, family, and coding this whole time. It’s not easy. Each week means a new set of assignments to complete by Sunday at midnight. And it’s not like you can just burn midnight oil to power through them, since you’ll have to pair up with a peer at least twice a week and work together. That means frequent email exchanges, rain checks, and frantic “please someone pair with me I need HELP!” posts on your cohort’s private Google+ community page. Oh, and you’ll be coordinating your pairing sessions across at least three time zones, since not everyone headed to your DBC city lives in your state. You’ll need to master your own schedule in order to manage the workload.

Not working is probably the easiest way to free up the time you need. For me, that wasn’t an option. On a typical day, I worked from 9-5 and tried to cram in an assignment during lunch. Then I enjoyed dinner with my family and hung out with my daughter until her bedtime, after which I did Phase 0 stuff until I couldn’t keep my eyes open. It wasn’t unusual for me to spend 15-20 hours on a week’s work. That’s more than I was told to expect at the beginning, but everyone’s experience is different and people catch on to some things easier than others. By the time I was on my third week of Ruby, I was blazing through the challenges and managed to finish up in about 10 hours. During the HTML/CSS introduction, my decidedly non-visual brain stalled frequently and I needed upwards of 25 hours to get my head around things. Every week will bring a new set of obstacles and you won’t know how you’ll handle them until you dive in, so don’t fall behind and never let a Monday pass without at least glancing at the week’s syllabus. You can submit an extension form if you need a little more time to get something done, but it’s really hard to be an effective helper in a peer pairing session if you’re not up to speed on the concepts, so maintaining momentum is key.

2) Expect to set stuff up.

I think one of the main purposes of Phase 0 is to avoid or minimize the stress of 20 new boots on campus wondering why they can’t get their command lines to cooperate. Most of my Phase 0 weeks introduced a new language, site, or tool. Before I could get started solving problems, I had to make sure my machine was ready for the work. One week, I had to learn how version control works and get started working with GitHub from the Terminal. Another week, half my cohort stalled for a day when there seemed to be no crystal-clear instructions for updating SQLite3 anywhere on the web. I’m glad I slogged through some pre-Phase 0 command line and Sublime tutorials; they helped me get confident with learning more about my laptop before that learning became a weekly requirement.

I’d say setup, installation, updating, and tiptoeing around unfamiliar software accounted for a full 25% of the time I spent on Phase 0. Every week, the assignments were like two kinds of challenge rolled into one. The end goal was always to finish the tasks and submit the work for review, but it was impossible to start the tasks without the right environment set up. I compare it to a chef who must cook a dish in a kitchen with dirty pots and a disorganized pantry. The cooking is the easy part, once the kitchen is clean.

Side note: About 85% of my fellow chefs are using Mac kitchens, with Linux coming in second. Windows machines can get the job done, but they’re not recommended. One person in my cohort worked through half the phase on a PC before retreating to Craigslist for a used MacBook. I can’t speak on how hard it is to go the PC route, but I hear it’s pretty hard.

3) Expect to write things down.

Here’s one of the biggest questions I had going into Dev Bootcamp: Given a culture that seems so insistent on regular blogging, why is it so freaking hard to find information about Dev Bootcamp on boot blogs? During my research, I looked at dozens of blogs that had started out strong and fizzled after a couple weeks’ worth of posts, never to be updated again. Now I think I know why boots aren’t blogging. It’s because we are.

Ok, let me explain that.

Each week, boots must research and write two blog posts, one technical and one cultural. In a given week, I found myself studying problems in the tech industry or conflict resolution styles, intricacies of Ruby syntax or CSS layout tips, and then crafting blog posts to share with my cohort. My WordPress presence has diminished during Phase 0 because I’ve got two other weekly blogging assignments to complete and submit to my GitHub repository, and that doesn’t leave much time or energy free for personal blogging. I imagine the same is true for others.

The writing doesn’t stop with blogs. We write questions on the community page when we get hung up on a tough step of an exercise. We write detailed reflections on our work after each exercise we complete. We write feedback for one another after pairing to solve coding problems or do research. This approach is great for me, since I’m a verbal thinker and I write by transcribing the little running narration in my head. You might wish you could spend the time coding. But the writing helps process and solidify new concepts before moving on to the next thing, and it’s probably excellent practice for a team workplace, where good communication habits are at least as important as solid coding chops.

4) Expect to connect with people.

Your peers will be your most valuable resource during Phase 0. DBC staff took a hands-off approach to most of my questions during the phase, gently reminding me that I could find the answers I needed if I asked a friend for help. It was frustrating at first, but I came to appreciate the nudge after finding a few answers by drawing from someone else’s expertise. Some of the people in my cohort have extensive SQL experience, some are phenomenal at CSS, and some are total neophytes with a knack for Googling the perfect solution. Between all of us, there’s more than enough knowledge and persistence to handle the phase’s toughest coding challenges with ease.

I had to learn to get over myself, to stop needing to have every solution to every problem right away and all on my own. A few times, I hammered away at a piece of code, checking the Google+ community page in desperation after hours of fruitless agony, only to see that my exact question had been answered before I’d gotten started. My easiest weeks were the ones when I had the most time to pair up.

Pairing involves meeting up with someone in a video chat to collaborate on code and learn new concepts through experimentation. I’ve learned so much faster during my pairing sessions that I shudder to think how long I might have spent getting some of these new concepts into my brain. Apparently pairing is catching on as a popular way to code in the real world, and I’m grateful for the opportunity to practice early, even before I can be sitting next to my pair in person.

There are weekly solo challenges too, to keep everyone honest and make sure each boot has a decent grasp of concepts all on their own. But the solo challenges are really the exceptions that prove the rule. You’re not supposed to go through Phase 0 alone. Don’t lone wolf it. It’s way easier, more fun, and more effective if you follow DBC’s recommendation to pair up regularly.

5) Expect to learn a test-driven workflow.

If you’ve ever taken music lessons, you already know something about what to expect from Phase 0. Think of that stickler piano teacher telling you to arch your fingers and play slower at first to get into the right muscle habit. Think of your RA telling you to eliminate the buzz from each guitar chord you finger before moving on to the next one, even if it means you’ll take 20 minutes to get through Moonshadow. Think of your choir director insisting you warm up at the beginning of each rehearsal. There’s a process behind the craft, and good craftsmen respect the process. Dev Bootcamp starts teaching good processes from the start.

I got a firsthand lesson after one of my guided pairing sessions (four appointments where an instructor sits in and offers tips, guidance, and instant feedback). I had spent the entire pairing hour trying to drive the code to the next step, insisting that we get through as much as possible in our limited time, writing big chunks of code that failed miserably and having to go back and fix what felt like a million things. I was rushed and anxious and completely ineffective. My instructor left me this feedback: “There’s a saying that you only get to write one line of code between tests for each year you’ve been coding. So slow down and make sure each thing you write works before going on to the next thing.”

TDD, or test-driven development, is a process where you start by writing a test that fails and then write the code that passes that test. So if you wanted to write a program that printed “Hello world!” you might first write a statement asserting that the output of the program was equal to “Hello world!” The first time you ran the program, that statement would be false, since you had only written the test and there was no program to compare to the desired output. So then you’d have to write the program, and the key here is that you’d only have to write just enough to make it pass that one test. Then you move on to the next feature, write the test for it, check that it fails, and move on to the actual coding. What looks like a 30-minute challenge at the outset can end up taking an hour or more if you’re testing as often as you should be.

Writing a good test accomplishes a few things. First, it ensures that you know enough about the code you want to write that you can express the result in terms of a test that could be failed. It’s like the scientific method applied to programming. Sometimes the hardest part of comprehending the concept is writing a testable hypothesis. Second, good TDD turns the whole coding process into a sort of game, where each test is like a level to complete. It breaks the work up into manageable chunks and allows you to take breaks without losing your place. Finally, testing gives you twice the practice on each concept you dive into, since you are manipulating variables and checking syntax in two places for each test you write, once in the test and once in the code.

Looking back, I don’t think I’ve gained any deep knowledge on any one language so far. But I do have the beginnings of a good habit in my work technique. If all DBC was trying to accomplish for Phase 0 was to set some best practices and let us get to practicing them early, the phase still wouldn’t be a waste. But as a piece of a larger, group learning model, the TDD requirement is like the consistency icing on the learning cake.

6) Expect to make things.

Those blog posts I had to write on my technical and cultural topics? They exist online because I had to write the HTML and CSS that brought them to life. I made a (very) basic JavaScript game during my third week. Most of the Ruby we write creates apps that serve some useful purpose, be it mathematical or practical. There is required and recommended reading accompanying every week of study, but the reading is secondary to the experimentation and exploration we do. I’ve had a lot of fun with the pure coding challenges, which combine the guidance of a clear workflow process (study, write the program in plain English, test-code-repeat, refactor to improve performance) with the adventure of a blank canvas.

I like to tinker with stuff, and Phase 0 has felt like a lot of tinkering, playing around with things in my text editor and then running them in the command line to see if/how/why they totally/don’t/sometimes-but-not-really work. It’s a lot like how it feels to navigate in a new town. You start by figuring out one route to each place you need to visit, and then you start connecting the routes, and then you start looking for detours, and over time you begin to feel like a local.

Dev Bootcamp gave me tons of destinations and no maps. I had to Google proper syntax, collaborate with other boots, read documentation, and mostly muddle around before I found myself where I wanted to go. And then it was time to get to the next destination somehow. Learning this way has a compound effect, and the DBC curriculum ramps up logically, so you can use mastered concepts to solve small parts of new problems. Meanwhile, you’re always learning new “roads” and plugging them into your existing map of knowledge. Now that I’m in review, I’m facing the interesting task of rewriting in JavaScript some Ruby code I’ve already built. The idea of that would have scared me silly in April, but now I shrug and hop into the work, knowing that I’ll surely find some way through whatever snags I encounter. You can plan to fall in love with the learning process in a way you haven’t done since elementary school. Getting your hands dirty is the aphrodisiac.

7)  Expect to get stuck.

 It’s going to happen. You’ll be breezing through an exercise and suddenly you’ll run up against something you don’t understand at all. Whether it’s an error message you’ve never seen before, a chunk of HTML that just won’t display right, or a stubbornly goofy line of code, there will be something that trips you up and refuses to get out of your way. Few hours are more frustrating than the ones you’ll spend blankly typing in something over and over, utterly clueless as to why your insane repetition keeps producing the same bad result.

I hear real programming is no stranger to these bleak hours, and DBC is trying to get boots ready to face them bravely. So don’t be surprised when one exercise in a week’s batch has a staggering difficulty spike, an innocuous step that turns out to break all your work until you learn more about the mechanism behind it’s implementation. Apparently that’s normal. And why shouldn’t it be? Overcoming unforeseen obstacles is kind of what life’s all about. Example: I wrote this whole blog post last week, 2000+ words, and lost it to a phone glitch. It was infuriating. Oh well. This draft’s better.

Back to the point. These crazy geniuses want you getting stuck and feeling overwhelmed a lot during Phase 0, because guess what you’ll be doing once Phase 1 starts? This brand of education sees stuck-ness not as a display of weakness, but as a necessary precursor to rapid growth. No lesson sticks quite as hard as the one that comes with a few bruises from banging your head against the wall. And you’ll be doing some of that damage to yourself too. If you like this coding stuff, you’ll be curious about it. Your questions will eventually venture beyond the presented material and you’ll go and try to get them answered. Inevitably, you will end up going far enough down the rabbit hole to find yourself hopelessly out of your depth. I swear this will be a good thing no matter how you handle it. Either you’ll go above and beyond and dig up the answers you seek (or, if you’ve been paying attention, you’ll find a pair and go digging together), or you’ll put a pin in the topic and have a great question to ask a mentor later.

The important thing is not to wallow in self-pity when you get stuck, because that’s a quick way to turn a perfectly normal hiccup into an existential crisis. Who has the time for those? Better to acknowledge that you’re not perfect, step away from the problem for a while (DBC often recommends sleeping on the trickiest puzzles) and find something else you can do to stay productive in the present. You’ll always have enough extra to turn your attention to, and this phase is more about introduction and exploration than execution and perfection, so there’s no need to panic.

Right now some of you are still hoping you’ll be special and avoid getting stuck because, all your life, you’ve been really smart. Keep hoping, special. Everyone who gets into DBC is really smart. That’s not what this is about. Now is a perfect time to start reframing temporary failure as a necessary step to long-lasting success. Take it from a former perfect person: you won’t feel perfect for long here, and you’ll actually feel freed and healthier once you set aside that exacting self-image and let yourself grow beyond your can’t-miss comfort zone.

I’d say /rant, but I didn’t open the tag, so I’d be wasting keystrokes.

8) Expect empathy

I’ve never felt less safe than I have this spring and summer. Everything is brand new and I’m never great at it right off the bat. I’m stepping out of the office, stepping away from my family, stepping into the unknown. There’s no guarantee of a good job when I’m done, and my stomach often churns at the thought of floundering after taking such a huge risk. I’ve never felt less safe than I do now, and I’ve never felt happier, because I’ve never felt more supported.

There are guides here who have struggled with perfectionism and can offer encouragement to people like me who freeze up when victory is less than certain. There are instructors who pierce through difficult pairing sessions with sharp insight and warm understanding. There are peers who are all in this together, each careful not to squash anyone else’s aspirations or monopolize pairing sessions. At Dev Bootcamp, everybody wants everybody to win, and it shows.

I really struggled midway through Phase 0. I fell far behind and kept telling myself that I’d never make it, that I would be a failure once again, that I was stupid for even trying. But each time I mustered the courage to reach out for help, I felt heard and respected and even loved. My shepherd, a DBC grad, shook m out of my funk by checking in regularly and reminding me that my work, when I finally completed it, was good enough. I paired with peers who graciously walked me through the previous week’s material so I could get caught up. And every time I took a break from coding to check @devbootcamp on Twitter, there was someone lifting up a boot, helping them get connected in the workplace, patting them on the back when they found success.

And then the strangest thing started to happen. I started getting my own empathy back.

Dev Bootcamp founder Shereef Bishay uses the example of a restaurant to highlight how DBC empowers and motivates people to lift one another up. In a restaurant, he says, there are people who sit at the table and people who work in the kitchen. I went into DBC with a table mindset. I wanted to sit down, pay my tuition, dine for nine weeks, and walk out with a full belly and a tech job. After being at this for a couple months, I’m sliding slowly toward a kitchen mindset, where I find joy in making something with others, something that can serve people and make their lives better. One of these mindsets creates the kind of enthusiastic cooks restaurants love to hire. The other produces the kind of demanding patrons servers love to complain about.

I got to help someone make their code less repetitive last week, and it felt fantastic, and I learned something new. The week before that, I got to show a pair how to improve their workflow in the Sublime text editor, and it solidified my knowledge of the feature, and I got better at using it. As I write this (hopefully) helpful blog post, I find myself more and more inspired to finish up and dive back into my work, where I’ll get better as a natural result of focused practice.

Caring about others is how you get better at whatever it is you’re doing, and DBC is fostering an environment where it’s really easy to care.

9) Expect to succeed.

I’ve heard that the occasional boot doesn’t make it past. Phase 0, that not even the available deferment program is enough to keep some people intact in the hectic lead-up to the real thing.  I’m not saying that’s not true. But I will say that if you love coding, you will get through Phase 0 without too many problems. This is a phase more about habit building than career readiness, and you’re not going to face anything too intensely complex here. What you will face are the kind of barriers you’ll be able to break through with ease…if you know how to ask for help.

This phase is all about ramping up and getting things in order. If you follow the instructions you’re given, and admit when you don’t understand something, you will never be too far from the next step you need to take.

Every week during Phase 0, I found myself learning something new. Weeks 1 and 2 brought HTML and CSS into my world. Week 3 flashed just enough JavaScript to pique my interest. Weeks 4 – 6 urged me deeper into Ruby, covering math, arrays, methods and classes. Week 7 threw some SQL at me to see what would stick (not a ton, but enough to make stupid jokes FROM top_of_my_head WHERE punchline = awful). And then it all wrapped up with comprehensive review. Through the whole process I was building a progressively better looking blog, pairing up, leaving feedback and submitting exercises. It took a lot of my time, but it wasn’t grueling. Like a brisk uphill walk, Phase 0 made me break a sweat but did more to wake me up than wear me out. I think anyone can do this work as long as they get a kick out of programming itself and invest enough time in the exercises.

10) Expect to change your expectations.

I have never learned this way before. There are no grades, no quizzes, no answer keys. I’m not done learning when I master enough of a concept to parrot the bullet points back. When I’m stuck on something, the teacher’s job is not to help but to point me toward tools I can use to help myself. It’s the opposite of a competitive college environment; there’s a spirit of proactive cooperation that runs through everything we do.

I was expecting a lot more guided direction, but at the beginning of each week you’re given your exercises and then left to your own devices to work through them. It’s a really cool teaching and learning style that lets me work at my own pace and on my own schedule.

Most importantly, I’m more confident now than I would have thought possible. And it’s not because I have all this mastery so early. I barely know anything yet, and the more I learn, the less I feel like I know. But that has nothing to do with my growing knowledge that I can figure out any new information put in front of me if I have some decent waypoints and space to attack the challenge my way. It’s a really empowering feeling, one I hoped I’d experience after hearing so many people gush about how Dev Bootcamp made them better learners. Though I’d heard the stories, I had remained skeptical until I started to see the changes myself.

My attitude is better now. I can contemplate more work before feeling overwhelmed. I’m less reluctant to work in a pair or a group. I’m more aware of my positive and negative character traits and I have become a more reliable communicator. These changes came about because I committed to working through Phase 0 as instructed. I can’t imagine what life was like before this prep period existed. Thanks to these nine weeks, I’ll be able to walk onto campus on Monday with a few concrete questions and a working knowledge of enough coding languages to start at a very fast pace. It’s been a long and difficult journey from April to now. But I’m still standing. And I haven’t seen anything yet.

Phase 1, here I come.

Pokémon (Learning) Ruby

I start Phase 0 in less than a week. I know so much more about programming now than I did a month ago. And the direct result of that knowledge is a deep and unsettling sense of not-knowing. The more I learn, the more questions I have. The more answers I find, the harder the questions get.

I’ve been taking study breaks to play Pokémon Ruby, because it’s been a while since I first owned the Elite Four, and because I like Mudkips, and because I’m learning Ruby in real life and I like symmetry. On occasion, a short break will turn into an hourlong Pokébinge and I’ll lose some valuable study time in the process.

Maybe by writing this down, I’ll improve that behavior.

See, it’s not the lost time that bugs me. What bugs me is the fact that I can be more willing to settle for virtual advancement than actual advancement, even when the requirements are almost identical.

The kid needs to catch monsters. I need to grasp lessons. Pokémon evolve with proper training. So does my understanding of methods and blocks and classes. My rival is a little tough but she drives me to maintain a competitive pace. Life is hard but it gets easier when I apply myself. And so forth.

Of course, games aren’t totally identical to life. If I could master real-life Ruby by walking in circles in tall grass and pressing A repeatedly, I would probably have several years of expertise under my belt by now.

And games entice with the promise of completion. Ruby Version has 386 pocket monsters, and I can measure my progress against that maximum. But I’ll never max out my programming knowledge. Ever. So I need to develop a motivation to learn that’s more subtle than “reach 100% and be done with it.”

That’s why Phase 0 can’t start soon enough. To date, I’ve been check listing my prep work, reading required texts and running through required exercises. When I finish something, it’s on to the next thing; when I finish all the somethings, I’m allegedly ready to dive in for real. There’s plenty of optional prep, but the core work follows the Pokémon model of skill development: if I can catch all the prep steps, I’m good.

But I can trigger that exact same reward center by grinding through a game I’ve already beaten, and I don’t like that at all. I’m hungry for a deeper, more nuanced level of engagement, beyond checklists, bigger than games. And it’s tough to satisfy that hunger before I know whether my preparation will hold up.

Luckily my days of toiling in solitude are almost over. Soon I’ll be an official part of a Dev Bootcamp cohort (let’s get it, July Firecrackers!) with real people as eager to learn as I am. So when I want to dive deeper into a concept than the checklist requires, there will probably someone I know willing to go even deeper than I do. And when I feel like I’ve fully understood something, I might be able to cement my mastery by explaining it to someone who needs some clarification.

Dev Bootcamp claims it can help students become better self-driven learners. I’m ready for that help. But in the meantime, I’ll settle for the warm comfy feeling of belonging to a group. I just need to keep the controller at bay for another week, and use that time to get control of the information I’ll be using this summer and beyond.

Beyond. Now there’s a scary word. I’ve been trying to keep my head down, look at just the next step, but I can’t shake this little voice in the back of my brain that constantly reminds me of how big this work is. I’m betting on myself here, betting that I can make the leap from semi-skilled jobs to a STEM career in less than a year. And I’m betting that I’ll be able to continue learning at a good clip after I’ve found work, building more skills and becoming more valuable, forever.

There are a hell of a lot more than 386 things to catch in this world. Is it crazy to want all of them? Probably. But if I don’t push hard, I’ll never get as much knowledge as I could have. I want the full stack, and I don’t even really understand what that is yet. But I want it.

Hopefully Dev Bootcamp will help me get it, by guiding me toward learning habits that are…


…super effective.

Sorry. I couldn’t resist.