Programming

Dev Bootcamp Rap Recap: Week 7

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

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

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

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

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

Advertisements

Dev Bootcamp Rap Recap: Week 6

I did it! I got through Phase 2 in one go, and I was so happy and proud of the effort I put in. Then Phase 3 hit, and the pace didn’t change. I feel like I’m hitting my stride, gaining more stamina when it comes to long coding sessions and grinding through the work in spite of feeling stuck on new problems. In the flurry of activity, I lost my hold on my blogging routine, but hopefully I’ll rediscover my balance this week. In the meantime, enjoy this rap recap. It’s a week late, and I’m trying to explain why in the lyrics. Read along below the video.

I know it’s a little late to ship this,
I know that I slipped out of existence,
cause I was turning my focus to JavaScript,
working and hoping that I could commit enough to live 6th week only one time,
and speed through the crunch time,
my social presence went from a feast to a lunch line.
I never guessed that I’d lose the heat from the sunshine; 
I was hidden and living at the peak of a CRUD grind. 

I kept reaching for a punchline only to grab lines of code from my troubled mind,
and catching up was the name of the game
my frantic pace was insane, I couldn’t even try to bust rhymes.
My priority shift was quite enormous: I quit from nightly blogging and missed shots to talk to my kid.
I had to sacrifice a lot for my wish to reach the Phase three spot but I did,
by dropping off of the grid.

I guess I did what I had to, banging on the door of potential until I passed through.
I’m hard-headed but finally understand dudes saying doing more than just coding can be a bad move.

And that’s true but I honestly think it’s worth it to try,
that’s why my rapping is returning to life,
I might not do it perfect – I’m uncertain and shy,
I might get down on myself and feel nervous at times, but that’s all of us!
Any programmer can lose confidence,
breaking links can make you think you’re an impostor but,
if you can weather the lows you can get back in the flow; 
I happen to know that it feels like an awesome rush.
So try not to play it safe –
test limits and get driven to win it working crazy late.
And let the struggle be your saving grace,
cause this emotional roller coaster is crazy but it makes you great.

Dev Bootcamp Rap Recap: Week 4

This week was the toughest and most inspiring yet. So I tried to write a verse as intricate and cross-dependent as the curriculum itself. Lyrics with links are beneath the video, and you might want to do some clicking, because some of these metaphors are kind of a stretch.

Enjoy!

It goes create-read-update-delete,
It’s no delaying the feverish pace we keep.
First we rake db:migrate and seed,
and then we table strings and make them sing.
Cause we’re sitting in with Sinatra, giving it all we got,
delivering something awesome and shipping it on the spot.
We’re dipping our toes in water and dripping a little knowledge to test.
I confess that it’s getting a little harder but we got this, we aren’t weak;
we stay cool and venture out (like a freon leak) into the web
and check the browser for the ERB, and we all see the progress of three long weeks.
Breathe, dog, breathe…because every day is a training one:
breaking CRUD toys with poise and having crazy fun,
raising up hands to ask questions and make ’em run,
staying tough, driven, and with it and never playing dumb.

Dedication is how we handle the pressure
and this user authentication is a valuable weapon.
I’m getting after the sessions. The routes are hooking up,
and that’s how the cookie crumbles when the packets are sending data
in hashes with hexes I’m feeling good which 
means the programming world is where I should live.
Ruby is dope but I’m flexible and I could switch
over to Haskell and that would make me a HOOD-rich codeaholic

…and at least I would be functional
but that discussion should be conducted when I get done with school.
I’m staying grounded about it and in a humble mood,
steady growing my knowledge like the seed of a mustard moves.
I’m journal writing these raps to sort of save state,
plus I hope I’m lighting a path like border gateways.
So if you feel insecure like port 80 observe my short statements
and maybe you’ll try to chase fate,

and witness why I’m believing in where I’m staying –
I’m saying these are some people with dreams and they’re amazing.
See, on the weekend we drink in these validations
’til we’re turnt up like one screen at a pairing station.
It’s apparent we’ll make it cause we’re looking out for each other
as brothers and sisters and getting good at what we discover.
It’s cool, we’re showing up because we love what we do,
and as for practice there’s never really enough to consume.
We stay hungry, but not for the dollar; we ain’t Puffy,
the Benjamins matter less than the drive to create something
and take it from me, if you’re just trying to make money
you’ll find this ain’t funny – the grind is straight nutty. Dig deeper.

I’ll try to help you see these things each week,
computers counting this as release 3,
and I’m on a mission to spit this out from DBC –
bringing more flow control than the TCP.

– Duke Greene

The Dev Bootcamp Rap Recap Repository

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

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

WEEK 1 (Full post with lyrics here.)

 

WEEK 2 (Full post with lyrics here.)

 

WEEK 3 (Full post with lyrics here)

 

WEEK 4 (Full post with lyrics here)

 

WEEK 5 (Full post with lyrics here)

 

WEEK 6 (Full post with lyrics here)

 

WEEK 7 (Full post with lyrics here)

Ten Things to Expect from Dev Bootcamp’s Phase 1

I made it out of Phase 1 in one piece, and now all I want to do is look back. That’s probably not the healthiest impulse, considering the likelihood that next week’s pace will make my last three seem like warmups. In the interest of moving forward, I’m going to pack my entire phase into one retrospective post so curious readers can see what it’s like at the beginning of Dev Bootcamp.

Word to the wise – your mileage may vary! Every cohort is different, and instructors group off in different ways each phase. And you are unique; you’ll bring to this experience a particular set of skills and expectations that will determine what you get out of your first phase on campus. I’ll try to stick with the big concepts in a way that doesn’t spoil any cool surprises. Hopefully you’ll find something useful here, something to help make you into a better coder someday, or at least help you make a decision about how you’ll be spending the next six months of your life.

Here’s what you should expect from the first three weeks at DBC.

Expect the first week to kick your ass. It’s a system shock akin to being thrown into Lake Michigan in May. While you’re asleep. And mostly naked. You’ll hit the ground running on your first day, bouncing between welcome meals and things-you-need-to-know lectures and personal introductions and code. Yes, there will be code. And it likely won’t be code you enjoy writing. The first week is basically about building algorithms, the little script machines that work under the program’s hood to manipulate data and generate results. It’s a lot of math-y stuff, like telling a computer to look at a list of integers and spit out only those that are evenly divisible by 17, or figuring out how to take a number and convert it into a different type of notation.

There are also a lot of activities that deal with string manipulation, and you’ll even dip your toes into regular expressions, which are basically chunks of gibberish that isolate relevant patterns with the precision of a Google search. When you hear about regexp’s, you’ll be scared and want to avoid them. Do that if you want, but it will cost you a ton of time and energy better spent learning the new tool, and eventually you’ll learn it anyway. This cycle – fear, intentional ignorance, reluctant engagement, begrudging acceptance, and then habitual usage – is at the core of the DBC process. Get used to it, and try to skip ahead to the reluctant engagement part as soon as you can.

By the time you’re done with the first week’s challenges, you’ll have gained a new appreciation for some of the more powerful methods in the Ruby arsenal. To put it another way, you don’t really love your staple remover until the day someone makes you pull out a hundred staples with your fingernails. A lot of boots say the first week of Phase 1 is one of the hardest weeks overall because the material is dry and largely unrelated to the work you’ll actually end up doing as a web developer. But it’s there for a good reason, and you’ll have to learn it if you want to be solid during the rest of the phase, so strap in and hold on tight. You can make it. Even through Sudoku, you can make it.

Expect to stay classy. There’s this thing called object-oriented programming, and it’s all about getting parts of your program to play nicely with one another. That means making sure each part does exactly one thing and doesn’t spend too much time prying into the business of the other parts. After you get past the algorithms from the first week, your focus will shift to OO design practices almost immediately. This will make you dizzy. You’ll be trying to keep track of a class you created, what its variables are, what it inherits from, how to call methods from it, and then all of a sudden you’ll hear, “Oh, make sure you don’t put that there. It’ll work just fine now, but your program will be really hard to upgrade later if you do it like that.” If this was an English course, you’d be learning the basics of nouns and verbs while trying to match rhyme and meter. It’s daunting stuff.

And once you get the hang of it, it’s also the most rewarding stuff so far. Harness the power of Ruby objects, and you’ll be able to build facsimiles of real world systems in code, which is mindblowingly cool. You can make a Band object that contains a bunch of Musician objects and then call something like awesomesauce.kick_out(narcissistic_lead_singer) to make your group sound better. You can make a Congressperson class that inherits from the LazyBully class and add a lot of unfortunate dependencies to it. As I type these words, I notice that each of my arms happens to be an instance of the Gun class. 

The point of all this is to stop thinking of programs as singular things that run in a set order, and start thinking of them as groups of objects that talk to each other in specific ways. This mindset shift is at the core of the OO movement, and it can be hard to wrap your mind around if you come from another school of thought. Don’t worry. You’ll get plenty of practice learning design by making real-ish things and then realizing why they’re not working right (hint: you didn’t whiteboard enough).

Expect to stretch. I have some bad news for you: you have no idea what you’re capable of. Luckily, Dev Bootcamp is here to help you fix that. To unlock your maximum learning potential, they will do everything they can to shake things up and keep you on the outer edge of something called the stretch zone.

Picture a slice of cake, because cakes are circular and delicious. At the tip of the slice, the center of the circle, is your comfort zone. You know exactly what’s going to happen when you take your first bite. It won’t fall off the fork and you won’t bite off more than you can chew because that first part of the slice is so darn thin. In the comfort zone, results are utterly predictable, contentment is totally guaranteed, and growth is absolutely impossible. You don’t want that. Everyone will know you as the person who only takes the first bites of cake slices, which is kind of weird and more than a little pathetic.

At the other extreme is the panic zone, the outer edge of the cake that’s basically all frosting. Have you ever noticed how cloyingly bitter cake frosting can be all by itself? It’s terrible. Once again, you’re not eating cake, but you’re probably thinking all about it, wishing you could go back to a better cake/frosting balance, even if it means being the “first bites only” weirdo. When you’re panicking from overwork and lack of understanding, your brain shuts down and seeks comfort. But you didn’t pay 12 grand for a cake to nibble at frosting and skinny slice tips. You’re trying to eat some cake here!

So Dev Bootcamp sets you up in the sweet spot, that outer-middle ring of cake where the batter isn’t undercooked and the frosting is just starting to get deliciously thick. That’s the stretch zone, where you’re getting the most calories per fork-bending bite. Except instead of calories, it’s aha moments and hours of focused practice and opportunities to grow in groups. Less delicious, but ultimately more fulfilling. DBC wants you to be safe while you’re here, but safe isn’t the same as comfortable. There will come a day in your first phase when you’ll feel like there’s too much work to do and you’ll never get it done, and you’ll reach out for something, anything you can understand. And then you’ll look at your hand and see that you’ve grabbed on to the thing that made you this afraid yesterday, because in 24 hours your phobia morphed into your security blanket. That quick learning turnaround can only happen when you’re living in the stretch zone.

Expect to stretch. That’s not a typo. You’re going to do some yoga. It’s only five sessions over the first three weeks, but it’s still exercise, and it’s morning exercise, and it will probably make you sweat. You’ll want to bring a change of clothes unless you’re some kind of fitness monster. The practice itself is invigorating and relaxing. Lots of stretching, focusing on the lower back and shoulders (where programmers hold a lot of stress), and core exercises for balance and…organ health, I guess? I’m not totally sure why they have us do this.

Ok, that’s a lie, I think I’m pretty sure. Yoga teaches mindfulness through focus on the breath, grounding practitioners in a present moment that resurrects itself with each new inhale. You’ll want a good handle on mindfulness practice because it helps you recognize your thoughts and emotions while you’re having them. That’s an invaluable skill when you’re working at a fast pace and starting to get stuck. Mindful programmers debug faster because they can catch their poor assumptions as they speak their expectations to themselves. They code cleaner because they have the stillness of spirit necessary to sit back and write good pseudocode before leaping into class creation. And they work better with others because they don’t let their emotions dominate them during times of conflict.

Also, we’re more than just brains in jars. Most of the students here like to work really hard. That’s expected and encouraged. What gets lost in translation is the distinction between hard work and self harm. There is no nobility in skipping meals or depriving yourself of sleep or exercise in order to spend more time coding. You’ll end up burning out somewhere down the line, and it will cost you double the time you thought you’d been saving. Take care of yourself. Remember that your brain is attached to a body. And if you forget, there will be yoga to remind you of how painstakingly connected your brain and your body really are.

Expect pizza on Tuesdays. And expect the deep self-analysis that comes right before it. Engineering Empathy will ground you in reality and encourage you to speak your truth. These are closed-door group sessions where emotions can get raw and people can get uncomfortable. It’s OK. You can handle it. Just come prepared to be honest with yourself and your cohort-mates about how things make you feel. It may seem corny or unnecessary, but consider the companies where you’ll eventually apply. They interview a lot of people who know how to code, probably a lot of people who can code better than you’ll be able to after 9-15 weeks. When they consider you for employment, they’ll be margining how you’ll add to the culture. Are you a positive and welcoming person? Do other people do better work when you’re on the team? Can you look deep enough inward to detect and address your emotions as they shift, or are you constantly flying off the handle and needing to apologize for getting scared or frustrated or pissed off? Can you address a client with empathy and help them feel like their experience and knowledge is valid and valuable?

There’s not enough time to explicitly ready you for all these situations, but you’ll have a fair shot at learning some of the basics of emotional self-regulation and empathy, fundamentals that will allow an apprentice to contribute to a company’s culture long before they’re able to contribute to that company’s code. That’s value that pays dividends, and you’ll want to be able to provide it, so embrace the discomfort (at DBC, ALWAYS embrace the discomfort) and give each 90 minutes your best shot. 

A counselor, who helps facilitate the EE groups, is also available for half-hour private sessions funded by DBC. It’s up to you to sign yourself up if you feel you’d benefit from the space to get away and be totally honest with someone who will never look at your code. Personally, I think everyone should give it a chance at least once. I check in with the counselor once a week just to make sure I’m processing everything in a healthy way. There is so much to learn, so many personalities to get used to, so many expectations that get tested and torn down and rebuilt every day. You don’t need to go it alone. Use the first phase to reach out and seize every resource available to you. Especially the ones that take a minute to ask you how you feel and if they can help.

Expect to work with others. If you already know Rails and Angular and Node and Swift, and you only have experience working on projects alone, I’d still recommend that you try Dev Bootcamp. The relationships alone are worth the price of admission. Anyone can conceivably sit at a computer and teach themselves how to code, but DBC ups the ante by making you code next to a peer for more than two thirds of the time you spend on campus. This has benefits and drawbacks, and why the heck would you want to learn what they are in an environment where struggling with interpersonal issues could cost you a job? It’s safe here, so get used to it here. 

Get used to being the slow pair. Get used to asking tons of questions and admitting when you don’t understand the answers. Get used to feeling sad that you didn’t know more today and letting it drive you toward pushing harder tomorrow. Get used to watching someone better than you do something well, and get used to practicing their tricks and shortcuts on your own time while the lessons are still fresh. Get used to expecting their normal to become your normal someday. Get used to raising your expectations each time you code with someone strong. Get used to navigating, explaining your understanding of the code out loud and pulling up docs on your laptop to support the driver with researched answers to questions that come up. Get used to driving, plodding along as fast as your slow fingers will let you while your more experienced friend helps you make the most efficient decisions possible. In short, get used to something like being an apprentice in the real world.

And get used to being the fast pair. Get used to having your knowledge checked by a barrage of questions, finding new and painful humility each time your answers don’t quite match up. Get used to feeling sad that you went slower than your optimal pace today and letting it drive you toward pushing harder tomorrow. Get used to putting your methods where your mouth is and showing another person all your secrets, doing your best to lead by example without screwing up too badly. Get used to practicing your shortcuts and tricks on your own time before your workflow is under scrutiny and you share responsibility for someone else’s progress. Get used to being upset when your pair didn’t learn as much as you hoped they would, and asking yourself how you could have been a better leader. Get used to the art of teaching by asking questions, tracing back your own learning to guide someone else along until they arrive at the same understanding. Get used to driving, showing your pair how you do things and taking frequent breaks to make sure they understand why you did them that way. Get used to navigating, patiently (so patiently!) easing your teammate through the process you understood in minutes, even if it takes hours. Get used to getting the most out of your friend in a way that makes them feel like they matter, like they can contribute, like they made the right choice to be here. In short, get used to something like being a team leader in the real world.

Expect to work weekends. The atmosphere is different in here on Saturdays and Sundays, and you won’t want to miss it. Everyone’s laid back, but everyone’s focused. There’s a lot of joking and YouTube video sharing, and there’s also a lot of shop talk and review of the week’s material. It’s likely that you’ll enter your first few weekends with some unfinished core challenges from the week before. The weekend is your time to catch up or get ahead. You’ll have some weekend challenges to dig into, and your instructors will highlight the stuff from the past week that they think deserves the most attention. Redo lots of challenges. Build lots of toys and break them and rebuild them. Pair up with someone (or if you’re really feeling feisty, try grouping up) and work through a project from start to finish. Don’t skip the whiteboarding step, because the weekend is the best time to check your fundamentals.

During Week 2, my cohort had to build an app that generated winners and losers at random. Did we put our names into it and see who was the best one Saturday afternoon? You bet we did. Did we put real money down on the game and get really jealous of the winner? No comment. Rest assured that the weekends are awesome and you’ll want to be here to soak in that awesomeness. You’re trying to immerse yourself in code, why would you take a day off? if you want to relax at Dev Bootcamp, I think you’re better off timeboxing your day and finding a couple hours to work out or read or (ahem) blog multiple times throughout the week, rather than working like a fiend for five days and only having time to sleep and do laundry after the gong rings on Friday afternoon. 

Expect to ask for help. The pace is fast. The language is foreign. But you’re smart, right? Always the quickest kid in class, the best speaker in the meetings, the comfortable master of whatever past domain you lorded over, perched atop whatever throne you used to claim. Yeah, um, get ready to get blood all over your crown. Everyone here was the smart kid. Everyone. Chances are, you’re in for a rude awakening if you expect to coast on your own awesomeness. You’re going to struggle to keep up here, and you’ll struggle a lot less if you admit that you’re struggling. So just admit it and get some help.

There will be instructors, junior instructors, TAs, boots from the advanced phases, and brilliant peers all around you at all times. All that’s asked of you is that you raise your hand and expose your ignorance. People think the secret to success at DBC is an insane work ethic and ungodly hours, but that’s mostly true for those who would rather bang their head against a problem from 2 hours than ask an ignorance-exposing question and get help in 5 minutes. Your time is valuable and your money is valuable, and you’re trying to spend a lot of the latter to save a lot of the former, so why waste minutes being stuck when there are so many unstickers handy? 

I can’t stress enough how much my work improved after I started asking for help. My first week, I burned out in three days by trying to prove to myself that I was smart enough for this, as if I had signed up to know things rather than to learn them. My second week, I asked so many questions and signed up for so many mentoring sessions that I pissed off my pairs and got a warning message from an instructor telling me not to be a help hog. Week 3, I found my happy medium and I’ve never felt so relaxed about getting so much done in my life. The discomfort’s still there (are you seeing a pattern yet?), but now it’s more like a petulant but good-hearted roommate, and I get to enjoy this process way more than I did when I was killing myself trying to solve things better than my instructors. I’m not that guy. You’re not that person. Save time and a headache and be the one who asks for assistance when they need it.

About those mentor slots: there’s this great thing called Pairing is Caring, where coders in the community, many of them DBC grads, stop by for a few hours and help people understand things better. You’ll be able to schedule an appointment with someone dedicated to working on what you need to work on, and that 60-90 minutes will help you accelerate your learning in the best way possible. Imagine pairing with someone way faster than you who isn’t impatient and wants you to drive the whole time. It’s such an awesome way to gain understanding. You might even come away feeling really strong about something you thought you sucked at, like I did when I sat down to work at a challenge with a mentor and realized that all my initial instincts were the right ones for the project.

If you miss out on PIC mentors, take advantage of the weekend pairing board, where students from Phases 2 and 3 write their names and available weekend time slots. Take an hour on a Saturday (because you’re already here, right? Right???) and link up with someone who recently finished that nasty challenge you’re stuck on. Not only do they know one possible solution right off the bat, they probably remember their thought process and can help you along the same road. There are so many ways mentoring goes right and so precious few ways it can go wrong. Take the plunge. Get a mentor. You won’t regret it.

Expect to make friends. I came to Dev Bootcamp thinking about the things I’d need to learn and worrying about whether I’d have time to learn them all. I’ll leave Dev Bootcamp thinking about the people I’ve met and worrying about whether we’ll keep in touch. At tonight’s graduation party for the exiting Coyotes, a few of us started talking about how hard it normally was to meet new people, especially new people who weren’t like the people we already knew. And yet here we are, with our vastly different ages and backgrounds and experiences, and we’re all becoming really good friends. This place is not normal.

I’m not saying I’ve forged a deep bond with every single person in my cohort, but we’re all connected nonetheless, and there are already at least 10 people I’d make plans to hang out with even if we had to connect over something other than code. They say the acceptance process is so selective because DBC is looking for certain types of people they think will flourish in this strange environment. I believe that theory 100%. To a person, all my fellow Bobolinks have a strong drive to learn and succeed, coupled with this deep-seated optimism and openness to try new things. The whole space is like a resonating chamber for positive human energy, and it’s helped us form the kind of bonds that don’t happen by accident. Simply working together for three weeks doesn’t explain our level of camaraderie. This is something deeper, and it’s really special, and I’m grateful to be a part of it. Learning code alone gives you a sense of accomplishment. Learning code at Dev Bootcamp gives you that plus a sense of belonging. Get ready to sink into it, and stay wide awake so you can enjoy every second. Get everybody’s phone number in the first three days and create a DBC group full of the best buddies you don’t know you have yet.

tweet TWEET! #JustBobolinksThings

Expect to succeed. Always, always, always expect this. You wouldn’t have signed on for this journey if you didn’t believe in your potential or the program’s, so trust your initial thinking and see it through. Work every single day. Get done with every challenge you can and try to venture into the stretch challenges too. Stay late enough to finish what you started each day, and get home early enough to give yourself a real shot at a fresh start in the morning. And trust the process. You are good enough for this, and you’re ready enough for this, and all that’s left is for you to get started and see how much fun you can have while being awesome.

Repeating is not failure. Not knowing something is not failure. Screwing up on a challenge or assessment is not failure. Being the slow one in the pair is not failure. Failure is quitting, and it’s nothing else. And if you were planning on quitting, we wouldn’t be having this hypothetical one-way conversation right now.

So if you’re scouring the web trying to get more ready for this thing, I’m here to tell you that completing Phase 0 means you ready right now. Anticipating more outcomes feels safe, but safety isn’t where your growth zone is. You won’t get hurt by trusting the process and jumping right in. Just keep it simple. Pat yourself on the back for getting your submissions done, show up on time on Day One, and come expecting the ride of your life.

Dependency Infection

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

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

The Joker, that’s who.

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

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

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

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

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

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

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

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

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

Bobolinks, assemble!

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.