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.


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.

Pokémon (Learning) Ruby

I start Phase 0 in less than a week. I know so much more about programming now than I did a month ago. And the direct result of that knowledge is a deep and unsettling sense of not-knowing. The more I learn, the more questions I have. The more answers I find, the harder the questions get.

I’ve been taking study breaks to play Pokémon Ruby, because it’s been a while since I first owned the Elite Four, and because I like Mudkips, and because I’m learning Ruby in real life and I like symmetry. On occasion, a short break will turn into an hourlong Pokébinge and I’ll lose some valuable study time in the process.

Maybe by writing this down, I’ll improve that behavior.

See, it’s not the lost time that bugs me. What bugs me is the fact that I can be more willing to settle for virtual advancement than actual advancement, even when the requirements are almost identical.

The kid needs to catch monsters. I need to grasp lessons. Pokémon evolve with proper training. So does my understanding of methods and blocks and classes. My rival is a little tough but she drives me to maintain a competitive pace. Life is hard but it gets easier when I apply myself. And so forth.

Of course, games aren’t totally identical to life. If I could master real-life Ruby by walking in circles in tall grass and pressing A repeatedly, I would probably have several years of expertise under my belt by now.

And games entice with the promise of completion. Ruby Version has 386 pocket monsters, and I can measure my progress against that maximum. But I’ll never max out my programming knowledge. Ever. So I need to develop a motivation to learn that’s more subtle than “reach 100% and be done with it.”

That’s why Phase 0 can’t start soon enough. To date, I’ve been check listing my prep work, reading required texts and running through required exercises. When I finish something, it’s on to the next thing; when I finish all the somethings, I’m allegedly ready to dive in for real. There’s plenty of optional prep, but the core work follows the Pokémon model of skill development: if I can catch all the prep steps, I’m good.

But I can trigger that exact same reward center by grinding through a game I’ve already beaten, and I don’t like that at all. I’m hungry for a deeper, more nuanced level of engagement, beyond checklists, bigger than games. And it’s tough to satisfy that hunger before I know whether my preparation will hold up.

Luckily my days of toiling in solitude are almost over. Soon I’ll be an official part of a Dev Bootcamp cohort (let’s get it, July Firecrackers!) with real people as eager to learn as I am. So when I want to dive deeper into a concept than the checklist requires, there will probably someone I know willing to go even deeper than I do. And when I feel like I’ve fully understood something, I might be able to cement my mastery by explaining it to someone who needs some clarification.

Dev Bootcamp claims it can help students become better self-driven learners. I’m ready for that help. But in the meantime, I’ll settle for the warm comfy feeling of belonging to a group. I just need to keep the controller at bay for another week, and use that time to get control of the information I’ll be using this summer and beyond.

Beyond. Now there’s a scary word. I’ve been trying to keep my head down, look at just the next step, but I can’t shake this little voice in the back of my brain that constantly reminds me of how big this work is. I’m betting on myself here, betting that I can make the leap from semi-skilled jobs to a STEM career in less than a year. And I’m betting that I’ll be able to continue learning at a good clip after I’ve found work, building more skills and becoming more valuable, forever.

There are a hell of a lot more than 386 things to catch in this world. Is it crazy to want all of them? Probably. But if I don’t push hard, I’ll never get as much knowledge as I could have. I want the full stack, and I don’t even really understand what that is yet. But I want it.

Hopefully Dev Bootcamp will help me get it, by guiding me toward learning habits that are…


…super effective.

Sorry. I couldn’t resist.

If you can play Katamari Damacy, you can learn to write code.

Katamari Damacy is a game where you’re the son of a narcissistic king who makes you clean up after all his messes. You do this by running around a 3-dimensional field of clutter and pushing a sticky ball that grows as you roll up thumbtacks and dominos and cats and people and trees and bridges and eventually entire landmasses.

It’s kind of nuts. It’s also a lot of fun.

It’s also hard to explain to someone who hasn’t seen the gameplay. So here’s some gameplay.

Super Mario RPG and Dark Souls make it a close race, but Katamari Damacy is probably my favorite video game. It’s one of those “simple to learn, tricky to master, addictive as all hell” type games. It’s bright and colorful and kid/grandma friendly. The soundtrack is bananas. And there’s this weird indescribable feeling of power that flows through you when you roll your newly giant ball back to a previously visited area and see how far you’ve come.

Learning how to program is exactly like this. A week and a half ago, I was thrilled about using the most basic Ruby functions, a puts putz on a print stint. I’m still a noob, but making strings of text appear on the screen is beyond child\’s play now. (I mean, come on, I even know what that backslash is used for!) I’ve moved on to more esoteric concepts, and my thinking has evolved. Looking at more than 50 lines of code no longer scares me, and I have enough of a baseline to think of new concepts in terms of concepts I’ve already learned, instead of resorting to bad analogies and mnemonic devices to hammer lessons into my brain.

And maybe Katamari Damacy is like life in general, and maybe programming is like life too, and maybe this is all just one big transitive property post that means nothing. But maybe you like games (like I do) and think you’ll never be the type of person who could get into programming (like I did), and maybe you’ll read this and be inspired to stretch your limits.

Maybe, maybe not. Either way, I get to make a list now, and there’s nothing you can do about it.

Here’s why Katamari Damacy is just like coding.

  • You have to do the little stuff over and over before you can move on to the bigger stuff. In the game, picking up one battery doesn’t give you carte blanche to start grabbing mouses all willy nilly. No, you need to get a couple dozen batteries before you’re big enough. It took me a few days of messing around with booleans before I felt like I grasped them well enough to use them freely and predict what they would do. Understanding happened first, comfort happened later. Mastery hasn’t happened yet.
  • Sometimes growth is incremental, sometimes it comes in bursts. In the video above, there are brief moments where the whole screen goes a bit fuzzy  and a glissando plays; those are the moments when you’ve “leveled” in size to the next milestone. Fifty centimeters, one meter, twelve meters, a hundred…you hear the sound and see the blur and you know you’ve grown. This can happen in programming, too. Once you grasp how an if/else statement responds to a language’s top-to-bottom processing order (aha, I need to set the most specific condition FIRST!), something shifts inside you and you’ve reached a new depth. But you’re still growing even when there’s no chime to remind you how awesome you are. In the game, and in programming, growth makes it possible to take on bigger and bigger challenges, even between the epiphanies. The growth is always happening, especially when you’re not consciously aware of it.
  • Sometimes hanging back helps you blast forward. The person playing in the video didn’t need to spend so much time circling around that tiny first neighborhood. They were big enough to ramp up to the larger city within the first minute or so, but they stuck around and grabbed everything they could. Then, when they moved on, they were able to spend much less time picking and choosing which objects were small enough for them to handle. Sometimes I need to slow my learning process until it feels like I’ve dawdled on one topic for too long, but the payoff is usually a quicker and smoother leap to the next idea once I’m done.
  • Sometimes you need to just press on and scale the wall. Ok, so maybe that last point isn’t always true. In the game, if you encounter a wall that is less than double your height, you can scale it like Spidey. All you have to do is press on into it after it’s stopped you, and trust that you’ll keep rolling. When I’m learning things in order, I frequently reach this moment of truth: “Oops, this can;t be right, I feel like an idiot. I mean, I got the last thing, but this seems miles harder. How am I supposed to tackle it?” And the answer, invariably, is to press on into the problem and trust that I’ll keep rolling. It’s almost like coding is a game that rewards the people who can see past a moment of zero motion and understand that progress is still being made.
  • Stuff will knock you off course. Until you’re big enough to snatch up the islands on which Katamari Damacy’s world is built, there will always be something on the map that is as big as you or bigger. And moving. And in your way. That’s part of the challenge that makes the game fun. In my new life as a programmer-in-training, time and effort are the ingredients of my stickyball. And there are always bigger things in my life that take up time or expend effort. By the end of the day, it’s usually a struggle to get into a lesson and make myself a stronger programmer. But I’ll only win the game if I drive through the challenge and commit my time to focused learning. Every day. No matter what.
  • The controls feel weird at first, but you get used to them. You play Katamari Damacy by working two thumbsticks at once, pushing them in the same direction to roll, opposite directions to turn, etc. It feels like controlling a tank, and there’s definitely a learning curve. But if you stick with it – and you’ll want to, because it’s all so colorful and fun in there – you’ll get the hang of the control scheme and gradually become agile in the game world. The gamer in the video is pretty good, adjusting the camera and making quick adjustments between smooth turns. That’s not overnight expertise. When you first crack into Ruby, the precision of the language is sort of baffling, from syntax and indentation conventions, to “=” vs. “==”, to that whole “computer does only and exactly what you tell it” deal…it’s like an alien world. But if you stick with it – and you’ll want to, because it’s all so limitless and exciting in there – you’ll get the hang of the language basics and gradually become more capable.
  • Your superego will rarely think you’re good enough. Poor Prince. Every time he rolls up a ball and presents it to the King of the Cosmos, he’s met with scorn or indifference. Well, almost every time. On occasion, the player knocks a level out of the park and wows his in-game dad in a moment that rivals the ending of Field of Dreams for its ability to produce hot man-tears in this blogger. But those are the exceptions that prove the rule: The King wants RESULTS, dangit, and he’s not easy to please. My own brain and its judgments are like a little King I’ll have to live with if I want to code well. If I can’t recognize that the inner voice screaming “NOT FAST ENOUGH” as I type lines on the screen is just a flamboyantly petty narcissist in Shakespeare pants*, I’ll start listening to my own doubts. And then I’m in trouble.
  • There is no way to beat the game. Sure, there are a finite number of levels, and a credit roll, and a maximum number of unlockables to unlock. But there are also time trials, and max size challenges, and friends to play against. And sequels, too! I don’t think there will ever be a point when I’ve “finished” learning how to program in any given language. Ever. There are too many frontiers to explore! Not to mention all the other languages out there, each equally deep and nuanced. And SQLs, too!

So, if you think you can’t code, you should head over to and click on one of the languages to learn. You’ll be surprised at how easy and accessible the basics are. It doesn’t hurt to try.

But if coding really isn’t for you, you should at least sniff around on Craigslist for an old PS2 and grab a Katamari game for it. The game’s that good. There are also Xbox 360 and PS3 variations. And one for iPad.

I own most of them. If you learned on thing today, it’s that I care about Katamari Damacy way too much.

Til next time. I gotta go figure out how to write Procs. They’re like blocks, but you can save them. Does that sound like Sanskrit to you? Two weeks ago, we would have been in the same boat.

Two weeks from now, you could be building a whole new skillset. Think about it.



*That’s just my superego, though. Your mileage may vary.