programming

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

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.

Kryptonite

As I sat there on the floor, looking up at my partner’s stern and disappointed face, I wondered how he’d managed to read my mind, and why my mind was so full of disgust, and whether I’d have anything new to add when it was my turn to attack myself.

Today was Engineering Empathy day again, and they say the second one is the hardest to get through. I hope so. I don’t know if I can do anything harder than today while I’m here.

The topic was the superego, that little bundle of rules and judgments and narratives, and how it sounds when it attacks you. Split into pairs, my cohort took turns unpacking all our inner self-doubt and self-loathing and self-destructiveness, one on one, face to face. I sat while my partner became his superego and I became him, and it was my job to look him in the eye and listen to all the terrible things he liked to say to himself when things got hard.

Then it was my turn. Stand up, look down, see myself, lash out: “You disgust me…everyone thinks you talk too much…why don’t you try another Netflix binge if being an adult is so hard…you’re going to fail again…”

And so forth. It was a long two minutes, but when it was over, I felt like I’d barely scratched the surface. Turns out I have a lot of ways to tell myself I’m not good enough. I had suspected as much, but anticipating an exercise like this one was way different from being right in the middle of it and realizing how invested I am in cutting myself down at any given moment.

I wasn’t the only one shaken. From the looks on people’s faces, I’m guessing a lot of us left that room in worse shape than when we’d entered it. But by the end of the day, I was grateful for the experience. It kept me from beating myself up when the challenges started to change.

Last week, most of the work we did was algorithmic, with one or two optimal “solved” states and infinite ways to get there. I thrived in that environment. Today, I missed that environment about as much as I miss my family back home.

We’re diving into the deep end now, building things that model real-world objects, sticking to a few key principles. Object-oriented programming has design guidelines, and following or ignoring them can mean the difference between code maintainable by total strangers for decades and code that no other programmer wants to touch. The rules have flipped. Now we’re facing challenges with infinite solutions and a scant few acceptable ways to write them.

As my pair and I struggled with the day’s open-ended challenges, we kept running into brick walls. This class wasn’t specific enough. That method was superfluous. Such and such variable was set with the wrong scope, or named wrong. I’m not sure if we correctly implemented a single data structure.

What really stings is the knowledge that today was likely the “key” day of the week, the one where the most crucial concepts are solidified and tested. All that buildup, and I feel like I flopped on the execution.

Or did I? I keep thinking back to the morning’s exercise, and then forward to the afternoon’s frustration, and I can’t help but notice that my self-talk sounded frighteningly similar in both situations. “You’re not prepared enough for this stuff…you take things too literally; design principles won’t stick to you…you probably don’t belong here…you disgust me…”

The superego session has already proven invaluable. Could I have been more prepared for today? Sure. Was my work good enough for my own standards? Nope. Do either of those things have anything to do with who I am as a person? I strongly doubt it.

I’m still upset with my poor grasp of design principles, but I’m learning that the other thoughts I’m having about today, the ones less about today and more about an ingrained instinct to “should” myself to death, those thoughts aren’t facts and I don’t need to carry them beyond the last word of this post.

I’m learning that some days I’ll ask for help a lot and get it, and the schedule will be full of meetings and lectures and improv and I won’t get much done regardless of how hard I push myself in between. I’m learning that sometimes pairing means getting to struggle with a friend and recognize that you’re not alone in not getting everything right away.

That was the big takeaway from the Superego Session. We all had similar fears, similar ways of yelling at ourselves, similar strategies for getting away from conflict by any means necessary. By suffering together, we lightened each other’s load a little.

After each paired Two Minutes Self-Hate, the listener got two minutes to reflect on how the experience made them feel. A lot of people used the time to try and counteract the arguments they’d just heard: “You made it this far and that counts for something…people don’t look down on you like you think they do…you’re doing a great job so far…I know you can do this…” People were looking at each other with kindness and speaking their truth about the beauty and strength and potential they saw.

Wouldn’t it be awesome, concluded the facilitator, if we could learn to look at ourselves with the same loving kindness we saved for others?

I think so. I also think I have a lot of reading and catchup to do in the next 24 hours if I want to keep my superego happy. And right now, that’s what I’m deciding to do.

I don’t have the time to listen to that voice anymore this week.

Ten Things to Expect from Dev Bootcamp’s Phase 0

You’re excited and anxious and completely in the dark. Phase 0 is coming up, and you think you might be prepared enough, but there’s not much time left and you wish you had a better lay of the land. You’re curious about the entire Dev Bootcamp experience and wondering why you haven’t heard more about the nine weeks that lead up to the on-campus Phase 1. You’re trying to make your transition into web development the best it can be, and you’re hungry for all the information you can get.

If one of those people is you, this post is for you.

For the last eight and a half weeks, I’ve been frantically learning how to code. Soon, I’ll head to Chicago’s Dev Bootcamp campus, where the pace and the pressure will reach a fever pitch. Graduating boots tell tales of 100-hour workweeks, ridiculously high expectations, deep self-discovery, profound emotional growth. For nine weeks, my life will be eat-sleep-code-improve, and they say I’ll be dreaming about code during the sleep part.

Sounds like fun!

During this final week of Phase 0, as I review what I’ve learned so far and get ready for what’s next, I’ve realized how far Dev Bootcamp has helped me push myself beyond my comfort zone. I want to give a little something back by paying forward a piece of the guidance I’ve received and demystifying some of the Phase 0 process.

Without further ado, here’s what I think you can expect from your Phase 0. Keep in mind that DBC changes their curriculum based on triweekly student feedback, so the older this post is, the less accurate it may become. To avoid that, I’ll try to stick to the broadest concepts. Let’s get started.

1) Expect a time commitment.

It wasn’t until the middle of my fifth week that I realized a lot of boots don’t work during Phase 0. I’ve been juggling work, family, and coding this whole time. It’s not easy. Each week means a new set of assignments to complete by Sunday at midnight. And it’s not like you can just burn midnight oil to power through them, since you’ll have to pair up with a peer at least twice a week and work together. That means frequent email exchanges, rain checks, and frantic “please someone pair with me I need HELP!” posts on your cohort’s private Google+ community page. Oh, and you’ll be coordinating your pairing sessions across at least three time zones, since not everyone headed to your DBC city lives in your state. You’ll need to master your own schedule in order to manage the workload.

Not working is probably the easiest way to free up the time you need. For me, that wasn’t an option. On a typical day, I worked from 9-5 and tried to cram in an assignment during lunch. Then I enjoyed dinner with my family and hung out with my daughter until her bedtime, after which I did Phase 0 stuff until I couldn’t keep my eyes open. It wasn’t unusual for me to spend 15-20 hours on a week’s work. That’s more than I was told to expect at the beginning, but everyone’s experience is different and people catch on to some things easier than others. By the time I was on my third week of Ruby, I was blazing through the challenges and managed to finish up in about 10 hours. During the HTML/CSS introduction, my decidedly non-visual brain stalled frequently and I needed upwards of 25 hours to get my head around things. Every week will bring a new set of obstacles and you won’t know how you’ll handle them until you dive in, so don’t fall behind and never let a Monday pass without at least glancing at the week’s syllabus. You can submit an extension form if you need a little more time to get something done, but it’s really hard to be an effective helper in a peer pairing session if you’re not up to speed on the concepts, so maintaining momentum is key.

2) Expect to set stuff up.

I think one of the main purposes of Phase 0 is to avoid or minimize the stress of 20 new boots on campus wondering why they can’t get their command lines to cooperate. Most of my Phase 0 weeks introduced a new language, site, or tool. Before I could get started solving problems, I had to make sure my machine was ready for the work. One week, I had to learn how version control works and get started working with GitHub from the Terminal. Another week, half my cohort stalled for a day when there seemed to be no crystal-clear instructions for updating SQLite3 anywhere on the web. I’m glad I slogged through some pre-Phase 0 command line and Sublime tutorials; they helped me get confident with learning more about my laptop before that learning became a weekly requirement.

I’d say setup, installation, updating, and tiptoeing around unfamiliar software accounted for a full 25% of the time I spent on Phase 0. Every week, the assignments were like two kinds of challenge rolled into one. The end goal was always to finish the tasks and submit the work for review, but it was impossible to start the tasks without the right environment set up. I compare it to a chef who must cook a dish in a kitchen with dirty pots and a disorganized pantry. The cooking is the easy part, once the kitchen is clean.

Side note: About 85% of my fellow chefs are using Mac kitchens, with Linux coming in second. Windows machines can get the job done, but they’re not recommended. One person in my cohort worked through half the phase on a PC before retreating to Craigslist for a used MacBook. I can’t speak on how hard it is to go the PC route, but I hear it’s pretty hard.

3) Expect to write things down.

Here’s one of the biggest questions I had going into Dev Bootcamp: Given a culture that seems so insistent on regular blogging, why is it so freaking hard to find information about Dev Bootcamp on boot blogs? During my research, I looked at dozens of blogs that had started out strong and fizzled after a couple weeks’ worth of posts, never to be updated again. Now I think I know why boots aren’t blogging. It’s because we are.

Ok, let me explain that.

Each week, boots must research and write two blog posts, one technical and one cultural. In a given week, I found myself studying problems in the tech industry or conflict resolution styles, intricacies of Ruby syntax or CSS layout tips, and then crafting blog posts to share with my cohort. My WordPress presence has diminished during Phase 0 because I’ve got two other weekly blogging assignments to complete and submit to my GitHub repository, and that doesn’t leave much time or energy free for personal blogging. I imagine the same is true for others.

The writing doesn’t stop with blogs. We write questions on the community page when we get hung up on a tough step of an exercise. We write detailed reflections on our work after each exercise we complete. We write feedback for one another after pairing to solve coding problems or do research. This approach is great for me, since I’m a verbal thinker and I write by transcribing the little running narration in my head. You might wish you could spend the time coding. But the writing helps process and solidify new concepts before moving on to the next thing, and it’s probably excellent practice for a team workplace, where good communication habits are at least as important as solid coding chops.

4) Expect to connect with people.

Your peers will be your most valuable resource during Phase 0. DBC staff took a hands-off approach to most of my questions during the phase, gently reminding me that I could find the answers I needed if I asked a friend for help. It was frustrating at first, but I came to appreciate the nudge after finding a few answers by drawing from someone else’s expertise. Some of the people in my cohort have extensive SQL experience, some are phenomenal at CSS, and some are total neophytes with a knack for Googling the perfect solution. Between all of us, there’s more than enough knowledge and persistence to handle the phase’s toughest coding challenges with ease.

I had to learn to get over myself, to stop needing to have every solution to every problem right away and all on my own. A few times, I hammered away at a piece of code, checking the Google+ community page in desperation after hours of fruitless agony, only to see that my exact question had been answered before I’d gotten started. My easiest weeks were the ones when I had the most time to pair up.

Pairing involves meeting up with someone in a video chat to collaborate on code and learn new concepts through experimentation. I’ve learned so much faster during my pairing sessions that I shudder to think how long I might have spent getting some of these new concepts into my brain. Apparently pairing is catching on as a popular way to code in the real world, and I’m grateful for the opportunity to practice early, even before I can be sitting next to my pair in person.

There are weekly solo challenges too, to keep everyone honest and make sure each boot has a decent grasp of concepts all on their own. But the solo challenges are really the exceptions that prove the rule. You’re not supposed to go through Phase 0 alone. Don’t lone wolf it. It’s way easier, more fun, and more effective if you follow DBC’s recommendation to pair up regularly.

5) Expect to learn a test-driven workflow.

If you’ve ever taken music lessons, you already know something about what to expect from Phase 0. Think of that stickler piano teacher telling you to arch your fingers and play slower at first to get into the right muscle habit. Think of your RA telling you to eliminate the buzz from each guitar chord you finger before moving on to the next one, even if it means you’ll take 20 minutes to get through Moonshadow. Think of your choir director insisting you warm up at the beginning of each rehearsal. There’s a process behind the craft, and good craftsmen respect the process. Dev Bootcamp starts teaching good processes from the start.

I got a firsthand lesson after one of my guided pairing sessions (four appointments where an instructor sits in and offers tips, guidance, and instant feedback). I had spent the entire pairing hour trying to drive the code to the next step, insisting that we get through as much as possible in our limited time, writing big chunks of code that failed miserably and having to go back and fix what felt like a million things. I was rushed and anxious and completely ineffective. My instructor left me this feedback: “There’s a saying that you only get to write one line of code between tests for each year you’ve been coding. So slow down and make sure each thing you write works before going on to the next thing.”

TDD, or test-driven development, is a process where you start by writing a test that fails and then write the code that passes that test. So if you wanted to write a program that printed “Hello world!” you might first write a statement asserting that the output of the program was equal to “Hello world!” The first time you ran the program, that statement would be false, since you had only written the test and there was no program to compare to the desired output. So then you’d have to write the program, and the key here is that you’d only have to write just enough to make it pass that one test. Then you move on to the next feature, write the test for it, check that it fails, and move on to the actual coding. What looks like a 30-minute challenge at the outset can end up taking an hour or more if you’re testing as often as you should be.

Writing a good test accomplishes a few things. First, it ensures that you know enough about the code you want to write that you can express the result in terms of a test that could be failed. It’s like the scientific method applied to programming. Sometimes the hardest part of comprehending the concept is writing a testable hypothesis. Second, good TDD turns the whole coding process into a sort of game, where each test is like a level to complete. It breaks the work up into manageable chunks and allows you to take breaks without losing your place. Finally, testing gives you twice the practice on each concept you dive into, since you are manipulating variables and checking syntax in two places for each test you write, once in the test and once in the code.

Looking back, I don’t think I’ve gained any deep knowledge on any one language so far. But I do have the beginnings of a good habit in my work technique. If all DBC was trying to accomplish for Phase 0 was to set some best practices and let us get to practicing them early, the phase still wouldn’t be a waste. But as a piece of a larger, group learning model, the TDD requirement is like the consistency icing on the learning cake.

6) Expect to make things.

Those blog posts I had to write on my technical and cultural topics? They exist online because I had to write the HTML and CSS that brought them to life. I made a (very) basic JavaScript game during my third week. Most of the Ruby we write creates apps that serve some useful purpose, be it mathematical or practical. There is required and recommended reading accompanying every week of study, but the reading is secondary to the experimentation and exploration we do. I’ve had a lot of fun with the pure coding challenges, which combine the guidance of a clear workflow process (study, write the program in plain English, test-code-repeat, refactor to improve performance) with the adventure of a blank canvas.

I like to tinker with stuff, and Phase 0 has felt like a lot of tinkering, playing around with things in my text editor and then running them in the command line to see if/how/why they totally/don’t/sometimes-but-not-really work. It’s a lot like how it feels to navigate in a new town. You start by figuring out one route to each place you need to visit, and then you start connecting the routes, and then you start looking for detours, and over time you begin to feel like a local.

Dev Bootcamp gave me tons of destinations and no maps. I had to Google proper syntax, collaborate with other boots, read documentation, and mostly muddle around before I found myself where I wanted to go. And then it was time to get to the next destination somehow. Learning this way has a compound effect, and the DBC curriculum ramps up logically, so you can use mastered concepts to solve small parts of new problems. Meanwhile, you’re always learning new “roads” and plugging them into your existing map of knowledge. Now that I’m in review, I’m facing the interesting task of rewriting in JavaScript some Ruby code I’ve already built. The idea of that would have scared me silly in April, but now I shrug and hop into the work, knowing that I’ll surely find some way through whatever snags I encounter. You can plan to fall in love with the learning process in a way you haven’t done since elementary school. Getting your hands dirty is the aphrodisiac.

7)  Expect to get stuck.

 It’s going to happen. You’ll be breezing through an exercise and suddenly you’ll run up against something you don’t understand at all. Whether it’s an error message you’ve never seen before, a chunk of HTML that just won’t display right, or a stubbornly goofy line of code, there will be something that trips you up and refuses to get out of your way. Few hours are more frustrating than the ones you’ll spend blankly typing in something over and over, utterly clueless as to why your insane repetition keeps producing the same bad result.

I hear real programming is no stranger to these bleak hours, and DBC is trying to get boots ready to face them bravely. So don’t be surprised when one exercise in a week’s batch has a staggering difficulty spike, an innocuous step that turns out to break all your work until you learn more about the mechanism behind it’s implementation. Apparently that’s normal. And why shouldn’t it be? Overcoming unforeseen obstacles is kind of what life’s all about. Example: I wrote this whole blog post last week, 2000+ words, and lost it to a phone glitch. It was infuriating. Oh well. This draft’s better.

Back to the point. These crazy geniuses want you getting stuck and feeling overwhelmed a lot during Phase 0, because guess what you’ll be doing once Phase 1 starts? This brand of education sees stuck-ness not as a display of weakness, but as a necessary precursor to rapid growth. No lesson sticks quite as hard as the one that comes with a few bruises from banging your head against the wall. And you’ll be doing some of that damage to yourself too. If you like this coding stuff, you’ll be curious about it. Your questions will eventually venture beyond the presented material and you’ll go and try to get them answered. Inevitably, you will end up going far enough down the rabbit hole to find yourself hopelessly out of your depth. I swear this will be a good thing no matter how you handle it. Either you’ll go above and beyond and dig up the answers you seek (or, if you’ve been paying attention, you’ll find a pair and go digging together), or you’ll put a pin in the topic and have a great question to ask a mentor later.

The important thing is not to wallow in self-pity when you get stuck, because that’s a quick way to turn a perfectly normal hiccup into an existential crisis. Who has the time for those? Better to acknowledge that you’re not perfect, step away from the problem for a while (DBC often recommends sleeping on the trickiest puzzles) and find something else you can do to stay productive in the present. You’ll always have enough extra to turn your attention to, and this phase is more about introduction and exploration than execution and perfection, so there’s no need to panic.

Right now some of you are still hoping you’ll be special and avoid getting stuck because, all your life, you’ve been really smart. Keep hoping, special. Everyone who gets into DBC is really smart. That’s not what this is about. Now is a perfect time to start reframing temporary failure as a necessary step to long-lasting success. Take it from a former perfect person: you won’t feel perfect for long here, and you’ll actually feel freed and healthier once you set aside that exacting self-image and let yourself grow beyond your can’t-miss comfort zone.

I’d say /rant, but I didn’t open the tag, so I’d be wasting keystrokes.

8) Expect empathy

I’ve never felt less safe than I have this spring and summer. Everything is brand new and I’m never great at it right off the bat. I’m stepping out of the office, stepping away from my family, stepping into the unknown. There’s no guarantee of a good job when I’m done, and my stomach often churns at the thought of floundering after taking such a huge risk. I’ve never felt less safe than I do now, and I’ve never felt happier, because I’ve never felt more supported.

There are guides here who have struggled with perfectionism and can offer encouragement to people like me who freeze up when victory is less than certain. There are instructors who pierce through difficult pairing sessions with sharp insight and warm understanding. There are peers who are all in this together, each careful not to squash anyone else’s aspirations or monopolize pairing sessions. At Dev Bootcamp, everybody wants everybody to win, and it shows.

I really struggled midway through Phase 0. I fell far behind and kept telling myself that I’d never make it, that I would be a failure once again, that I was stupid for even trying. But each time I mustered the courage to reach out for help, I felt heard and respected and even loved. My shepherd, a DBC grad, shook m out of my funk by checking in regularly and reminding me that my work, when I finally completed it, was good enough. I paired with peers who graciously walked me through the previous week’s material so I could get caught up. And every time I took a break from coding to check @devbootcamp on Twitter, there was someone lifting up a boot, helping them get connected in the workplace, patting them on the back when they found success.

And then the strangest thing started to happen. I started getting my own empathy back.

Dev Bootcamp founder Shereef Bishay uses the example of a restaurant to highlight how DBC empowers and motivates people to lift one another up. In a restaurant, he says, there are people who sit at the table and people who work in the kitchen. I went into DBC with a table mindset. I wanted to sit down, pay my tuition, dine for nine weeks, and walk out with a full belly and a tech job. After being at this for a couple months, I’m sliding slowly toward a kitchen mindset, where I find joy in making something with others, something that can serve people and make their lives better. One of these mindsets creates the kind of enthusiastic cooks restaurants love to hire. The other produces the kind of demanding patrons servers love to complain about.

I got to help someone make their code less repetitive last week, and it felt fantastic, and I learned something new. The week before that, I got to show a pair how to improve their workflow in the Sublime text editor, and it solidified my knowledge of the feature, and I got better at using it. As I write this (hopefully) helpful blog post, I find myself more and more inspired to finish up and dive back into my work, where I’ll get better as a natural result of focused practice.

Caring about others is how you get better at whatever it is you’re doing, and DBC is fostering an environment where it’s really easy to care.

9) Expect to succeed.

I’ve heard that the occasional boot doesn’t make it past. Phase 0, that not even the available deferment program is enough to keep some people intact in the hectic lead-up to the real thing.  I’m not saying that’s not true. But I will say that if you love coding, you will get through Phase 0 without too many problems. This is a phase more about habit building than career readiness, and you’re not going to face anything too intensely complex here. What you will face are the kind of barriers you’ll be able to break through with ease…if you know how to ask for help.

This phase is all about ramping up and getting things in order. If you follow the instructions you’re given, and admit when you don’t understand something, you will never be too far from the next step you need to take.

Every week during Phase 0, I found myself learning something new. Weeks 1 and 2 brought HTML and CSS into my world. Week 3 flashed just enough JavaScript to pique my interest. Weeks 4 – 6 urged me deeper into Ruby, covering math, arrays, methods and classes. Week 7 threw some SQL at me to see what would stick (not a ton, but enough to make stupid jokes FROM top_of_my_head WHERE punchline = awful). And then it all wrapped up with comprehensive review. Through the whole process I was building a progressively better looking blog, pairing up, leaving feedback and submitting exercises. It took a lot of my time, but it wasn’t grueling. Like a brisk uphill walk, Phase 0 made me break a sweat but did more to wake me up than wear me out. I think anyone can do this work as long as they get a kick out of programming itself and invest enough time in the exercises.

10) Expect to change your expectations.

I have never learned this way before. There are no grades, no quizzes, no answer keys. I’m not done learning when I master enough of a concept to parrot the bullet points back. When I’m stuck on something, the teacher’s job is not to help but to point me toward tools I can use to help myself. It’s the opposite of a competitive college environment; there’s a spirit of proactive cooperation that runs through everything we do.

I was expecting a lot more guided direction, but at the beginning of each week you’re given your exercises and then left to your own devices to work through them. It’s a really cool teaching and learning style that lets me work at my own pace and on my own schedule.

Most importantly, I’m more confident now than I would have thought possible. And it’s not because I have all this mastery so early. I barely know anything yet, and the more I learn, the less I feel like I know. But that has nothing to do with my growing knowledge that I can figure out any new information put in front of me if I have some decent waypoints and space to attack the challenge my way. It’s a really empowering feeling, one I hoped I’d experience after hearing so many people gush about how Dev Bootcamp made them better learners. Though I’d heard the stories, I had remained skeptical until I started to see the changes myself.

My attitude is better now. I can contemplate more work before feeling overwhelmed. I’m less reluctant to work in a pair or a group. I’m more aware of my positive and negative character traits and I have become a more reliable communicator. These changes came about because I committed to working through Phase 0 as instructed. I can’t imagine what life was like before this prep period existed. Thanks to these nine weeks, I’ll be able to walk onto campus on Monday with a few concrete questions and a working knowledge of enough coding languages to start at a very fast pace. It’s been a long and difficult journey from April to now. But I’m still standing. And I haven’t seen anything yet.

Phase 1, here I come.

Day One: Catching Up, Checking In, Setting Out

Ok, I’m in.

Phase 0 has officially begun. Am I as prepared as I thought I’d be? Absolutely not. Am I scared? Absolutely yes. Can I do this? Absolutely maybe.

I didn’t get through all the tutorials on time, so now I’m scrambling to catch up. That’s why I haven’t been blogging much. I could go on for a long time about mindfulness and workflow and trusting in the next step, but maybe that’ll be next post. For now, a brief rundown on the work I have cut out for me this week:

One scheduled intro session via video. I have to bring questions. I have to have questions. I have to learn what questions I have. I hav until Thursday to learn.

Nine self-teaching challenges. I say self-teaching because I’m the one going through them myself, and also because the lessons teach you themselves, ie I am learning how GitHub works because the lessons are posted in GitHub and the first few lessons are about using GitHub. Very clever. Very efficient. By the time I finished the first challenge, I had a Git account set up and a vague understanding of how version control works. My current task involves cloning to a local repository and learning about open source licensing. It’s briskly paced. It’s fun.

Each challenge requires reflection. I have to write down what amounts to a brief essay every time I learn something, and upload that essay alongside the stuff I just learned. It plays like a reinforcement/debriefing strategy, and it’s working so far. I think. This is still very new.

I had a moment of panic today when another boot sent me an email asking if I wanted to pair program with them and if I knew how, because he didn’t, and I realized that 1) yes, I did want to pair with them and 2) no, I had no earthly idea how and 3) please help me I’m scared. I still haven’t responded to that email, but that’s next on my daily to-do list; if I can’t get over my need for a perfect solution to every problem that presents itself, flawless on the first try, I’ll be washed up before I even begin. This email is a problem that only has imperfect solutions. I need to bite the bullet, admit to what I don’t know, and pick this other guy’s brain. Maybe we’ll figure out the solution together.

I wish I had more time to say what’s on my mind about this process. I’m anxious and excited and puzzled and interested all at once. The way they set it up, it’s like a meeting agenda mixed with a point-and-click adventure game. I need to do things in the right order, but there’s discovery at every turn. It’s wild. You should try it.

Since we last spoke, I know a lot more HTML and a little more JavaScript; I still need a little more of the former and a lot more of the latter. This’ll be the last you hear from me until I get those prerequisites nailed down. It’s one thing to augment understanding by blogging, but it’s another to spin wheels while work sits unfinished.

Priorities. I’ll see you soon.

Efficient Learning, the Walter White Way

That title probably makes no sense. But I didn’t write it for you. That’s what today is about.

Truth time.

I let myself get a little behind in my prep work, and now I’m staring down a few long nights. More checklists to complete. And every item is a rabbit hole I want to run down. It’s hard for me to pull myself back from endless curiosity and move on to the next thing, but that’s just my learning style and I’m pretty sure I can manage it.

Dev Bootcamp is big on learning styles. They want you to know something about how you learn best before you get started, so you don’t waste time. I did some required reading and took a couple of online tests they prescribed, and I wasn’t at all surprised with what I found. I’m not a very visual learner, but I get a little more from reading material and a LOT more from hearing/speaking and doing/testing. And my thinking style means that I need to do a lot of doing and testing, trying things out my own way and challenging my teachers, if I’m to learn at my best pace. I don’t need to be at 100% all the time. But 99.1% would be nice.

That’s good information to know. But if I believe it’s true, I need to apply it in order for it to stick. So this post is my meta-learning exercise, where I’ll be thinking through some ways I can get the most out of every hour I spend learning all this programming stuff. I figure if I spend an hour on this now, it’ll save me several hours in the coming days, and I’ll remember more of what I cram into my skull. And maybe I’ll have more fun with the whole process.

Bear with me, reader. Or don’t. This post might inspire you to do a similar exercise for yourself, but I don’t really care if it does. I’m only doing this publicly because it keeps me accountable and honest with myself. I’ve spent many years as a performer, guitar in hand and mic in face, and now I grow better when I’m doing things on a visible stage.

Corollary: If you’ve ever seen me play in person, I was lying to you. You thought I was giving you something because I wanted you to enjoy it. But I did it for me. I liked it. I was good at it. I was alive.

Walter White is not amused by this tomfolery

“Way to steal my words, jerk.”

 

Anyway, here’s how I think I learn best, and what I think I need to do/have/accept in order to learn better. (I already had to write something like this for a DBC survey after I was accepted. Let’s see if I can improve on it now that I’ve been learning new things for real.)

I’m not the reader I thought I was. By far, the hardest thing for me to get through was the Learn to Program e-book I had to read. Second hardest was the Learn to Count e-book I had to read. I’m a quick reader, and I had no problem comprehending the material or applying what I had learned later, but getting the information into my head was BORING. I kept getting distracted and losing my place. Or I’d get frustrated about getting distracted and stop reading for the day and come back to the material and find that I’d lost my place. I lost my place a lot. I had to reread paragraphs a lot. I was bored. It was inefficient. It was frustrating. Going forward, I need to own this weakness and commit to taking short breaks from material if I get bored. And I need to get back to it right after break time instead of letting myself lose momentum.

If I want to lock something in, I need to say it out loud. My family is getting sick of hearing about code. But they’re the ones within earshot, and every time I explain something to someone else, two things happen: my recollection improves, and my understanding switches on. Even if I’ve worked with a method for hours and think I know all I can learn about it for the day, talking about it always seems to open up another layer of mastery. And if I can’t express an idea verbally, that’s a pretty good sign that I don’t really understand it yet. So talking is a booster and a yardstick for me. Thank goodness I’m so good at talking! Of course, there won’t always be someone around to talk to, and my family will lose patience with me eventually. Maybe I could cultivate my self-talk skill over the next few weeks, or make up little songs to sing to myself about the things I’m learning.

When I’m mindful, I’m a great listener. Well, duh. That’s all listening is, really – staying in the moment and fully engaging with what somebody is saying. My problem is that I can spend less time listening and more time planning what I’m going to say next, or drifting off on some mental tangent and tuning out of the conversation. The first habit isn’t an issue when I’m watching an instructional video or a lecture, but the second buries me all the time. The worst part about it is that I’m giving up a strong learning style when I fail to listen; my auditory learning skills are some of my sharpest weapons, and I’m blunting half of them if all I can do is talk and drift. I’ve started practicing mindfulness daily, a few minutes at a time, and I’m getting better at turning my attention back to the moment. (Come to think of it, my reading has also gotten a little better since I started practicing being present.) There’s nothing mystical about it. When I’m here, I can soak in whatever’s here. When I’m not, I can’t. If I want to learn as fast as I can, I need to be in the room the whole time I’m learning, even when it’s not my turn to speak.

My eyes deceive me. I understand how flowcharts work, but I’m not good at drawing them. When I imagine how a piece of code is going to work, I’m thinking in words, not pictures. Those fun infographics that go viral with their fonts and their icons and their expertly-designed layouts? They don’t do much for me. I don’t even like cat photos. I know this skill isn’t fixed, I could learn to be a more visual person, but now is probably not the best time for anything other than my most efficient and fastest effort. So my cleanest idea here is to talk quietly to myself when presented with a visual concept. Or maybe I could try replicating the drawing on a notepad, but do it in a different way, so I’d have to demonstrate the concept as I drew. I don’t know. This one’s tough for me.

I make a great lab rat. Put me in a maze and I probably can’t draw it for you, and I might not do the best job of listening to your directions for solving it, but if I can just strike out in a random direction and figure it out from there, I bet I’ll be eating some cheese pretty soon. I’m at my best when I’m actually plugging away and trying things out. I took a lot of things apart when I was a kid; when I couldn’t take something apart, I smashed it to bits. Whatever it took to see the inner workings, I did it. I still do it. When I sit down with an intention to learn a programming concept, my first instinct is to play around with the code until something clicks. It’s a skill I’ve developed through years of songwriting and decades of gaming, and it’s equal parts gift and curse; I get frustrated if I can’t test a proof of concept immediately. And I might come across as annoying when I’m asking endless questions about something I don’t understand yet. That sounds like an auditory habit, but it’s really a kinesthetic one: from my point of view, I’m building something in my brain, and the teacher’s answers are helping me test the structure’s weak points. To learn at my full potential, I’ll need to keep defaulting to a do-first attitude instead of losing myself in thought, which is the default defense mechanism of my perfectionist brain (I can’t fail if I don’t start). And I need to keep working on playing well with others, so my passion for tinkering doesn’t come across as badgering or micromanagement.

Blogging really helps. When I get online and write things down, it puts my mind at ease and reinforces the work I’m already doing. So far, I’ve only written about my learning process and my shortfalls, because I’m nervous about diving in with a badly oiled learning machine, and writing about learning is helping me learn better. Once Phase 0 starts, I expect to get a lot more technical.

Whatever I end up writing about, I’ll keep on trying to post regularly. It’s a habit that keeps me pressing keys, if nothing else. Stay tuned. I’ll be back tomorrow.

For me. Not you.