coding

Dev Bootcamp Rap Recap: Week 7

You’ll hear a lot more about Phase 3 in the coming weeks. This one’s more of a retrospective. I feel like I’ve come so far so fast, and I’m eternally grateful for the lessons I’ve learned at DBC. Check out the rap recap below, and read along with the lyrics below that. Have a great week!

The apprentice sat down next to the master and asked her how to use new tools to follow his passion.
She looked at him and smiled and took his hand like a child, and guided him to a table with blank canvas.
He sat scratching his head, cleared his throat and he said, “I wanna do bigger things! This really ain’t much.”
“You might be right,” she replied, “but way before you define a new art, first you gotta master a paintbrush.”

That’s how it felt the day I started out,
I thought I’d hold the whole web in my hands and stand tall and proud,
I sorta scoffed at the process people were talking ’bout,
and when I looked at the lessons I had a lot of doubts…
At first glance it all seemed esoteric and abstract –
I wondered if they’d ever bring us past that,
but as I moved from algorithms to a class act
I started craving the next challenge out the grab bag.
And as I flash back, marking my time here, it’s quite clear:
the real challenge was beating my fear!
All my ignorance masquerading as arrogance
is so apparent when I compare it to what I idealize in the present.
My mind is a weapon with double edge; if I never apply inner pressure then I’m only gonna hurt myself. 
I learned why help’s the greatest word I can speak to strive for the best of my potential
and I bet that I’m stronger than ever,
better for for the wear, aware of my heart and my head
I’m honestly at peace with who I’ve become,
and where I’m trying to go, cause I’m in the zone and remarkably stretching. 

I always thought that I could be like this.
I’m not perfect but I’m working like a fiend and I can see my gifts:
I learn best when I’m thinking with hands on,
I’m hoping I can keep with the plan to tinker with craft and stand strong.

And someday I’ll get paid to code
but it’s something money cannot buy that makes me go, 
I’m just a student who’s achieving in leaps,
loving the art of making beautiful and meaningful things.
I know the sky is the limit,
cause I write lines a little different than I used to
as I improve through the time I’ve been given.
Not just in Chicago, I’ll never stop coding cause I’m walking a long road,
here I go!

Advertisements

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.

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.

Dependency Infection

I’m getting more and more comfortable with the fact that design principles just don’t come as naturally to me as I’d like them to. I need to study them. I need to practice them. And I need to search outside myself for examples of object oriented programming done right. When I find a great example, I get really excited because I feel smarter for having seen abstract concepts at work in the real world.

Example: You know who’s really good at OOP?

The Joker, that’s who.

Today we learned a bunch of stuff about dependency. Dependency happens when one part of a program needs another part of the program in order to function properly. If I built a program based on a Coke machine, the robotic arm that grabs the Coke would need to depend on the information passed along by the purchaser’s button press, or else it wouldn’t know what type of can to grab. If I changed the order of the buttons, the machine would probably send me the wrong beverage can unless I also reprogrammed the robotic arm. Thanks to dependency, that “reprogramming the arm” job is now a necessary part of the “change the button order” job… unless I can anticipate that the buttons might need to be changed around from time to time, and then find a way to plan for that eventuality in my machine design.

That planning process is one of the main pillars of OO design, and it has a lot to do with something called separation of concerns. I think. Someone correct me if I’m missing something, I just learned this as of this morning. But assuming I’m on the right track, separation of concerns is the art of telling various pieces of the program, “Do this and exactly this and only this. Know that and exactly that and only that. If you need help with something, ask only this one other thing for the right information. Anything beyond those three tasks is not your job. It doesn’t concern you.

The object oriented programmer is like a master thief who assembles a variety of tools to pull off the perfect heist. Only these tools aren’t just tools, they’re people, and they need to work together in perfect harmony. But here’s the catch: the whole score must end up in the master’s hands. None of the other thieves can get a piece. But how does that even work? How can you get a big and complicated job done without telling each worker enough information to rip you off in the process?

The Joker knows how. He comes in with a plan fully hatched and then implements each piece in turn. Good programmers do the same thing, only instead of bank blueprints and instructions for each wannabe master thief, they use whiteboards and pseudocode.

I’m not a planner by nature, but you can bet your ass I’m becoming one at DBC. The challenges are becoming more realistic now, and that means workloads too big to mess round with on the fly. It’s getting increasingly harder to write code that fixes bad code, because there are enough moving pieces that I inevitably write more bad code and create entanglements that turn my app into a brittle and inflexible mess. Like a house of cards ready to tumble if a single queen needs to be swapped out for an ace, strongly interdependent programs have objects that aren’t easy to update later on.

Think of the real world implications. Your client expected the project to come in on time and under budget, and you made it happen…at first. But now, they decide they want to change how user data is submitted, and you look at the source code and realize you have four other structures that assumed the user data format would never change. Now, your client thinks you just need to tweak a feature, and they expect to pay feature tweak money for the job. But you’ll need program rewrite money because you let your little thieves know too much about other thieves’ business. Guess who’s leaving in the bus full of money? Your code, not you.

Dependency management is a fascinating principle and I need to spend a lot of time practicing it this weekend, whether it’s alone, with a mentor, or as a cohort. We’ll all be meeting on campus tomorrow to hold each other accountable for our success as a group. A few of us could probably benefit from a phase repeat, but we’re trying to get that number down to zero through hard work, focused practice, and a healthy dose of empathy. The all-stars among us will focus on teaching the strugglers. Ultimately, we’ll all learn from one another. I plan to do a lot of teaching and even more learning as I try to break out of my comfort zone and work on the skills that good leaders need to have: patience, compassion, trust, enthusiasm, and the ability to see awesome potential in the people I’m working with. And I hope my partners will see my potential when I’m the slow learner in the pair.

When the idea for a cohort-wide learning blitz first surfaced, there were concerns that people on the bubble might not get the push they needed to pass – after all, how can you move ahead when you’re reaching back to help someone behind you? But someone suggested that the moderate-mastery coders in our group could pair off together and feed off one another’s similar skills to learn new things. Like a virus, optimism spread  through our ranks and got us really fired up to code during the hours many would have reserved for free time. The sacrifice will be worth it. This weekend will make us all stronger.

And that’s a really good thing. Because we’re not code or thieves or Coke machine arms. We’re human beings, and there’s no rule against us depending on each other a whole lot.

Bobolinks, assemble!

Sudokode

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?"
else
puts "Hello, #{name}. How's the lurking going? You know you can comment, right?"
end
end

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.

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.