Learning

The Rockwell station.

You Have To Know What Scares You More

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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!

No, I Don’t Play Football – Some (Revisited) Thoughts on Stereotype Threat

Author’s note: I wrote this post in June for my Phase 0 blog. The current horror in Ferguson, MO made me think of it again. On dozens of social media feeds, witnesses reported seeing militarized police taunting peaceful protesters, attempting to goad them into violence, as if they were just waiting for an excuse. I see this as an example of stereotype threat in action; the officers came to the scene expecting the predominantly black crowd to act up, and did everything they could to make the crowd believe acting up was what they were supposed to do. It can be dangerous for marginalized groups when other people get the wrong idea about them. But it can devastating when they get the wrong idea about themselves.

It was like being typecast in real life. My fourth grade teacher sat down across from my parents and told them I was not doing well in math because I “just didn’t get” long division. On the surface, that’s kind of how it looked. I’d stare off into space instead of doing the problems when study time rolled around, I rarely turned in my work, and when I did, the paper showed only the answer, with no corresponding calculations. I might be cheating or using a calculator on those, the teacher said. But there was no way someone with my aptitude could be solving those problems in my head. Someone like me wasn’t smart enough.

Except I was. I had been doing the problems in my head, because writing out all my work felt tedious. And eventually I stopped doing the work, because it stopped challenging me. I was a smart, headstrong kid. Other smart, headstrong kids my age were in special gifted/talented courses where instructors harnessed all their mental energy in a positive way. I didn’t get that kind of structure; when I acted out due to extreme boredom, I was sent to the library for hours at a time, devouring books of my own choosing instead of sitting through lessons. Why wasn’t I considered smart enough for the gifted courses? Why was my disinterest in lessons seen as a sign of low potential? Could it be because I was one of only three black kids in my elementary school?

I started high school in a different district, but the attitudes I faced were similar. I lost count of the times I turned down a JV football coach’s sales pitch. I had been a choir kid my whole life, and I wasn’t about to add athletics to my full load of extracurriculars. In fact, I was and am one of the least sporty people I know. But that didn’t stop me from being scouted like an untapped vein of raw talent. In what I can only hope is totally unrelated news, black students were disproportionately well-represented on the football team, even though they made up a small minority of the student body.

I faced the threat of two stereotypes growing up. First, I could have been the dumb, belligerent black kid, and later, I could have been the strong black kid (who doesn’t need to worry about mental stuff because he’s strong.) Obviously, living with either option nets the same result – lowered academic expectations and a general “other”ness that follows you for life once you accept it. But that’s the weakness of a stereotype: it’s meaningless unless it’s accepted.

People in tech do a lot of talking about stereotype threat, but sometimes they get their definitions confused.Throughout my childhood, the danger of stereotype threat was not that other people could have gotten the wrong idea about me. It was that I could have gotten the wrong idea about myself.

In another world, I could have let it sink in that I was probably bad at math, that I wouldn’t belong in a group of smart kids, that I should probably stick to other subjects, that my future would be brighter if I embraced my number-clumsy nature. I could have let myself believe that football was my calling, that I wouldn’t belong with the music nerds and drama heads, that I should probably stick to the weight room and stop pretending I could make any other meaningful contributions to my school’s culture.

But I don’t need to go to that other world to see stereotype threat at work. I’m trying to break into a field with a known diversity problem, one that’s been attributed to self-selection. The argument goes that tech is overwhelmingly male and White or Asian because that’s the makeup of the applicant supply. So why aren’t there more female, Black or Latino people seeking careers in tech? Maybe it’s due to thousands of small social cues that those groups “just don’t get” tech and might be more comfortable somewhere else. Again, the problem is not that these prejudices exist. The threat is that the target will believe the stereotype to be true about themselves. And then the hiring numbers fulfill the recursive prophecy, and we repeat the cycle to the detriment of an industry that could desperately use some fresh perspectives.

So how do we fight back against stereotype threat? Two ideas spring to mind, and we’ve been talking about them at DBC for weeks now. With a habit of mindfulness, people can better monitor their thought processes and more quickly identify distorted self-concepts arising from societal stereotypes. And a well-cultivated growth mindset can build self confidence and counteract thoughts of permanently not belonging or being inferior. If growth is always possible, stereotypes will never tell my whole story, even if some of them start out being true. (And who’s to say I would have had to choose between football and music? Am I not strong enough to tackle both, terrible pun intended?) Like many issues around diversity, the root problems here are systemic, but many of the most easily implemented solutions take place on the individual level.

The kid who “didn’t get” long division ended up getting top-percentile math scores in high school. But that might not have happened, if I’d let myself believe that ignorant teacher. If she’s reading this, by the way, she might stop to consider how uninformed judgements about potential can haunt a child for life, and pray for forgiveness. 

What are we teaching people to believe about themselves? How are we priming the pump that sends talent down this pipeline I keep hearing so much about? How many great programmers are out there, unaware of their potential because they’re believing lies someone else told them about themselves?

And who are you, really? What are your strengths? Your limitations? Your passions? Are they there because they exist, or because you believe they do? Because someone told you that’s who you are?

I don’t care if you think you’re a crappy cook or bad at math or genetically predisposed to violence and opposition. Unless you’ve gone out and proven it to yourself, personally, over time, you might be living under the weight of a self-directed stereotype. And that’s tragic, because it means you’ve been more than you think you are this whole time, and you’ve been missing out.

Call it a sunk cost. It’s never too late to take the next step, to do the next right thing. The next time you notice yourself putting you or someone you know into some box, some category, remember that you have a choice. Pattern recognition is an excellent animal defense mechanism and a terrible way to be a mindful human being. Take a breath, take another look, and really try to see the person behind the category, especially if the person is you. 

The worst thing that could happen is you hate how deeply a world built on snap judgements has shaped your thought process up until now.

The best thing that could happen is you love yourself for who you really are.

The db:seeds of Discontent

The pace is starting to pick up.

We learned the basics of Active Record over the weekend, which let us use Ruby syntax to manipulate database information. A big part of the learning curve was practicing how to precisely define the relationships between data tables and translate those relationships into AR associations. We were given a few challenges over the weekend, plus a link to the necessary documentation, and told to get to work. Just like that, we’ve entered Phase 2, where students begin to learn faster than they can be taught, and self-instruction starts moving to the forefront.

Code challenges are getting complex enough that it now takes more time to explain to an instructor why I’m stuck than it takes for them to help me get unstuck. Multiple folders for models (data), views (pages), and controllers (logic) create a new challenge: when something breaks, any one of four or five files could be the cause, and figuring out which one is at fault only gets me a little closer to a fix.

And the clock is always ticking.

It would be an overwhelming situation without the time crunch. But there’s a time crunch. Getting hung up on a challenge and falling behind means playing catchup late into the evening and flailing to stay above water the next day, when they pile on more complexity and take off more training wheels. Today I felt the crunch in a big way, and it wasn’t even really my fault, and it sucked.

The task involved loading a huge list into a database and working with selections from it in Ruby. I had completed the challenge last night, but my pair for the day hadn’t, and I can always use some extra practice, so we got started. After a reasonable hour or so of work, things should have been going smoothly, but for some reason, results weren’t showing up like they were supposed to. Instructors stopped by to give us a few debugging suggestions, and we hammered away at our methods like lunatics, but we couldn’t dig to the core of the problem.  We started throwing up Hail Marys, printing every little thing to the screen in hopes of catching where we were going wrong.

In a moment of desperation, we tested for a ridiculous edge case, and that’s when we finally saw the issue: the database hadn’t seeded correctly. Our logic had been perfect since before lunch, and we had been spinning our wheels and questioning our grasp of the material for no reason. To make matters worse, it was now 4pm and I was exhausted and headachey. My day was basically shot, my energy spent.

And the next challenge was the real test of the day. We worked at it for an hour before the official day ended and I realized I couldn’t maintain focus any longer. Defeated, I slunk home for a nap and a blog break to clear my head.

Now it’s 7pm, I have at least one more challenge to attack on my own, and I’m still hurting from last night’s late recording session. I never like Tuesdays (too much structured lecture, not enough open coding time), but today was the hardest one yet, and it’s not over by a long shot.

So it goes. Not every day is a party. Frustration is definitely part of the package. But I’ll get through my work tonight, and tomorrow I hopefully won’t have to flail so hard. Maybe I’ll even pull ahead a little bit.

Whatever happens, my motivation still runs deep. And we’re actually making simple web applications now, which fires me up even more. Even on a crappy day, the reality is that I’M DOING THIS, I’m becoming a web developer, and the occasional outrage (why did you not seed properly, db?!?!) isn’t enough to knock me off course.

Every setback is a lesson. Every struggle strengthens my resolve. Days like this are the ones I’ll cherish the least, but ultimately they’re the ones that will matter the most. Bring them on.

But please, not again until next week at least. I’m tired.

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.

The Storm Before the Calm

It’s just an assessment.

Not a test. Not a stumbling block. Not a trial by fire. Just an opportunity to see whether the stuff in my head and my hands is enough to make the stuff in tomorrow’s five challenges work before the time runs out. If it is, great – I’m ready to move forward into the next phase. If it isn’t, great – I’m aware of my shortcomings and know what I’ll need to do to fix them next time around.

Apparently test anxiety is very common here. An instructor told us a story about a student who sticky-noted their monitor at the start of an assessment, signaling they had a question that needed answering. The question? “I’m panicking. I need help. I forget how to do all this stuff. Talk me back from the ledge.” I’m not that far gone, but there is a familiar feeling in my gut that comes before a moment where my performance will be judged somehow. I never seem to shake it, so now I’m trying to ride it to a saner place.

So. It’s not a judgment. Not a chance to fail. Not a culmination of past work. Just a look at how I’m doing right now. Nothing more.

My favorite mentor recommended bringing in something that makes me feel good: a talisman, a tasty snack, a great album, a hot cup of coffee, a photograph that keeps me grounded. There’s no rule against getting up and walking around, so I might even play my guitar in the hallway if I feel too stressed. The key, he tells me, is making sure my brain isn’t getting jammed up by raw emotion. The challenges won’t be lengthy, and they won’t show me anything I haven’t seen before, but they’ll be short enough that getting stuck will cost me, and the easiest way to get stuck is to panic.

But I won’t panic. Because it’s not an emergency. Not a crisis. Not a referendum on my past experience. Just a few beautiful lines of code I get the privilege of writing.

My mentor reminds me that there’s no sense in moving on to a phase I’m not ready for. Employers and clients won’t want unfinished projects, no matter how fast they’re delivered. I don’t need to beat this thing because it can’t be beaten. “It” doesn’t even exist. There’s just me and what I’ve learned and an opportunity to show it.

The best thing I can do to “prepare” is what I’ve already been doing. I know how to create classes. I can pass hashes to and fro. My parsing game is on point. I don’t miss indentations and usually remember to end my methods. I always read the f*cking error message. There’s no way to cram for this, but I can build more stuff between now and then if I want to. I think I’ll create a Band and Musician class tonight and see how they can talk to each other. And then I’ll get eight hours of sleep and arrive early in the morning.

The less I worry, the more I can focus on this week’s material, which has us building our own ActiveRecord methods and manipulating databases with Ruby code. Most of us left a couple challenges hanging this afternoon, and we’ve been told that our Phase 2 understanding depends entirely upon how well we acclimate ourselves to this new stuff. It’s pretty complicated and requires a lot of looking back and forth between files, checking the scope of variables (is :name the name of Fifi the dog or is it the name of the Dog class?), and writing and testing against rspec statements. There’s a lot to take in, and the easiest way to miss it is by focusing on the wrong stuff. It’s not about the easy work tomorrow morning, it’s about the frenzied learning that takes place during the hours before and after it.

Tomorrow is not the hardest part. It’s the easiest part. Assessment day will be a brief respite from the breakneck learning pace we’ve come to expect here. For once in three weeks, we won’t be up against anything new before lunch.

Two days ago, I felt like I was drowning, and I clung to a life preserver made of the stuff I felt like I was drowning in two days before that. Today, drowning in ActiveRecord calls, I found solace in the predictability of the SQL statements that had mystified me on Monday.

Tomorrow will be like a life vest strapped to a boogie board. As long as I can keep kicking, I’ll swim as far as I can swim. Whether that gets me to the next island isn’t really up to me at this point. I can hope it does, but hoping won’t help me swim any faster.

I woke up scared out of my mind and now I feel like I’m exactly where I need to be. I can’t wait for tomorrow.

String cheese, you’re coming with me.

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.