JavaScript

Dev Bootcamp Rap Recap: Week 6

I did it! I got through Phase 2 in one go, and I was so happy and proud of the effort I put in. Then Phase 3 hit, and the pace didn’t change. I feel like I’m hitting my stride, gaining more stamina when it comes to long coding sessions and grinding through the work in spite of feeling stuck on new problems. In the flurry of activity, I lost my hold on my blogging routine, but hopefully I’ll rediscover my balance this week. In the meantime, enjoy this rap recap. It’s a week late, and I’m trying to explain why in the lyrics. Read along below the video.

I know it’s a little late to ship this,
I know that I slipped out of existence,
cause I was turning my focus to JavaScript,
working and hoping that I could commit enough to live 6th week only one time,
and speed through the crunch time,
my social presence went from a feast to a lunch line.
I never guessed that I’d lose the heat from the sunshine; 
I was hidden and living at the peak of a CRUD grind. 

I kept reaching for a punchline only to grab lines of code from my troubled mind,
and catching up was the name of the game
my frantic pace was insane, I couldn’t even try to bust rhymes.
My priority shift was quite enormous: I quit from nightly blogging and missed shots to talk to my kid.
I had to sacrifice a lot for my wish to reach the Phase three spot but I did,
by dropping off of the grid.

I guess I did what I had to, banging on the door of potential until I passed through.
I’m hard-headed but finally understand dudes saying doing more than just coding can be a bad move.

And that’s true but I honestly think it’s worth it to try,
that’s why my rapping is returning to life,
I might not do it perfect – I’m uncertain and shy,
I might get down on myself and feel nervous at times, but that’s all of us!
Any programmer can lose confidence,
breaking links can make you think you’re an impostor but,
if you can weather the lows you can get back in the flow; 
I happen to know that it feels like an awesome rush.
So try not to play it safe –
test limits and get driven to win it working crazy late.
And let the struggle be your saving grace,
cause this emotional roller coaster is crazy but it makes you great.

Advertisements

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)

A Farewell to Phase 1

I’m moving on to Phase 2, and that means a lot of things.

It means I’ll be leaving a quarter of my cohort behind. Several of us will benefit from a repeat, and you can already feel this invisible line forming, separating what had been a cohesive unit into two distinct groups. Once I knew that one particular person was repeating, it was easy to spot the others around him, all clustered together at the far end of the space, digging into Ruby tutorials, reviewing code samples, decompressing, venting, commiserating.

It’s a weird energy to sit with, as someone who can only attempt to empathize. We learned about the difference between sympathy (“at least you can learn even more now”) and empathy (“sounds like you’re having a really difficult afternoon; I’m here to listen if it helps”) in our first Engineering Empathy session. But when the chips were down, I kept spouting sympathy instead of taking the dangerous dive into a shared emotional funk. I wish I had chosen kinder words. More than that, I wish I had spent more time pairing with struggling people in my cohort. Maybe if I and my quicker peers had invested the pairing hours, more of us would have been ready to move on today. I’ll never know for sure, but I’ll probably wonder about it right up until Phase 2 slaps me in the face.

That’s another thing about passing. It’s technically the fifth day of Week 3, but the curriculum thinks it’s the second day of Week 4. Assessment takes a lot out of me, and I struggled to get much coding done in the afternoon following my code review. That doesn’t mean there’s not plenty to do. We’re plummeting into ActiveRecord now, which means digging through file trees in search of the right programming object, tracking tricky variables through multiple parts of interconnected systems, and holding on to enough Ruby and SQL knowledge to debug and test every line of code we touch. And this weekend-long taste of ActiveRecord won’t hold a candle to our first three days in the next phase. It’s going to get very hard very fast, and I’m hearing that we should plan to add an hour or two to our work day in order to keep up.

As this new challenge takes shape in the distance, the first instinct is to get a better look at it by asking people who just conquered it. And that raises a different issue, because the Salamanders ahead of me have at least three among their number who passed their phase but would have preferred a repeat. Even the people who are smart enough don’t feel like their smart enough. One guy explained the dilemma in real world terms:

“Why are we here, right? We’re not here to pass assessments and do core challenges. That’s what we do here, but it’s not why we came here. We’re looking for a new kind of career, and we took a huge risk to find it. We all spent twelve grand to come to this place where we won’t receive a degree or official certification. Once we finish, we’ll be competing against CS grads and people with years of industry experience. The interviewer won’t care about whether we spent three weeks or six learning the real web app stuff. All we’ll be able to bring to the interview is what we’ve learned and the app we made in Phase 3. I want to be able to collaborate on a bomb-ass app, and I don’t think my skills are there yet. So I’d rather repeat and get my skills up on that level before I commit to a final project.”

I’m excited to be entering a phase that ignites such a deep passion for excellence. I’m looking forward to working on stuff that exists beyond the memory required to run a disconnected Ruby app. We’re about to start building things that will live on the web, and that means there will be layers of complexity and frustration caked around every little morsel of achievement. It’s going to take a deeper level of commitment, to the material and to each other as a cohort, for us to pull through this next three weeks. Our number will decrease as we leave some people behind, and it will swell again on Monday as we join the repeating Salamanders on a steeper path. And through all this flux, there’s a graduation tonight for the Phase 3 people who actually built bomb-ass apps, people who were agonizing over bugs and presentation plans and elevator speeches for prospective employers while the rest of us were blissfully splashing around in the shallow end by comparison.

It’s easy to get wrapped up in the ecstasy of self-improvement and forget that there will be a scary job search at the end of the rainbow. Every transition brings the reality into full relief, and with it a bunch of new work that will help prepare us for it. So passing isn’t really a celebration, and the weekend after isn’t really a breather. It’s the inhale before a deadlift, the gasp before a skin dive, the puffing up before blowing out dripping candles and making a wish.

Right now, I’m wishing for stamina. This next step will be ridiculously tough.

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.

Playing Catchup and Pushing Forward – How I Almost (Maybe) Washed Out of DBC

Wow. What a whirlwind couple of weeks it’s been. I have more to share than one blog post could comfortably hold, so I’ll do my best to hit the highlights and then get right back to my DBC work, which has taken up about 20-25 hours per week so far.

Well, kind of. My actual weekly average is somewhat lower than that number, because I made a huge mistake last week.

Let’s get one thing out of the way real quick: I’m still stuck deep inside a fixed mindset. Which is why I was terrified about learning JavaScript last week.

“I don’t know this! It’s outside my comfort zone! I might not be awesome at it right away! Maybe I should just put it off and start later.”

And I did start later. Ten days later.

Yeah, that’s not a good first impression to leave on your accountability group. They had bunched us into four-person groups at the beginning of Week 2 to help us pair program easier and leave solid feedback on each other’s work. Then they handed us a group assignment at the beginning of Week 3. I went from being a super-perfect proactive emailer (“Hey guys, heads up on this upcoming assignment! Let’s try to finish early.”)  to a total deadbeat in a matter of hours. That means my group was left twisting in the wind as I dodged emails and sat in silent panic for over a week.

What a terrible week it was. By Tuesday, I was nervous. By Wednesday, I was certain that I would get kicked out of the program. On Saturday evening I had visions of going back to retail work with my tail tucked between my legs, a total failure at everything ever.

Then a light shone in the darkness. My Phase 0 “student shepherd” reached out and asked how I was doing. I told the sad truth and committed (for the second time since the start of the program!) to making a change for the better. The response I received was empathetic and reassuring; apparently, my shepherd had gone through almost the exact same experience when she was a boot.

She encouraged me to stay in touch and not give up, and reminded me that I had plenty of resources to call on. Her positive attitude reminded me of myself on my best days, the days when I’m not afraid to be wrong in the pursuit of getting it right, the days when late is better than never, even when late is really late and never looks like an oasis of familiar mediocrity.

So I got back to it. And the strangest thing happened, which would be stranger if it wasn’t always what happens when I drag myself back on track: the work was easier than anticipated, and the world didn’t end just because I screwed up.

In the last two days, I’ve put in a dozen hours of work and completed all but two of my Week 3 challenges. I now understand the basics of JavaScript, enough to be comfortable with the prospect of creating a basic “fetch quest” game for one of those challenges, which I plan to finish in the next 24 hours.

The other challenge is a guided pairing session scheduled for early next week. During Phase 0 guided pairing sessions, an instructor works with a pair as they work together to complete a challenge. During my last GPS, my pair and I built a website mostly on our own, with a few gentle interruptions from our guide reminding us to stay on task and move forward. Guides are watching for technical mastery as well as soft skills – willingness to learn, communication effectiveness, bravery in the face of getting stuck – and the sessions are good opportunities to check your overall progress against someone else’s work.

So, to recap, here’s my Phase 0 experience in a haiku:

Markup, CSS,
Javascript, abject horror,
Ruby starts this week.

Looking ahead, I’m excited about digging into TDD (test-driven development) and learning how to use something called RSpec to write hurdles that only successful programs can jump over. The tests seem to get written first, which is an interesting reversal of every creative process I’ve been a part of in my life. I’m excited to see what’s ahead. And I’m really excited to see if I can get myself back on schedule in the next few days and free up more blogging time. Writing this has been the best 45 minutes of my day.

Now I have to go and figure out how to make the medic get the salve off the table and give it to the patient. Go fetch, medic! JavaScript is fun.

Follow-Up: The Scoop on Dev Bootcamp

Ok, maybe not “the” scoop. But it’s my scoop. After connecting with several DBC grads via email, Facebook, and Twitter, I know what to expect from Dev Bootcamp. At least I think I do.

This post marks the gripping conclusion of the search I started in this other post. Check the comments in that one for answers, too. Dave Hoover, who runs the Chicago DBC, stopped by to provide some helpful numbers and guidance.

To get my information, I tapped family networks for knowledgeable contacts, talked to people who have hired (and rejected) applicants with a Dev Bootcamp pedigree, asked DBC admissions staff to introduce me to boots, scoured the blogosphere for grads with current contact info, pestered Twitter users with DBC credentials in their profiles, and used an app called BootieTracker, created by a team of boots, to locate Chicago-area students and message them on Facebook with my questions.

I asked a ton of questions.

I wanted to know if the life-changing experience touted on the website was for real, if I would get help when I needed it, if the journey would be worth the effort.

I wanted to know whether people really went from 0 to 60 with no prior programming experience, whether a lot of people were getting kicked out to inflate graduation rates, whether DBC’s stats – 85% hired at $75K per year on average – were accurate.

I wanted to know how people handled the grueling pace of the program, how they felt about pair programming, how they struggled and overcame their setbacks, how they fared after graduation.

I wanted to know what boots wished they had known going in, what the program looked and felt like, what tech companies thought of Dev Bootcamp graduates, what grads took away from the experience as a whole.

I wanted to know everything. That’s what I generally tend to want. And I never get it. But I can get close. And I feel like I got close with this round of research. Close enough that I’ll be plunking down my deposit this week and focusing all my energy on Phase 0 prep. Let’s go over the info that cemented my decision.

Bullet points? Bullet points…

  • Most boots graduate. Everyone I spoke with reinforced Dev Bootcamp’s claim that the overwhelming majority of boots complete the program. Though a few do get asked to leave, and others drop out, those are the exceptions that prove the rule. In general, if Dev Bootcamp thinks you’re passionate enough to get accepted, you’ll be passionate enough to see things through. (This only applies to Phases 1-3, which take place onsite. The in-home Phase 0 might have a higher drop rate, but the nature of my search made it impossible for me to figure that out. And I was less interested in doing so, because losing steam at the start isn’t too costly; if you drop within the first three weeks of the intro phase, you get all your tuition back except for the deposit.)
  • Apprentices get paid, too. When I first looked at DBC, the path to becoming a junior developer sounded like this: 1) Apply. 2) Get in. 3) Work hard. 4) Poof! 5) You’re a junior developer. Nope. Not even close. The reality is more like this: 1) Apply. 2) Get in, start learning. 3) Work as hard as you can. 4) Learn as much as you can on your own time. 5) Get a job where you can keep learning on the clock. 6) Learn at work, after work, and on weekends for several months. 7) Somewhere in there, you become a junior developer. For a lot of graduates, step 5 means starting out as an apprentice, someone who does very basic stuff for the company while learning more complex stuff for themselves over 3 to 6 months, after which they either say goodbye (repeat step 5) or stick around as a real developer (step 7 completed, now do step 6 for the rest of your life). The good news is that apprentices in Chicago still make a living wage, anywhere from $40,000-$55,000 a year. Not a bad gig for a fresh-faced boot.
  • Repeating phases is a thing. Buried beneath the “Intensive 9-Week Program” branding is a deep desire to see boots succeed. Students invest a lot in DBC, and it looks like the investment is mutual. These guys really don’t want you to fail. So if you’re faltering at the end of a phase, you can retake it one more time to lock it in. Boots repeat Phase 2 the most. Phase 3 can’t be repeated, because it’s the final project and career planning phase, less about pure learning and more about applying principles in real-world terms. Some boots recommended that I budget extra time and money in case I need to rerun a phase or two. I’m glad I got this information before I settled on a rent arrangement for my stay in Chicago!
  • The command line is your best frienemy. When grads gave me advice about how to prep for Phase 0, learning the command line (Terminal on my MacBook) was the most emphatic recommendation. I need to practice navigating and managing folders and files, calling up help screens and manuals, and learning shortcuts to streamline my time. Since this work is all about the code, and the code is running in the command line, I must choose to befriend it or fight it every step of the way. Those I spoke with couldn’t stress it enough to me; I can’t stress it enough to anyone reading this for help.
  • Less HTML, more JavaScript. Dev Bootcamp primarily teaches Ruby, Rails, Javascript, and basic HTML/CSS. Of the four, HTML/CSS seems to be stressed the least. One graduate said I should refresh myself on the bare-bones basics and then get back to the Ruby and JavaScript stuff. Still, I shouldn’t beat myself over the head with JS, though, since DBC does a good job of teaching everything at the right time, and Ruby comes first. I was told to get the Code Academy JavaScript track done and leave it at that.
  • Pair programming can help…and hurt. Working in tandem is a great way to accelerate your growth, if you and your partner have similar proficiency and learning styles. If not, the imbalance can be a hurdle. Working with someone who leaves you in the dust could inspire you to push yourself that much harder. But it could be discouraging, and someone used to functioning at a faster pace may not take the time to reach back and help you get on their level. Working with someone much slower than you might feel like a drag on your time and energy, though teaching a concept is often the best way to learn it. However you feel about pair programming, it’s going to happen, so be prepared to work empathetically with other human beings. And remember to speak up if you feel yourself floundering, because…
  • Asking for help is good. And necessary. Dev Bootcamp says this, current students say this, graduates say this, employers say this. Knowing when you’re stuck, and looking outside yourself to get unstuck, is a crucial habit to develop. Use Google, Stack Overflow, GitHub, teachers, mentors, peers, whatever you have at your disposal. The students who knew how to swallow pride and ask for help grasped concepts faster and got more done each day. Being humble is always better than staying in the dark.
  • Experience matters less than passion. Some of the people I talked to had walked away from computer science majors. Some came from business or teaching backgrounds and had spent a couple years learning to code in order to solve work-specific problems. Some hadn’t touched code before they started at Dev Bootcamp. But every single grad I talked to was passionate about programming. It’s passion, not knowledge or expertise, that keeps someone on campus for 14 hours a day during the week and 10 on weekends. Dev Bootcamp gives people the tools they need to become “world-class beginners;” you don’t need to bring many tools of your own. But sharpening them takes a lot of time and effort, and passion makes the effort worth it. By the end of the three phases, those who showed the most hunger and drive were the ones who thrived.
  • Success is in the struggle. I had to take some time with this one. I asked several grads, “What were some habits of successful students compared to students who struggled with the material?” One answer: “…Well, what do you mean by success vs. struggle?” Another: “Dude, success comes from the struggle. You’re thinking about it wrong.” My bad. I hadn’t let it sink in that every single person at DBC faces an uphill battle. Strike that, we’re talking mountains to climb. And the successful people are the ones who get in there and strengthen their climbing muscles, the ones who learn by slipping how to grip better, the ones who aren’t satisfied with climbing only the mountains they know they’ll scale on the first try. If I’m ready to feel helpless, hopeless, and afraid, I’m ready to push through that and get to the wisdom that lies beyond.
  • You have to find your own cheese. More about the learning environment: This isn’t a classroom where you listen to lectures about mazes and cheese all day, poring over maze theory and case studies of dairy farms, and then take a test on paper with a closed book and multiple-choice questions. It’s a place where they throw a ton of information at you at the beginning of the day and then say, “We’re dropping you into a labyrinth. There’s some cheese in there. Go get it.” On some days, you’ll find it in an hour and spend the rest of the day teaching others how to find it or building a new labyrinth of your own. On others, you won’t find the cheese at all. The DBC curriculum is designed to reward experimentation and prepare students for a career where they’ll fail at things the first time, all the time. This flies in the face of an academic culture that rewards keeping your mouth shut and not opening it unless you know you know the right answer.
  • If you want the work, do the work. Employers stress that successful DBC hires are self-motivated and willing to push themselves outside their comfort zone. The grads that don’t get hired are the ones who stop learning once the program ends. Dev Bootcamp gives people a blueprint for self-instruction; if a person refuses to learn Java to get their dream job at a Java shop, that’s on them. Some of the graduates I talked to spent months sending out hundreds of applications and doing dozens of interviews. The word “hustle” came up several times. In essence, if you’re the type of person who can push themselves through a 100 hour a week commitment, you can push yourself into the workplace too. But you have to keep pushing, expanding your skillset and fleshing out your understanding by creating real projects on your own time and posting them to places like GitHub.
  • Learning never stops. If you want to be a programmer, there is never a point where you’re “done” educating yourself. Everyone I talked to said they spent big chunk of their free time attending programming events, tinkering with code, learning new languages, and so on. Senior-level programmers are the hot commodity in the web development world, and if you want to get there, you must several years of focus and dedication to take in all the information required to function at that level. Dev Bootcamp functions as a learning accelerator, and that function is twofold: in the coming months, I should expect to learn things faster than I ever have before, and I should expect to learn enough about how I learn to be able to teach myself new concepts as quickly as possible.
  • The rewards are real. Dev Bootcamp claims that 85% of grads get hired and that most of them are making upwards of $70,000 a year. Is this true? Yes and no. Check in with someone a couple months out of school and they’re probably apprenticing somewhere, building up their coding chops. Or they’re still searching for work while attending hackathons and making apps. Wait a year and check in again, and they’re likely working a job they love for pay that skews way closer to the advertised median. It’s all about who you ask, and when. Again, significant work is required to get significant results, but the results are easily achievable. It’s worth mentioning that people also felt their experiences represented those of their cohorts. There’s not a lot of variation in the stories I was told, which leads me to believe that no one’s BSing here.

Whew. That pretty much sums up what I’ve learned from my search. I’ll have plenty of firsthand information to share in due time, but you’ll have to settle for secondhand until I actually start my phases. The lessons I learned are pretty high-level; take away the first six points and this isn’t just advice about Dev Bootcamp. It’s about life. Which is why I’m so excited about it. Everyone I talked to said DBC changed their lives for the better. And no one had lost their passion for learning; if anything, passion intensified once boots graduated.

I love to learn. If I could choose any superpower, I’d want this one right here. If Dev Bootcamp can help me get a tiny bit closer to that level, then I’m in. Let’s do this.

Now, if you’ll excuse me, I have to go wrap my mind around recursion. Time to struggle.

April O’Neil, out.*

tl;dr It’s for real, it’s super difficult, and it’s worth every penny of the $12K tuition if you’re willing to invest the time as well as the money. But only if you love programming. If it’s all about the financial upside for you, get out while you still can.

 
*Don’t ever do a Google Image search for April O’Neil. Please trust me on this, and enjoy the default post image for now.