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.