DBC

The Rockwell station.

You Have To Know What Scares You More

I graduated Dev Bootcamp in September, and got asked to come back on contract as a junior instructor, and that job became full-time official last month, and that meant I finally got to reunite my family in Chicago, so we’re together again and my career trajectory has changed in a huge way and 2014 was the most amazing year of my adult life.

But that’s not what’s important for today.

What’s important is that my family moved to Lincoln Square, right off the Rockwell Brown Line stop. That matters because the train is at street level at Rockwell, which means I get to see a drama play out every morning that reminds me of my work.

The Rockwell station is just west of its namesake street. A street level station means there’s no bridge over Rockwell, just a track embedded in the asphalt and four big lighted wooden arms that come down when a train’s about to cross; it’s a railroad crossing, and sometimes people get hit at crossings, so there are bells and flashing red every few minutes before Kimball-bound trains slow down into the station. Or before Loop-bound trains arrive at the station, load up, and then cross Rockwell heading east.

The timing matters for this analogy. Kimball trains come through the crossing faster, since they’re decelerating from speed. By contrast, you’ll see and hear the warnings for a Loop train before the train has arrived at the station, before it has slowed down to a stop before the closed crossing, before passengers have boarded.

And I say all this so maybe you’ll think differently about the kind of person who would ignore bells and flashing lights and duck under a descending wooden arm to make their train. Maybe they’re not ignoring a clear danger. Maybe they have enough context to know when there’s no danger at all.

For many DBC students, the beginning of Phase 1 is all loud warnings and descending arms. Day One hits and it’s FULL – intros given, overviews covered, rules communicated, and on top of that there are several code challenges to get through in what amounts to only a few hours of core coding time. It’s hard to get through everything on the first day, and if you don’t, the fullness of the day gives your ego an easy out: “surely tomorrow, when there’s more time to code, I’ll get through the challenges easier.”

And then comes Day Two and the pace actually increases and it’s really easy to feel like you’re already in danger of total challenge/day/program/career/life failure, depending on how loud your inner authoritarian can yell at you from inside your head.

Before Dev Bootcamp, you were really good at something, art or negotiation or electrical engineering or parenting or sales or being a full-time student, and a lot of your identity is wrapped up in that first expertise. Society messages to us that everyone’s supposed to get good at something and then make some money doing it, and we get nervous enough about the money part that we forget to challenge whether that “something” really needs to be singular for anyone. It’s not that you can’t take on a brand new skill as an adult (I’ve personally watched hundreds do it since last May), it’s that no one’s ever explicitly told you that it’s totally normal, it might even be the default path to happiness, so all you’re left with is the sense that you’re struggling and that you’re doing it alone, because who’s ever done anything this crazy before?

Well, your cohort’s doing it, so that makes you feel safer. And you’ve got instructors who did it, and that helps a lot. But inertia is powerful, and when your brain can’t get its daily expected dose of expertise dopamine, two days in a row, it can make you panic all the same.

I’ve seen a few people have to leave DBC. Sometimes the program just doesn’t fit a student’s learning pace, and it hurts to say goodbye, because you still know they’re going to go off and become great coders one day, but you won’t be there to see it. But sometimes a student just hits an emotional wall and shuts down, and it has nothing to do with their technical prowess, it’s all about their courage.

It goes something like this: “I know I’ve already repeated this phase, and I really need to buckle down these next three weeks if I want to pull through. But what if I summon a Herculean effort and I’m still not good enough in time? Maybe it would hurt a little less if I just tapped out now and failed on my own terms. At least then I could retain some sense of control.”

This morning, on my way in, I saw the gate start to come down, and three people took off running to beat it. Two ducked under, and the third decided at the last moment not to chance it.

If the train represents a perceived danger, and the wooden arms are the ego’s defenses against that danger, maybe the difference between those who go for it and those who hedge is in the context. Maybe Runner 3 didn’t know it was a Loop train and that there was plenty of time to duck even after the arm had dropped completely. And maybe the knowledge that DBC is a safe place to learn and make mistakes, the knowledge that you’re surrounded by students and mentors and teachers who have your back and will help you succeed, the knowledge that so many before you have found success here by trusting the process and bringing their whole selves into the struggle…maybe that knowledge will empower you to pick your moment, stare down the train and get yourself where you were trying to go.

However… what if the train represents a path to somewhere awesome, a path you can miss out on traveling if you hesitate for too long? If that’s the case, maybe the arms and bells and lights are the ego’s defenses against personal change, and maybe Runners 1 and 2 weren’t afraid to duck under them because they knew the ego is a vicious liar when it doesn’t want change, and in that context the warnings weren’t warnings at all, they were just excuses.

But that’s not right either. Coding (and, I’m slowly learning, life itself) isn’t about finding the right solutions, it’s about the best solutions available considering the specific situation and the tradeoffs involved. There’s no black and white, just pros and cons and a choice to be made.

And if that’s true, the train is both danger and opportunity. It’s not your death or your salvation, it’s a risk. It might crush you, or it might open its doors and let you change your scenery. But the tricky part is that when the bells start to go off and the lights start to flash, you will need to decide for yourself what the warning means, and you’ll need to act on that decision quickly.

It’s convenient that I ride toward the Loop way more often than I ride toward Kimball, because it gives the analogy another layer. When I hear the bells and see a train barreling westbound toward the tracks, I know ducking the arm would be a stupid risk, not because I’m more likely to get crushed by a westbound train, but because west is not even where I need to go. Hopefully, long before you started DBC, you got at least a kick out of writing code that works; if not, this might not be the right risk for you in the first place.

But that’s hindsight at this point. You’re here now, and you’re uncomfortably new at this, and the work is really hard, and your defensive brain is warning you that you might be in danger. And yet the train that’s endangering you, these challenges, this process, the uncertainty of what comes after, the uncertainty about yourself, is the very reason you left the house in the first place. At this point, you can hold yourself back or push yourself toward the risk.

I don’t know your tradeoffs, so I can’t speak for you. And it’s a scary choice no matter what side you land on. Scary like running through a railroad crossing is scary, because in both cases you’ve grown up being told to never ever chance it: “A career change? At YOUR age? But you’ve got such a good thing going…”

Still, I’ll bet money that while running through a railroad crossing is scary no matter what, one of those runners was more afraid of getting crushed, and two of those runners were more afraid of missing the train.

I graduated Dev Bootcamp in September, and got asked to come back on contract as a junior instructor, and that job became full-time official last month, and that meant I finally got to reunite my family in Chicago, so we’re together again and my career trajectory has changed in a huge way and 2014 was the most amazing year of my adult life.

For me, putting my head down and going for it was the right move.

Advertisements

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!

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!

OO – It’s Magic, You Know…

Aaaaaand there it is.

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

Everything is a object.

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

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

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

“I object!”

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

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

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

object

oh, dammit. Make it stop.