When these two sides of my nature are in harmony, inner peace is the result. When they are in competition, the result is inner turmoil.

Because my current prose proficiency is greater than my current coding proficiency, there have been times in the past when the less glamorous tasks involved in writing code (e.g. debugging & diagnosing updates that break your app) would cause me to question the decision to devote so much time and energy to a second, extremely cognitively taxing craft.  But today I had a breakthrough:

Writing code and writing fiction are really just two ways to solve problems…

Two ways to tell a good story.

Two ways to entertain.

Two ways to educate.

Two ways to inspire.

It’s been said that, “Writing is thinking on paper.”

Likewise, coding is thinking on a computer / network / mobile device / in the matrix.

~

In every career track you will find people who’ve been obsessed their whole lives with the skills and craft involved in their profession–and seemingly nothing else.

I am not one of these people.

But as of today, I no longer envy the single-minded specialists. I respect them, sure (I respect everyone). But now I’ve found a new appreciation for my inner compass. And to celebrate, I’m calling bullshit on the following aphorism–a smug quip propagated by ass-hats, that sadly, has stunted the growth of many a budding Renassaince (Wo)Man:

Don’t be a jack-of-all-trades and a master of none.

While I can appreciate the cautionary tale contained within this advice (i.e. don’t be a dilettante; learn and appreciate the unique rewards that result from hard work and mastery of a skill), the danger–especially for young people–is that if they hear this quote, and happen to be a well rounded, passionate individual with many pursuits, they might start to feel like there’s something “wrong” with them…like they can’t be a “success” in life unless they eliminate extraneous pursuits that bring them joy in favor of a monk-like devotion to only those skills their culture and society celebrates.

There is a better way: recognize that “All Is One.”

Clear thinking on paper , is clear thinking in a text editor, is thinking clearly.

Empathizing with your reader, is empathizing with your end user, is being empathetic.

Getting wisdom past a student’s rational filters in the form a story, is refactoring a peer’s code to amplify their intent and imparting wisdom along the way, is being wise.

Writing is writing. Coding is coding. Writing is coding.

]]> http://jeremyleejames.com/dev-bootcamp-day-04-i-write-for-me-i-write-code-for-you/feed/ 0 http://jeremyleejames.com/dev-bootcamp-day-03-freakout-geeks-and-complete-people/ http://jeremyleejames.com/dev-bootcamp-day-03-freakout-geeks-and-complete-people/#comments Thu, 04 Oct 2012 07:42:30 +0000 Jeremy Lee James http://jeremyleejames.com/?p=1236 Soft skills are not software. Soft skills help you build software.

Soft skills (or what Shereef, aka “Fearless Leader” refers to as “meta-skills”) refer to  everything about you and your way of being in the world that influences how well you work with others.

If you couldn’t tell the difference between the last two sentences and two Xanax washed down with a shot of bourbon, that’s only because you weren’t at DBC headquarters doing the hard inner work involved in developing soft skills.

If you had been there, just hearing the term “soft skills” would illicit an emotional response akin to french kissing a rattlesnake.

A little off-topic, but worth mentioning…

As Instructor Steve was describing the difficulty many geeks have communicating to non-geeks, I experienced a sudden wave of deja vu: the phrase “Object Oriented Programming” was uttered, and in an instant, I was transformed back inside the lucid dream I had prior to even being accepted to Dev Bootcamp. In the dream, I was sitting in the same stool-height chair, noting internally that the brick walls were of a similar texture as the brick walls in my apartment in LA, and feeling grateful for being accepted into such a life altering program. The day after I had this dream, my friend Kelly in LA asked me if I thought I would be admitted to the program. I said “yeah, I think so,” and proceeded to tell him about the dream which could have only been taking place inside the DBC offices (which I’d seen a picture of on the web).

Weird.

Anyway–soft skills / meta-skills / how to freakout geeks and complete people… Here’s the thing: I can’t talk about the best parts. It’s private. You had to be there.

So instead, assuming I had more gas in the tank (which I don’t), I’d like to talk about this weird method for deriving recursive functions from a set of repeating data points that will solve and/or generate the full series you’d like to generate, i.e. the Fibonacci series, or the algorithm for calculating a factorial.

Next time, maybe.

In the words of the great Eddie Vedder: “Jeremy’s Spoken,” and he says night-night, sleep tight; don’t let the Socrates bugs bite!

My roommate, Boot D (a nickname to protect the innocent), paired with me today, Day 02 of Dev Bootcamp – Fall 2012, in the Year of the Dragon.

Quick drag(gressi)on:

• 2012 is the Year of the Dragon on the Chinese calendar.
• I was born in a previous Year of the Dragon (1976).
• Three weeks ago I got a rather large Asian dragon tattooed on the side of my calf.
• DBC Headquarters is on the edge of Chinatown here in San Francisco, and dragons are revered in Chinese culture.
• Today it was hotter than a herd of dragons roasting weenies at Burning Man.

Anyway, Pair Programming.

In a word: niiiiiiice!

What’s so nice about it? Many, many, things. But I want to focus on only one aspect here today, and that is the optimum combinations of pairing among programmers with distinct , varying levels of experience / proficiency / language-specific familiarity / general programming knowledge. For the sake of simplicity, I’ll lump these aspects all together and call the result “Code-Q”.

In a given programming pair, there are three possibilities. A coder could be paired with someone who currently:

1. has a lower Code-Q
2. has about the same Code-Q
3. or possesses higher Code-Q

The question is then, what are the developmental implications for a given coder for each of the three combinations? in the context of the following objectives:

1. developing facility with the syntax of a new programming language (e.g. Ruby)
2. deepening and solidifying their current conceptual understanding of the day-to-day use of a programming language
3. transcending their current level of proficiency through learning new and possibly more elegant approaches to programming challenges

Granted, this is after just two days of pair programming, but here are some conclusions I’ve made thus far:

Pair Programming Principles To Prosper

If your goal is to increase your comfort level and proficiency with the syntax of a new language, then pair with a programmer of similar Code-Q.

Because you will both be eager to cover as much ground as possible, your rate of progress will be much higher than if you A) attempted to assist a greenhorn beginner, or B) if you struggled to understand the elegant, esoteric instructions issuing from the pizza slot  of a seasoned pro. In the case of A) you would lack the necessary vocabulary and clarity of thought to convey the principles at play in the problem domain to your less experienced peer. Conversely, in scenario B) you wouldn’t have learned enough “rules of the game” to appreciate when to break them or when to play a different game altogether.

When your objective is to crystalize your knowledge of a programming language, pair with a programmer who currently exhibits less Code-Q than you.

The ability to explain complex and/or subtle programming principles in simple, straightforward, and easy-to-grok language will force you to deepen your own understanding of the tools offered by said language. Pairing with someone with a similar level of Code-Q would hinder the re-conceptualizing and refinement of what each member of the pair already knows–in part because the pair would tend to reinforce each others’ (possibly bad) habits. Likewise, pairing with a coder of significantly higher Code-Q tempts the less experienced coder to seek approval and to demonstrate that they can “hang” with the alpha-geek by only relying on syntax and techniques that they are the most confident with–thus neglecting precisely those areas of development that would benefit most from a beginner’s on-the-nose style questioning.

To transcend a hard-earned and long exhibited level of programming proficiency, pair with an old pro with strong Code-Fu & high Code-Q.

Because programming practices and coding habits tend to become ingrained over time, discovering new and potentially more elegant ways to tame the machine almost always requires a more experienced guide.

Which brings me full-circle back to my new friend and first pairing partner, Boot “Going The Distance” D. Our mutual Code-Q is similar. He certainly has strengths that I don’t have, and perhaps vice-versa, but with respect to the goal of mastering the Ruby programming language, we’re both far enough from Nirvana to be great companions on the journey. When I hit a wall, he has a sledge hammer. And when he zones out, I’m often getting into the zone. Anecdotally at least–this pairing combo definitely supports my first recommendation above on the topic of pair programming.

If you’re a new practitioner of pair programming, or if it’s all old hat–either way–I’d love to hear your thoughts and tips on this valuable software development practice.

Jeremy Has Left Building

What time is it? Bed time! What time is it? Bed time!  I said, what time is it?

return “Bed Time”.upcase

Inhale, exhale. Rollover, dream. Tomorrow, it’s go-time.

717 California Street, here we come.

The six of us walk single file up Third and across Market onto Kearney. The final two-hundred yards to headquarters it’s straight up hill. This is called foreshadowing.

If you’re thinking mock-turtle necks and polo shirts with popped collars, you need to check yourself. This isn’t college, and we’re not undergrads. We’re 50+ geeks with laptop bags, bikes, and two-day old beards. We’re from both coasts and many countries. We’re job quitters, difference makers, and soon to be Version 2.0 of our former selves.

Cue the techno.

Yes, I said techno.

And it’s loud. The locked door we’ve been milling around opens promptly at 9:00, just like Shereef said it would. I’m the first one through. Adrenaline drops into my gut like a corner pocketed eight ball off the break. My ears ring with a chorus of high fives and hell-yeahs. I feel like I’m walking the corridor into a stadium–like I should be doing high-knees through the gauntlet on game day.

And then our fearless leader gets down to business and talks about our “contract.” Finally, reality sets in…not! It only gets better:

• “Be here 100%”
• “Have integrity”
• “Love and kindness”

You might be tempted to call this stereotypical San Fran-silly crystal-gazer bullshit. But then you wouldn’t be a boot.

These aren’t just platitudes. These are deeply held beliefs. Put forth by people who care. Twenty-somethings who turned their backs on corporate bureaucracy; thirty-somethings who did a gut-check and cashed their last check just to be here.

I have to make the most of this opportunity. We all do. So how?

There’s an app for that: “Do. Share. Reflect.”

• Do the work and do your best.
• Share what you’ve learned so that you really learn it.
• Reflect on what you can do better tomorrow.

And most importantly: “If you want to go fast, go alone. If you want to go far, go together.”

Eventually this journey will make me weary, but I know I’m not the only one who will have trouble sleeping tonight.

And over there: a seed that has grown in rich soil. A young tree with thirsty roots and sturdy branches. His leaves track the light of knowledge; his bark not yet scarred with crude hearts and summed initials, carved. He is also a boot.

And beside the first man, yet another: A hungry inquisitor, intoxicated–not with the noir of narcotics and loss–but with opportunity and hope and zest for a new life in a new land. This boot is made for walking–not over you, but with you.

Then there is the boot who seeks to make instead of manage; to polish code instead of PowerPoints. He’s been good in rooms brimming full of the best. Now he will get even better.

And to his left, a new friend guided by fascination, lead by a love for learning. His joy is contagious…a fast friend with a French accent.

They are not alone…

Outside these walls, drawn to the same city: fifty other boots in this fall of ‘012…treading the same path, sharing the same passion, daring to make a difference.

I am proud to be among them.

…Be more effective than efficient.

…Be proactive instead of whining.

…Be loved instead of “right.”

How ’bout you?

Life is what happens when you’re busy making other plans. ~John Lennon

This certainly holds up in my experience. Case in point: in my most recent Dev Bootcamp – Fall 2012 (DBC) update, the plan was to:

1. work through vimtutor again (to brush off my VIM rust)
2. finish Learning Ruby The Hard Way (LRTHW), and to
3. start reading ELOQUENT RUBY until I get to a point where nothing looks familiar, or I’m comfortable enough to move on to Michael Hartl’s Ruby on Rails Tutorial.

Boots Get A Boot To The Butt Sooner, Rather Than Later

Although I did get through vimtutor, I’m only on Lesson 38 of LRTHW, and just a few chapters into ELOQUENT RUBY. It hasn’t helped that I figured out how to stream the BBC feed of the Olympics, or that a client website ran past deadline.

Or, that our benevolent instructors at DBC surprised us with our first batch of prerequisite homework. In a nutshell, we were to:

• ensure we can type 40+ wpm,
• find our way around the command line,
• grasp basic Ruby concepts,
• and understand the essentials of building a webpage with HTML and CSS.

Good stuff. For me the highlight was definitely the Ruby Monk primer. It’s very good, and it seems to teach more “idiomatic” Ruby than LRTHW (which started life as a port of “Learn Python The Hard Way”).

In total, there will be 50 hours of homework we’ll have to complete before showing up, assigned in batches. I’ll probably end up devoting around a hundred hours to it, though, because I’m attempting to be as thorough as possible while learning the fundamentals. I’m also trying to adopt a different workflow than what I’m used to by relying more on git, SASS, VIM, RSpec, and other tools and frameworks favored by the Ruby community. Any time you learn a new way of doing things, there’s an adjustment period.

Establishing A Hacker House In San Francisco

Finding someplace to live this Fall was something I’d planned to put off until just a few weeks prior to DBC. Because I wanted something inexpensive and within walking distance of DBC HQ, I figured I’d target room shares and sublets on Craigslist. These come up all the time when someone needs to travel on short notice but can’t break their lease; however, they don’t usually come up three months in advance—which is why I’d planned to wait.

Enter the proactive Canadian, Andrew Fowler. He suggested on the DBC Facebook group that we try to form a “hacker house” with as many boots rooming together as possible.

Sold.

And over the course of three days we made it happen: With lot’s of hard work and collaboration, twelve of us (so far) will be staying in two, 2-bedroom Archstone South Market apartments. The rent comes out to $1,050 per person, per month, which sounds high, but actually isn’t too bad for San Francisco. Bottom line, I’m really proud of my new roommates; their ability to coordinate bodes well for the pair programming and team projects at DBC. It’s also nice not to have to worry about where I’ll be collapsing into the fetal position each night after 15 hours of coding.

HOUSING TIPS: if you need short-term housing in San Francisco, you might have better luck going with an agency that specializes in business travelers and relocations (like Executive Suites, who works with Archstone and other upscale apartments). That way you can get a more flexible lease. Of course AirBnB is always a possibility, too, but if you need to stay over three weeks, your options there will be limited. When pooling money, nominate one person to collect funds via PayPal or Crowd Tilt, and then create a shared Google Spreadsheet to track who’s put up money, how much, and who will be rooming together. That’s what worked for us. Bonus: no credit checks or associated fees.

Time To Become A Machine

I’ve got a week in Hong Kong coming up to be a tourist, which will eat into the time I have for the next batch of pre-DBC homework, but will help me recoup from a crazy-busy year of building websites. On the plane over I’ll work through the excellent Git Immersion tutorial to knock off my git rust. Then, when I get back to the U.S. it’s head-down, fingers on the keyboard, and coding like crazy until October. Depending on how much time the next round of assignments requires, I hope to complete the Hartl Rails tutorial and finish reading ELOQUENT RUBY, in addition whatever our instructors throw my way. Beyond that, I’ll just have to play it by ear.

A 50% Increase In Enrollment

One last bit of news: It turns out that 60 people were accepted into the fall class instead of the advertised forty. I’d prefer a smaller cohort, if I’m honest. Although our fearless leader, Shereef, assures us that the teaching quality will be better than ever—and I believe him—having that many students is less than ideal. Given my fascination with learning, pedagogy, and Social Psychology, this could be a topic I’ll expand on in later posts. For now, I’ll just have to trust that our instructors know what they’re doing, and focus on what I can control: i.e. how hard I work, how well I support my fellow boots, and where I choose to focus my attention.

The biggest motivation for this word count and progress tool is how much easier it is to finish when you write every single day.

Writing every single day without fail; i.e. building some momentum.

The lie we tell ourselves is: well, if I just skip today, I’ll make up for it the following day by doubling my word count.

Never. F-ing. Happens.

Because that’s not the way the brain works.

It’s not merely the slow but steady accumulation of words that writing every day makes possible. Writing every day also minimizes time devoted to reviewing what you’ve already written in order to keep the story fresh in your head. And having the story fresh in your head inevitably leads to faster production. The same is true for maintaining a consistent tone for all your POVs, and for sticking to a nice rhythm to propel your readers forward in the plot.

It’s been said that a novel-in-progress is like a boulder. It takes a lot to get it to budge, but once it’s rolling, it’s not too difficult to maintain forward momentum with a steady page-or-two-per-day push.

This boulder metaphor also goes a long way toward explaining why there are so many half-written novels that never make it to THE END. The more pages that have accumulated before you lose momentum, the heavier the rock. And if you simply try to press on from where you left off (without first investing the time to re-read), then you risk an inconsistent voice leeching into your prose.

In my case, for instance, I’ve got a 50,000+ word manuscript that I’ll have to re-read from the beginning before I attempt to re-establish a groove. Instead of knocking out a reasonable 850 words today, I’ll be reading late into the night just so I’ve got a shot tomorrow at finishing another scene. It’s painful—more so, writing about it here. I’ve been writing this book for an embarrassingly long time now.

But shame, like anger, can be a powerful motivator…

So let’s toast: to momentum, and to picking up the pen again no matter how many times you drop it. Cheers!

UPDATE: As of February 14th, I have over 62,000 words. Momentum works!

Why go full-on geek? you may be asking, when there are so many slick graphical text editors to choose from?

It’s really an investment in my future productivity. One of the basic principles of VIM is that when editing text, you’re fingers should remain as close to the “home row” as possible. If you can touch type, this is nothing to sneeze at.

Choosing VIM will have (hopefully not too detrimental) consequences for me when I arrive at Dev Bootcamp. In the prep material I’ve received from headquarters, they specifically encouraged us to use TextMate, because that’s the editor of choice at Dev Bootcamp HQ. (Probably in no small part due to its popularity among Ruby and Rails hackers.) Fair enough. And I actually do like TextMate. But after a week long trial run with both VIM and TextMate, I found myself more excited by the possibilities of VIM and its modal way of doing things.

It’s more of a gut thing than a rational “this is better because…” type of decision. It just feels right, right now. Plus, I’m an aspiring novelist and I type fast. Even though I use Scrivener for about 90% of all the fiction writing I do, if I ever get really, really good with VIM, then I can definitely see how it would be a big productivity win to use it for composing and editing fiction in addition to hacking code.

“Simple tools, mastered,” is a mantra that resonates.

Granted, my primary objective is to learn Ruby, and VIM is not Ruby, but it’s a tool I’ll be using to compose virtually every line of code I write for the foreseeable future.

Onward.

I found the following resource very useful for getting setup with VIM: Coming Home to VIM by Steve Losh. You’ll know all you need to know about making VIM more useful after reading it, and then some.

One tip I’m keeping in mind as I get everything setup, is to note the language of choice of the people I’m learning and borrowing dot files from. My goal is to learn Ruby and Rails, so I want to be careful not to copy configurations from folks that were optimized for a Python or PHP-centric workflow. For example, Steve is a Python guy, and he’s remapped the <tab> key to put in 4 spaces; the Ruby community uses 2 spaces. Be sure to look for that if you make use of someone else’s .vimrc file (and if you don’t know what a .vimrc file is, you will after reading Steve’s excellent article).

Prerequisites to VIM

By the way, I’ve already gone through a lot of setup on my new MacBook Air prior to installing VIM and MacVim (some of it prerequisite to the task at hand). I found this ThoughtBot resource: 2011 Rubyist’s guide to a Mac OS X development environment extremely valuable for configuring a new Mac OSX Ruby dev environment.

I should warn you, tweaking your setup is not learning. In the time between starting a draft of this post, and hitting “Publish,” I’ve already fallen into a few rabbit holes. It helps to remember what my objective was when I set out, and today that’s: get MacVim installed on my new Mac (along with a few key workflow plugins), and configure it just enough to be useful and pleasing to the eye...

…and several hours later, mission accomplished. But not before I explored the following:

• Oh My ZSH
• Trail Map by ThoughtBot (a really cool social curriculum experiment for learning Ruby-centric web development, and something I might use to modify my own pre-bootcamp journey)
• My Extravagant Zsh Prompt by Steve Losh

Next Steps:

1. Type vimtutor at the command line and go through it all again—but this time, create an Anki Deck for VIM as I go along (I’ve already started this and will share more details when I get some time). Update: I’ve finished the Anki Deck called “VIM Beginner” but the Anki website is being rebuilt and I won’t be able to share it for another week.
2. finish Learning Ruby The Hard Way (I’m on exercise 14, and I’ve also started building an Anki Deck for Ruby as I go along)
3. start reading ELOQUENT RUBY until I get to a point where nothing looks familiar, or I’m comfortable enough to move on to Michael Hartl’s Ruby on Rails Tutorial