hope

How to Fail at Dev Bootcamp (and How to Succeed)

When you do nothing but code at top speed for four days straight, you learn a lot about yourself very quickly. Even though I’m still in my first week, I’ve already been through enough ups and downs to offer some advice to anyone willing to listen. Including my stubborn self. This whole post could probably be summed up as “don’t be stubborn,” but I haven’t written it yet, so I don’t know. Let’s find out together.

How to fail: Panic on your own. Picture a circle inside of a circle inside of a circle. You now understand nested loops. Kidding! The inner circle is your comfort zone, where you feel good and everything is safe and you never grow. The outer circle is your panic zone, where you feel terrified and nothing is safe and you never grow because you keep running back to the comfort circle. In the middle is a whole lot of discomfort, and you’ll be living on the outer edge of that at Dev Bootcamp. The easiest way to slide out of the sweet spot and into panic is to isolate yourself from your many supports here. Stubbornness says “I got myself into this mess, I can get myself out of it…” and then it’s been three hours since you’ve looked away from the screen and you’ve written zero new lines of workable code and you start to wonder about the percentage of boots that get sent home and whether you’re one of them. You don’t want that.
How to succeed: Struggle with a friend. You’ll have counselors, speakers, instructors, mentors, and fellow boots to lean on. Get ready to lean a whole lot. There are signup boards for one-on-one instruction. There are sticky notes you can put on your monitor whenever you have a question. And there are your cohort-mates, who are in the same boat as you and equally invested in paddling forward. There is no shame in pairing up on a difficult challenge, and I’ll say it again because there is no shame in pairing up on a difficult challenge. Thursdays tend to be solo days here, but that’s just a suggestion, and it’s a terrible excuse to cheat yourself out of hours of progress because you were too proud to look around for a buddy to code with. When you have a friend by your side, it’s very hard for both of you to panic at the same time. At least one of you will be pulling the average back toward discomfort, and you want discomfort a whole lot.

How to fail: Explore every rabbit hole. Let’s break down a typical day. You get in at 8 in the morning. You code for an hour. You sit in lecture for an hour. You code for an hour and a half. You eat lunch. You code for an hour. You attend an afternoon lecture or activity. You code for two hours. Now it’s 5:00. You can either try to squeeze in a few more hours or call it a day and start fresh. If you head home at 5, that’s less than six hours of coding, and I’ve faced an average of seven challenges each day here so far. Do the math. If you decide to get cute or fancy or clever or insatiably curious and run off chasing an edge case (“Yeah, but what about if the user has a Chinese keyboard?”) or a strange solution (“I’ll do the whole thing with nothing but bracket operators!”), you will run out of time. I know this because I do this and I keep running out of time. I’m not the only one, but there are a lot of people who manage to get through every core challenge by the official end of the day, and they do things differently.
How to succeed: hop like a bunny. The people who finish by 5 block out their days in small chunks and set deliberate intentions for each slice of time. If they only have an hour to get a challenge done, that’s a great motivator to ask for help the instant they hit a snag in their process. These code bunnies are always hopping, from challenge to challenge, from Sublime to Google, from their desk to the kitchen for coffee, from their own work to a struggling friend for a quick head-clearing help break. The point is not necessarily to understand everything 100% before moving on; sometimes you just have to grit your teeth, accept that the last 25% will take 3 hours that you don’t have, get the challenge done the best way you know how and come back to ask about it later on.

How to fail: Blaze your own trail. There is a lot of honor in finding a brand new way to do everything there is to do at Dev Bootcamp. There is also a lot of regret and heartache and heartburn and loneliness. But forget about that gloomy stuff. You paid a lot of money for this particular wheel, and no one can tell you not to reinvent it. Who cares if people think you’re stubborn? They don’t know what’s best for you. You do. You’re going to do things your own way even if it kills you. Well, here’s a spoiler alert. It will kill you.
How to succeed: Read the map. Dev Bootcamp works because it keeps getting better. The mentors keep hearing and answering new questions, the curriculum keeps getting tweaked for clarity and concision, the boots’ cumulative knowledge keeps growing as cohorts keep passing the sum of the previous knowledge on to the next cohort, and now you understand recursion. Kidding! But seriously, they know what they’re doing around here. And unless you’re running the Coca-Cola of coding bootcamps in your country of origin, they know it better than you. Trust the process, do what they say in the order they say to do it, and listen really close when some senior boot suggests that you ask for help if you’re stuck for more than 10 minutes.

How to fail: Be a machine. This is it. Your big chance. All these weeks to do exactly the thing you love to do and nothing else. No one to distract you from your passion. Naturally, you’ll want to code all day and all night. You can handle it. You’re wired for this stuff. There’s plenty of coffee in the kitchen. Neo could study for 12 hours straight, and you’re the hero of your own movie, so you can probably rock 13 no sweat. Which is fine until diminishing returns start to kick in. Your head hurts from thinking hard all day, but stubbornness tells you to keep going instead of taking a nap. Now you’re making stupid syntax mistakes and drifting off every few minutes. Your code starts to suck. But machines power through. Machines soldier on. So you keep on going, even though there’s a way to do the same work in way less time by simply stepping back and rethinking your approach, and now you understand the difference between linear and binary searches. Kidding! But you don’t understand kidding, because you are the warrior robot, and warrior robots have no use for humor.
How to succeed: Maintain your machine. Not your computer. Your body. Even warrior robots need oil. You’ll want to compromise sleep. Don’t. You’ll want to skip meals. Don’t. Your brain needs sleep and food, and your code needs your brain, and your success needs your code, and now you understand how the Ruby require method. Kidding? I’m not sure. See, I’ve been fading fast all day and it’s because I’ve been skipping meals and naps. As much as you may wish you could just be a disembodied mind that only has to engage with code and ideas, you have a body too. Respect it enough to take decent care of it while you’re here.

How to fail: Beat yourself up. Ok, so today kind of sucked and you’re stressing about it. Maybe now is a good time to dissect each moment of your workflow and examine all the ways it’s bad. That will fix things. At least it should, but for some reason you can’t move past the recognition of your negatives and into the implementation of your solutions. You were on the verge of panicking earlier because you made some mistakes, so now it’s time to retreat to the comfort of self-pity. Make no mistake, wallowing in despair is definitely more comfortable than pushing past it into action. But how can you act when all you can think about is how incompetent you are?
How to succeed: Lift others up. The best way to stop thinking bad thoughts about yourself is to think good thoughts about someone else. When you’re floundering in the deep waters of a tricky problem, the counterintuitive solution is usually a good one: stop working on it for a while and go help someone else with their problem instead. If you can offer good help, it will make you feel all warm and fuzzy inside. Plus, you’ll build up a sense of mastery that will renew your confidence when you return to the challenge you were working on before. Sometimes the best way to lean on someone else is to let them lean on you. Put yourself in the position to remind yourself that you’re not alone in this, that everyone else is terrified just like you, that most people feel like impostors at some point in the curriculum.

For me, that point happened this afternoon, and I realized I needed to break after the Thursday evening DBCx talk (XSS vulnerabilities, fascinating and relevant stuff from Phil Corliss) for Vietnamese takeout and some serious decompression time at home. Technically, I’ll start tomorrow behind half a day of challenges; last night, my instinct would have been to lose sleep, neglect meals, and power through them alone in my room, all the while taking detours down esoteric paths that had nothing to do with the craft at hand. Today, I followed that instinct and it made me doubt my potential for the first time since I started Phase 1. It’s an awful feeling. I don’t recommend it.

Don’t be stubborn. Take this advice and succeed when you get here. If all goes well, maybe one day I’ll be standing over your shoulder, keeping you honest and focused and not letting you get away with not asking questions.

On that day, feel free to lean on me.

Advertisements

Poem: Unready

The worrying is back and bold and vicious, all talons and heavy wet fur and dark scales that reflect back the way I looked when I first said yes to this.

It’s happening again and I am part of it because I built it, dreamed it up from need or something like it, and it is just like the last time and the time before that.

Before I got here I wrapped the cord around my neck and turned my back on birth. They say they had to drag me stubborn into the work of breathing, had to twist and pull and wrench my head towards the world in front of me. I was not ready to live.

At five my brain was full of letters, wet and heavy with information, and still they held me back. I was not ready to socialize with second graders. I began to repeat myself, throwing out answers and jokes and punches, all of them perfect in their placement and terrible in their timing. I stared down the principal and dared him to punish me harder. I was unbreakable.

Eleven and counting and I cannot advance, the choir director says it’s immaturity but I’m positive it’s because he’s a butt head, so I must sit and watch the best singers travel to the best places and work through the best vocal warmups, and wonder whether I would ever be ready for anything I really wanted when the time came to take it.

I was not ready for college. I was not ready for the workplace. I was not ready for children. So when this begins to happen again and I can feel it breathing hot and loud and impatient like subway wind, I brace for impact and plan my retreat.

But time is an arrow, and none of my steps are backwards, and when I walked past seeing my path I claimed my life and I found my friends and I sang my song, all in time, and all of time will fade and leave me standing

At the edge of the next thing to happen, I turn back to find the reasons not to turn back around. And Love pulls and twists and wrenches my head back again, toward the world in front of me, and I hold my breath and take one more step.

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…

david-caruso-sunglasses_400_260_c1_center_top_0_0

…super effective.

Sorry. I couldn’t resist.

Comfortably Newb: Setting forth with a growth mindset.

I spent a lot of time poring through Dev Bootcamp grads’ blogs this week. About 75% of that time was me being baffled at the technical depth of the posts.

I’ve also spent a lot of time reflecting on Carol Dweck’s work on fixed vs. growth mindset. Partly because it was assigned to all incoming DBC students as required reading, partly because I recently had to review a video of a talk on Dweck’s research as part of a work assignment. Huge coincidence, so I embraced it.

Fixed mindset says: “Whoa, this material is WAY over my head. I feel like an impostor. I’ll never get this stuff. I’m not techie enough. I should just quit. These graduates are so far ahead of me, there’s no way I’ll ever catch up. Their success is my failure.”

Growth mindset says: “Wow, these people learned a LOT to know what they know now. They started out with zero knowledge – hey! that’s where I’m at now. Their success is my inspiration. If I follow the path they took, I know my brain is flexible enough to hold all the new information. One day I’ll get this stuff.”

I know next to nothing now. I’m sure I’ll look back at these first posts in a year and laugh out loud at my struggles with material as basic as a TI-83 game. (Puns! I got ’em!) But that’s a good hope to have, because it means I can see myself way smarter in a year. Watch me grow.

Now, if you’ll excuse me, I’ll be over here, trying to remember whether the key or the value comes first in a hash. I’m pretty sure it’s {

“key” => “value”

}

but don’t quote me on that just yet. Cheers.

Dr. Strangecode, or How I Learned to Stop Raging and Get Unstuck

Frustrating. Just spent 20 minutes banging my digital fists against a wall, wondering why I couldn’t solve this simple, baby-spoonfed problem. Feeling like an idiot. Wondering why I couldn’t get it right. Even starting to doubt myself a little bit. Was I really cut out for this?

The challenge was to create an array sorting method with a reverse-alphabetize function. You can find it yourself in the Ruby training. It’s in chapter 10, Ordering Your Library, lesson 5/6. I’d link it, but I’m mad. Because the solution thingy was broken.

When I stopped groaning and let myself check the Q&A forums for a lifeline, I saw that my code was actually a perfect match to someone’s submitted solution. The only issue was a glitch in the system. Vindicating, frustrating, and kind of inspiring. Because, when I was stuck, I tried different solutions that looked more wrong, but ultimately came back to the one that felt right. And it was right.

Almost right.

Despite the occasional flaw, Code Academy is great, and the greatest thing about Code Academy is this little picture-in-picture window next to your code, where you can see your work running immediately after you write it. I’m good at context clues, and I’d been seeing “nil” show up on incomplete code a whole lot. Basically it happens when the program is done running, and there’s nothing to print. The Ruby tester throws the word up to confirm that something happened and that it then finished happening. Even after I tested what I “knew” to be the right answer, I was getting that nil. No output, just nil.

Luckily, looking up your learning styles and using knowledge of self in your workflow is a mandatory part of DBC prep. Last week, I had reaffirmed something I’ve known about myself since I was 7 and reading my parents’ books about raising me. (I may have been an annoying little s*** at age 7, but at least I was an informed one. Wait, maybe I was a little s*** because I was informed. Moving on.) I’m a concrete random learner. Which means, among other things, that I’m a verbal guy, and I do a lot of experimenting to solve problems, and I need to do things my own way.

Oh, and that I do things out of order sometimes. And I digress a lot. I know I was talking about fixing the nil. Let’s revisit that.

Working out of order, doing little chunks of everything in the Dev Bootcamp prep packet, I had already installed Sublime Text 2 and set up my Terminal to handle Ruby, Rails, Git and Heroku (no idea why yet, but dammit, I did it). It’s how I became prepared to work through Chris Pine’s Learn to Program text. Now that I knew Code Academy’s tester was suspect, I reverted to tech I knew I could trust. I copied my code into a Sublime file, saved it as a Ruby app, and loaded it up in the command line. Bingo! Nothing showed up.

Long story short, the Code Academy chapter had been letting me get away with a misplaced and/or unspecific “puts” command (puts prints things to the screen and then starts the next work on a new line). With the code in a different window, I felt freer to explore. And I fixed the glitch in a couple quick keystrokes. That felt good.

I think I can understand the frustrated “stuck” feeling that DBC graduates say they broke free from at Dev Bootcamp. They say that learning how to get unstuck is one of the most important skills in a good programmer’s toolbelt. And they also say that short bootcamps do a great job of sharpening that particular tool, by surrounding you with other strugglers and mentors who know how to bring a stuck student into an aha! moment.

Learning is always hard, and it’s always fun. I think I learn things a bit more quickly because I have more fun learning. But there’s nothing fun about getting stuck because your teacher screwed up, or because your textbook was misprinted. Code Academy is way more good than bad, but I can see where the rough patches would stop others from moving forward on a path of self instruction. I just see the roughness as reinforcement that I can’t learn optimally in a suboptimal environment, and it’s hard to gauge how good a learning environment is when you hardly know anything about the material.

That’s why I wanted to go to Dev Bootcamp in the first place. I know I’m smart enough to take a couple years, muddle through things on my own, and get enough groundwork in to apply at a program that’s less “0 to 60” and more “20 to 90.” But I don’t want to waste years on silly hangups when I know my own potential is so high. I want real people, with real job experience in a real market, giving me the tools I really need to push beyond myself. The kind of tools where it won’t matter if I know the “right” coding language, or the most elegant solution, at least not this instant. Because I’ll able to adapt, able to grow, able to get myself unstuck from anything.

To do that, I’ll need more than hours alone at the computer. I’ll need a good human teacher and a kick in the pants.

From a boot, preferably.