Curiosity

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!

The Dev Bootcamp Rap Recap Repository

Here are all the Dev Bootcamp Rap Recaps I’ve uploaded to date. Thanks in advance for listening and pulling your friends over to your screen of choice so they can listen too.

Look for a new one each weekend here or at my homepage.

WEEK 1 (Full post with lyrics here.)

 

WEEK 2 (Full post with lyrics here.)

 

WEEK 3 (Full post with lyrics here)

 

WEEK 4 (Full post with lyrics here)

 

WEEK 5 (Full post with lyrics here)

 

WEEK 6 (Full post with lyrics here)

 

WEEK 7 (Full post with lyrics here)

A Farewell to Phase 1

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

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

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

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

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

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

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

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

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

Careening Toward Craftsmanship: My First Assessment at Dev Bootcamp

**For the uninitiated, arrays are [“structures”, “like”, “this”] and the items in them are counted in order: 0, 1, 2. Hashes are {noun: “structures”, preposition: “like”, pronoun: “this} and you can get their values if you know the right keys: :preposition returns “like”. Don’t worry about the differences too much, just know that they’re similar but different, and they each have suggested uses, kinda like spoons and forks. This post is about how I keep trying to eat ice cream with a fork.**

Alright, alright, Captain Persnickety. It was technically my first mock assessment. But it still mattered, and it still felt a lot like a test.

Thursdays at Dev Bootcamp are solo coding days, and during the second week of the first two phases, the biggest solo challenge comes in the form of a three-hour morning exercise that gets reviewed by an instructor later in the afternoon. The idea is to make something by using principles you’ve been practicing and then get near-immediate feedback on your process and its result.

I was nervous but hopeful when I sat down at my assigned station and started setting up my work environment. I figured I’d do a pretty good job executing whatever method I chose to solve the assessment challenge, but I knew I’d have to be careful about the strategy I chose. I seem to have a knack for choosing the least natural data structure to do whatever job needs to be done. When arrays are best, I choose hashes. When hashes make the most sense, I choose arrays. When it’s time to deal with objects, I choose arrays again.

I choose arrays a lot. Arrays aren’t the best choice for most things we’re working on, but they’re the things I understand best, and I often retreat to the comfort of using them instead of digging deeper in my tool belt. Right now, the array is my Swiss Army Knife. It does one thing excellently (handling small groups of easily-countable data whose order isn’t expected to change frequently) and 25 other things poorly. But instead of going to the hardware store and shopping for a real screwdriver, I keep figuring out how to hold my wrist just so to force incompatible screw heads to comply with the one shape I happened to have in my pocket when I started the project.

That’s what I did on my assessment. We were faced with a few different files and asked to find a way to put them together into something that could complete a task. The objective was kind of like something I might see in the real world someday: read through a set of customer requirements and find the quickest, easiest, most natural way to satisfy them. There were plenty of opportunities to implement the Single Responsibility Principle, which involves separating program functions into single “verbs,” so that no single method performs more than one task. And there was a really obvious opportunity to implement a variable naming strategy we had learned yesterday.

And, alas, I missed it by a mile. I zigged when I should have zagged. I beeped when I should have booped. I arrayed when I should have…well, I won’t spoil it here, because you future boots deserve the learning experience (and also, as a student, I’m contractually forbidden from revealing specific details about DBC curriculum).

That’s not to say I spiked the challenge. My execution was about as elegant as my clunky choice allowed. There were points in the challenge when my strategy was perfect, but I overextended it and fell a little short of my own expectations.

At the end of the mock assessment and subsequent code review, boots get a frank assessment of the phase completion track they’re on – there’s the Passing track, the Repeating track, and the agonizingly nuanced Passing But Could Benefit From A Repeat track.

I’m on the third track, which feels like this huge weight of pressure to accelerate my pace. Maybe I have it in me to pass this time around, maybe not. I’m pretty sure I do. Either way, I don’t think my speed this next week will be nearly as important as my direction.

Dev Bootcamp believes software development is a craft, not an art. Artists get the luxury of using one tool to make beautiful things. Think of a chanteuse’s voice, a sculptor’s chisel, a dancer’s body, an illustrator’s pen. Developers aren’t so lucky. Every year, there are new languages, libraries, APIs, and…other things I can’t think of because I’m a noob…that devs have to lean on to do their work well. It doesn’t make sense to get hyper-focused on gaining one set of expertise when you know it might be obsolete by the time you break even on the time and effort investment. There is space for experts in the software world, but there is much more space for flexible craftspeople who can move with agility through changing client requirements and newly-patched coding tools and anything else that might come up.

I believe I’m here to become more flexible. And I think my teachers share that belief. If we’re to become hirable developers, that means learning how to function in the real world. And real world knowledge isn’t just learning what people are doing now, it’s learning how they are doing it. I didn’t know what Agile Development was when I first got here, but I recognize a lot of similarities between it and the requirements of my former position at a small communications firm: talk with your client frequently, work efficiently, leave wiggle room for adjustments, and don’t grab a hammer and run around assuming everything is a nail. Even though I can mentally grasp these ideas, practicing them is a real struggle, especially because I’m trying to learn a new language at the same time.

But it’s not like I don’t have help. My favorite mentor has a way of spotting me staring off into space, taking me off to the side, and directly challenging all of my most comfortable habits:

“You’re good at leading in a group; maybe try hanging back sometimes and letting other people lead. You’re good at experimenting with code directly; maybe try reading the source code of other people’s successful experiments and getting some information that way. You like to be the one who’s talking and sharing; listen more today. You’re pretty slick with those arrays…but can you do the same stuff with a hash?”

There’s a lot of nuance to this process. Our optimal DBC learning flow is in the stretch zone between comfort and panic, but sometimes I’m stretching into new design principles and I realize that I don’t understand how a hash can get the next step done and I smell panic and retreat to the comfort of an array, and now I’ve managed to occupy three spaces simultaneously, even though it might outwardly look like I’m just stretching.

Take a step back, though, and the shape of things becomes clear. I came into this program as someone very comfortable with doing very few things, like eating pesto and writing songs and making my daughter laugh. I will leave it as a more well-rounded developer and a more complete human being. I fully expect that the stretching I do into new and uncomfortable data structures will prime me for the kind of stretching I’ll need to do when my employer suddenly decides I need to know another coding language, or when the job environment transforms to accommodate a glut of new programmers, or when science realizes pesto is highly toxic when people consume it as much as I like to.

I need that kind of stretchiness, because so much in my life is up in the air and dependent on the result of these 9 (12? 15?) weeks, and I’ll probably stay up in the air for a long while as I figure out what happens after. This assessment was a fun little awakening, a bell of mindfulness ringing far outside my comfort zone. The code review feedback I got today told me that my capacity to understand is not my problem, it’s actually my comfort zone.

As for my capacity to slog through repeated practice, enduring the fear and frustration that comes from learning new ways to say the coding ideas in my head…I’m not sure if that’s in anyone’s comfort zone. At least not at first. And yet here I am, in a place where I get to see my trajectory in time to change it, and I get to decide if I’m ready to make those changes every single day.

This is what I paid for, this safe space for wild reinvention of my oldest habits, this invitation into transformative discomfort, this contract negotiation between the person I am and the person I am capable of becoming.

It’s the first time in a long time that the two of us have been in the same room, but I’m confident that we can hash something out.

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.

Stuck, Stuck, Loose

It’s almost like they did it on purpose.

The first core challenge today seemed designed to hurt people’s feelings. It involved lots of pattern matching, finicky attention to detail, and a totally-not-obvious approach to building Ruby methods. Oh, and we didn’t learn how to implement the best solution until after lunch. And yet it was exhilarating to grind away at a single thing for 6 hours with no solution in sight. In the process, my pair and I got very familiar (way too familiar, actually) with nested loops and string manipulation.

But then we learned about regular expressions and it was like a switch turned on.

But that was in the afternoon. This morning all my fellow Bobolinks had an Engineering Empathy session in the Room of Requirement, because we’re new enough to need two in two days and because all the rooms are named after Harry Potter stuff. In the EE session, we discussed programming, oppression, and empathy, and how they all might be related. Though we didn’t arrive at a consensus, we all left the room a little more hopeful that we could actually be change agents in the world we were entering, adding to and maybe even elevating the cultures of the places where we’d eventually work.

After EE, everyone got pizza. I don’t know where this pizza was from, but it had eggplant and figs and blue cheese and it would have been the best part of the week so far if the coding wasn’t so challenging and amazing and cheesy and seasoned to perfection. For real, people, I still can’t stop thinking about that pizza. 

And then we dove into regular expressions, also known as regex’s, or regexps (if you’re into impossible-to-pronounce consonant strings). Regex’s look at stuff and try to find coder-defined patterns in it. If someone wrote you an email with a ten-digit phone number, I could use a regex to isolate just the number. In plain English, my method would be to look for three digits, then an optional single character (like a parenthesis, comma, period, or dash, or nothing at all…that’s why it’s optional), then another three digits, then another optional single character, and then four digits. I won’t go into more detail here because I know future boots are reading this and I don’t want to spoil the fun of figuring this stuff out. I will say this, though: STOP BEING AFRAID OF REGULAR EXPRESSIONS. I was, and I shouldn’t have been. They don’t look at all like plain English and that’s literally the only hard thing about them. There’s this fun site called Rubular where you can enter in whatever text you want and then see what happens when you run regex’s on it, in real time. 

With such a powerful tool, you’d think our day-long pairing session would have gotten easier. And it did, but we still felt rusty. So we tabled our challenge to revisit later, during my Pairing is Caring session. Pairing is Caring is an onsite mentorship program where really good teachers use the Socratic method to help you pull your best work out of yourself. After closing the 8-5 “workday” (almost no one leaves before 7 unless it’s for a quick dinner) we met up with our mentor, who patiently and firmly hammered home the principle of single responsibility. That’s when we got unstuck.

Single responsibility means that each method we write in Ruby should do exactly one thing. You wouldn’t want the person handling the money at the restaurant touching your food in the kitchen, so why would you want to get input and return a result in the same method? Following the SRP meant our code was not only cleaner and more elegant, but also less vulnerable against the kind of bugs that render programs unusable all at once. When we broke stuff during coding, we only broke one set of stuff at a time. We finished the challenge on our own shortly after our mentor wrapped up the hour.

Throughout the whole process, we were assured that we were doing a great job, even when we didn’t feel like we were. This assurance was coupled with an expectation that we solve the problem all on our own, so we never got any more than the vaguest of hints to keep us on the right track. We spent at least as much time doing our own research as we spent asking questions, and the balance was empowering in retrospect. In the moment, though, I occasionally found myself irritated that we weren’t just given the right answer when we felt stuck; my childhood traditional education lasted long enough to create plenty of bad habits, and they’re dying hard.

There were eight core challenges today, all of them based on algorithms. That’s kind of the theme for Week 1. I haven’t touched any of the stretch challenges so far, but that doesn’t bug me too much, because our final result on that first beast of a challenge worked cleanly and handled a lot of different types of input with ease. I’d rather understand three things very well than fly through six exercises without pausing to reflect.

Once again, this blog has taken me a half hour past my healthiest bedtime, which means I’ll either have to start truncating my posts, writing more on the subway, or finding a way to get out earlier each day. Not blogging is not an option. When I wake up tomorrow, I know I’ll remember more about today because I wrote about it

It’s not like I’ll need too much sleep tonight anyway. I’m already feeling performance adrenaline starting to bubble up. See, there’s gonna be a talent show tomorrow, and I brought my guitar in this morning. Once again, tomorrow is coming sooner than I expected, and I can’t wait. 

Day One at Dev Bootcamp

Author’s note: This post is way more epic if you start playing the embedded video before you start reading it. Trust me.

7:14 am They told us to get there ten minutes early and I am right on time. I’m seated facing the rear of the train, barreling towards a future I can’t see. The sun is battling the morning clouds for sky space. I think it’s winning. I hope it wins. I’m struck by the realization that everyone on this train has a reason to be here and a place they’re going. For all I know, each silent stranger is also going somewhere today that will change their lives. I send out as many good vibes as I can muster. I’m not sure if they’ll stick. I hope they stick. I am listening to This Will Destroy You at full volume. It’s not a soundtrack. It is a promise. The music shimmers, swells, soars, stills, shakes, sunders. I am ready to be destroyed. I am ready to rebuild myself. Everything I have done leading up to today is gone. My memories are just the stories I tell myself about how I got  here. I feel underprepared this morning, because I have told myself a story of opportunities missed. I did not remember to write down the small and huge victories that kept me up late at night, smiling at the progress I was making. Wherever I actually am, I am much closer to where I’m going than I was nine weeks ago. This feels like the first day of school. This feels like the first day of summer camp. My lunch is packed. I have forgotten my mittens. I wonder whether the teachers will be nice. I wonder whether I will make new friends. The train veers and comes close enough to the one next to it that for a moment I can see another room full of lives, moving as fast as mine, and my awareness expands and I realize the world will be alright no matter what I accomplish today. I will be alright too. And now we are underground. I am walled in but moving fast. My path is laid out and it will take me exactly where I’m meant to go. I put away my headphones and focus on my breath. This is not meditation. This is a warmup. This is my stop. This is it. 9:19 am I’m in the bathroom and there are ten more minutes of waiting before everything starts to happen. We all entered the DBC space at 8am, greeted by a volley of high fives and Gangnam Style blasting on the PA. After a few icebreakers, we spent an hour introducing ourselves one by one: name, cohort mascot, quirk. New boots (what up, Bobolinks!) and TA’s shared the reason they were here. The Salamanders and Coyotes, respectively starting Phases 2 and 3, shared tweet-sized advice for the newbies: Work your hardest. Remember why you’re here. Always be asking questions. Get sleep. Eat food. Enjoy the experience. And never ever push a commit to the master repository. That last one was phrased “Don’t push the master or you’ll get slapped” and for a moment my eyes were darting around the room, looking for the coder whose mastery had sparked a violent streak. Then I realized the guy was just talking about GitHub. Between the intros and this stillness was a catered Day One breakfast and a bit of time to mingle. I took the opportunity to ask everyone I could about what Week 1 would be like. “They pile so much on you, and then you work late to try and understand it all, and then you wake up and they pile so much more on you,” went one reply. So now I’m in the bathroom writing notes, barely following the letter of the “no phones” rule, which unfortunately seems to extend to Wi-Fi device permissions. Oh well. I’m sure I’ll be too busy coding to care about Twitter. 2:11 pm So many introductions, so many walkthroughs, so much controlled chaos. I’m starting to realize I’ll need to hold back at least a few concrete details of my experience in this blog, so as not to spoil surprises or give away answers. Still, there are moments that stand out, even without detailed explanation. A classic get-to-know-you name game got tweaked into a group refactoring challenge. There was a brief discussion about how to stay outside our comfort zones without slipping into panic as the weeks progressed. Boots gave impromptu talks on pairing, open source code, proper gong technique, speed skating. We learned about personal truth and why The Boy really Cried Wolf. An experienced coordinator cheerfully informed us that she would be here for us, whatever we needed. An experienced boot gleefully informed me that I was going to just LOVE this weekend’s group coding challenge. I’m looking forward to my inevitable Sudoku nightmare tonight. We are out of the gates now, and we’re coding. In Phase 0 we paired with one another in hour long sessions, tackling one challenge before parting ways. Now we are split into four-person groups and told we’ll be pairing with one of our groupmates for the entire day. There are six core coding challenges to complete, along with two “stretch” challenges for those who finish early or stay late. My partner is new to the Mac environment and rusty on version control. Not a problem. He gets to practice the basics, and I get to practice explaining them clearly and concisely. We’re both doing our best and scratching our heads and fist bumping when we figure things out, and it doesn’t even matter that we might be a little behind the average pace, except it kind of does, because I’ll need to get home by 11 if I want to sleep for more than 6 hours. I shrug off the stress and resolve to focus only on the present challenge and give it all I can. Things will work out. Help will come if I ask for it. 5:02 pm Pair programming is like playing a multiplayer video game that rewards you constantly for hours and then hits you with a difficulty spike so gnarly that you wonder whether the rewards were some kind of elaborate and sadistic setup. We were trucking along, plowing through engaging but basic material, and then suddenly 90 minutes had gone by and there was a cluster of TA’s looking over our shoulders and I can’t remember whether they dropped more F bombs or we did but there were a lot of F bombs being dropped. Turns out we had veered off course early on by changing two things when we only needed to change one, and the test file had assumed we would never change the second thing, and so we sat stuck until we thought to start from scratch and do the one thing, after which there was much “oh my GOD”ing and “you gotta be SHITTING me”ing and wailing and gnashing of keyboards. I couldn’t stop grinning through the whole thing though. I love a good challenge, and that was one hell of a good challenge. Afterwards, I’d learn that most of the pairs had gotten stuck on that finicky piece of code, and I felt good for not beating myself up when I had the chance. At this point, my partner was exhausted from the mental effort and ready to turn in for the day. But first, we had to attend our introductory Engineering Empathy session. The topic was feedback. Great companies thrive on it, failing companies stumble over it. A.S.K., actionable specific kind. The instructor stresses that the kindest feedback can be the hardest to hear. Kindness is not niceness. Kindness is loving and fearless. Kindness is respecting your fellow boot enough to tell them that it’s gut check time, that they will wash out at their current pace. It’s telling your partner that their pairing style is crippling your effectiveness. It’s admitting that you might not have the whole story, while standing firm on the validity of your piece of the story. Parallels are drawn between the Compass of Shame and the ways we can choose to deal with feedback. The instructor is given a tissue box. It’s full of feedback that’s difficult to process. He hits himself over the head with it, attacking himself. He throws it at the giver, attacking others. He refuses to take the box, avoiding any confrontation. He drops the box and walks away, withdrawing from the stress. Then he takes one tissue out of the box. It’s the part of the feedback that he can actually use. He does not actually use it. So far, we are all hale and hearty here at Dev Bootcamp. 9:13 pm My partner was tapped out at 5:00. That left me alone and eager to see how much of the code I could understand all by myself. I mostly flew through a basic refactoring exercise with one baffling capitalization requirement. Ditto for the first half of a method chaining exercise. I took a brief break to FaceTime with my daughter. We blew raspberries at each other for five minutes and then I told her a made-up story about Pikachu. My wife had gotten her hair done and she looked fantastic. For the first time since I’d left, I felt a little homesick. We hung up and I ascended the elevator to the seventh floor, ready to get back into my rhythm. Then came my second difficulty spike: an inscrutable chain of methods, a single-line gauntlet that needed a cleaner look. Prime numbers were involved. Squares too. It was a mess. Again, I shortly found myself joined by a bemused trio of instructors, and I felt no performance pressure because this was now our code and we were going to solve it together, damn it. We teased out an artful solution and patted each other on the back, having gained a deeper understanding of array iteration and deletion methods. It was getting late now, and I felt a pang of pressure at the realization that the day’s final core challenge was still untouched. Luckily, it was a challenge I’d already completed by overachieving during Phase 0 prep, and once I worked up the courage to ask a Phase 3 boot to pair up, we knocked out a solution that was elegant and D.R.Y. (Don’t Repeat Yourself; if your code uses the same line or a version of it multiple times, you can write it better). I’m heading home earlier than I expected to, and I’m almost shaking with joy. I made it through my first day without slipping behind. Walking down Grand, I whipped out my phone and scheduled a mentoring session for tomorrow, because one of those stretch challenges I missed looks too juicy to pass up. I’m doing this. I can do this. 11:38 pm In bed, fading, I click Publish on my blog post and put my laptop away. This will almost certainly be my last long blog post for at least a week. Maybe until this is finished. But maybe not. Where I’m from, it’s already tomorrow. I’ll try not to get too far ahead of myself.

Poem: Unready

The worrying is back and bold and vicious, all talons and heavy wet fur and dark scales that reflect back the way I looked when I first said yes to this.

It’s happening again and I am part of it because I built it, dreamed it up from need or something like it, and it is just like the last time and the time before that.

Before I got here I wrapped the cord around my neck and turned my back on birth. They say they had to drag me stubborn into the work of breathing, had to twist and pull and wrench my head towards the world in front of me. I was not ready to live.

At five my brain was full of letters, wet and heavy with information, and still they held me back. I was not ready to socialize with second graders. I began to repeat myself, throwing out answers and jokes and punches, all of them perfect in their placement and terrible in their timing. I stared down the principal and dared him to punish me harder. I was unbreakable.

Eleven and counting and I cannot advance, the choir director says it’s immaturity but I’m positive it’s because he’s a butt head, so I must sit and watch the best singers travel to the best places and work through the best vocal warmups, and wonder whether I would ever be ready for anything I really wanted when the time came to take it.

I was not ready for college. I was not ready for the workplace. I was not ready for children. So when this begins to happen again and I can feel it breathing hot and loud and impatient like subway wind, I brace for impact and plan my retreat.

But time is an arrow, and none of my steps are backwards, and when I walked past seeing my path I claimed my life and I found my friends and I sang my song, all in time, and all of time will fade and leave me standing

At the edge of the next thing to happen, I turn back to find the reasons not to turn back around. And Love pulls and twists and wrenches my head back again, toward the world in front of me, and I hold my breath and take one more step.

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.

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.