serial milk

I CRAVE INFINITE KNOWLEDGE!

[serialmilk]

Install Clojure

Clojure is a wonderfully simple language, and you're going to love it

Since the Climate Corporation is big on Clojure, I decided I’d like to mess around with it a bit. Here is a simple set of instructions for installing it.

Install java if you don’t have it. The simplest way to do this is open up the terminal and type:

    java

If it isn’t installed, the message “No Java runtime present, Requesting install.” will appear. Follow the steps and let software update do its thing.

Download Clojure here.

Unzip the file and cd into the directory. To confirm that it worked, enter the following into the terminal (replace YOUR.CLOJURE.VERSION with whatever version you downloaded):

    java -cp clojure-YOUR.CLOJURE.VERSION.jar clojure.main

A clojure repl should open up.

To install Leiningen, download the script here

Move the file to your /usr/local/bin

    mv ~/Downloads/lein.txt /usr/local/bin

and rename it

    mv lein.txt lein

Run it! lein It should install, and now you can learn about how it works:

    lein help tutorial

References:

http://clojure.org/getting_started

http://leiningen.org/#install

Get started with Clojure

[serialmilk]

Post DBC Reflection and Next Steps

I recently watched Indie Game: The Movie, a fantastic documentary that follows the story of three indie game developers and their projects. One of the teams, months out from their deadline, is presented with an opportunity by Microsoft- their game Super Meat Boy will be featured on the front page of the Xbox Live Arcade marketplace if they can finish it by the end of the month.

The pair go on an insane sprint, working 16-18 hour days for the entire month to take advantage of the promotion. Finally, completely exhausted, they make the deadline. Microsoft screws up and doesn't get the game up until the middle of the day, and still it manages to blow all previous sales records out of the water, selling over 20,000 copies in the first day.

On release day, the documentarians ask both team members how they're feeling now that the project they've been working on for over two years is finally, in a basic sense, complete. Both members are completely dazed, but one manages to articulate a sense of emptiness now that they've crossed to the other side of the finish line, he expresses a longing for the pressure of the sprint. Despite all the anxiety and the challenge that went into producing Super Meat Boy, the team go back to work on a new project shortly after.

It's been almost a month since DBC ended, and I've been avoiding writing a post because I'm having a hard time accepting that it's over. Hiring day was an incredible experience where we finally got to apply everything we've been working on to the 'real world', but at the same time it also signified, definitively, that the program was over. I identify with the game developer who felt a sense of emptiness at the end of his project- you pour so much of yourself into something and then suddenly it ends. I know I'm entitled to a feeling of pride and accomplishment, but mostly I long for a return to the pressure of the sprint...

...as such, I'm excited to announce my next step: on Monday I'll be starting as a Software Engineer at Climate Corporation, a mid-size startup that helps businesses adapt to climate change using global weather simulation modeling and local weather monitoring systems. Let the sprint resume.

[serialmilk]

On Friday we had our second 'wax-on-wax-off' session, in which we're given four forty minute rounds to get as far as possible on a project with a different partner each time. The first time we did this, our assignment was tic-tac-toe, and at least for me, I was too much of a novice to get very far into the app (although I did learn a lot about testing). This time around, however, I managed to build an entire functioning todo web app two out of four rounds. Oh the difference a few weeks makes!

During our debrief, it seemed like people still had a lot of questions about how to get this app working. I felt like I'd developed a really good approach to putting it together that lent itself to an understanding of what was actually going on: I used Rails' built in error messaging to essentially tell me what it needed me to do next (someone coined this 'error driven development'). So I offered to lead a 'breakout' session on my approach.

The video above is a 50 minute screencast of the presentation I gave to 25 or so fellow boots. The actual act of screencasting slowed down the computer quite a bit, so apologies for the long delays. I also started with a disclaimer that's worth repeating here: while I understand how all of my code functions, the best explanation I have for a lot of the actual implementation on the back end is still "magic". But that's changing slowly but surely. As always, I'm open to feedback! Enjoy!

[serialmilk]

Decisions, Decisions.

On my way home from the office tonight, five and a half weeks into DBC, I suddenly realized that I'd made a serious decision about what to do with my life. For some people, that concept may sound absurd. Maybe you've been aware of your trajectory for years and have deliberately pursued a logical set of goals and opportunities to support your ambitions. But for myself, and many other people I know, that process hasn't come so easily. I got to thinking about decisions.

A major personal barrier for me when I'm faced with a decision is the fear of closing off one path in favor of another. If I decide to pursue coding as a career path, does that mean I forfeit my capacity to actively pursue my other interests? This particular brand of Fear Of Missing Out (FOMO) has affected non-professional areas of my life too- particularly my personal relationships, and the result is paralysis- an inability to move forward in any direction.

Over the weekend I sat down with a friend who was facing a tough decision about a relationship. In typical fashion, we hashed out the possible outcomes of continuing versus ending the relationship, and like so many of these tricky choices, an obvious path wasn't clear. At first, we resolved that because the choice wasn't obvious, the best thing to do was give it time and see if a best choice might emerge, but the more we talked about it, the more that option began to seem less ideal. Leaving the decision in limbo accomplished nothing- no questions were answered, no choices realized, and the general outcome was emotional gridlock. If nothing else, she would be faced with an even harder choice to make down the line.

As we continued to talk, wisdom suddenly materialized out of thin air: make a decision. I encouraged her to make a decision- any decision, but just to make one. Make a choice, stick to it, and learn from it. See what happens. Until she made a choice, the situation became only less clear. If she made a choice, even if it did end up being the wrong one, a lesson would be learned, and forward motion would be achieved.

Choices have consequences. That's a basic law of emotional physics that we're all aware of, and it's not my intention to diminish that fact. Choices can have extremely serious consequences, and if a choice needs to be made, it should be made carefully. That being said: choose one. And don't be afraid to be wrong. The impact of each choice is like the stroke of a chisel that forms the uniqueness of our individual lives and experiences, and a block that's marred with nicks and scratches will always be more vivid and fascinating than a pristine and indifferent pillar.

The decision of whether or not to join DBC was momentous for me. When it came time to choose, it was like approaching my statue with a chainsaw rather than the delicate tools I'm comfortable with. And yet, unlike so many other intimidating decisions I've had to make, it came easy. To be honest, I haven't figured out why. Maybe that's an indicator that this is the 'right' path for me, or maybe my circumstances at the time wholly predisposed me toward making this choice. Maybe approaching such a huge decision with wholehearted commitment and confidence allowed me to perceive things from a completely new perspective. Regardless of why, it feels incredible to have made a choice at all, and doubly so that it's working out.

Maybe it wouldn't feel as good if this had turned out terribly, but I like to think that, as I've learned from the wrong decisions I've made in the past, I'd be able to look back and take satisfaction in having made a choice at all. I challenge anyone who's taken the time to read this to act on a choice you're facing. And for those of you who appear to move forward with unfailing confidence, share your secrets!

[alancohen-deactivated20160627]

Don’t even try to build startups. That’s premature optimization. Just build things that seem interesting. The average undergraduate hacker is more likely to discover good startup ideas that way than by making a conscious effort to work on projects that are supposed to be startups.

PG (via alancohen)

Wisdom.

[serialmilk]

Not so shameless self-promotion: Introducing the Daily DBC Digest

Is you or someone you love interested in learning to code, but just can't seem to find the resources to support the habit? Well no more! Introducing the Daily DBC Digest, a crowd-sourced semi-weekly newsletter of the best resources to aid your learning experience, curated by 55 fellow developers in training.

Every day, a fellow boot and I put together 5-10 resources to support your learning on a given topic- from TDD to SQL- and mail them out to you, FO FREE! So sign up, tell your friends to sign up, then make a new email account and sign that one up too, because this thing is so rich with content you'll want to subscribe at least twice.

LINK LINK LINK LINK LINK LINK LINK LINK LINK LINK LINK LINK LINK LINK

[serialmilk]

Code is poetry, not prose

I got to enjoy my favorite kind of learning moment today: when an innocent, seemingly simple question turns into a journey, which leads to a revelation. The revelation is that code is poetry, not prose.

I was really dissatisfied with code I wrote at the end of last week for a flashcard program (the technical term is 'flashcardinator', apparently). The challenge was designed to enhance our knowledge of RSpec, Ruby's popular testing framework, as well as our understanding of test driven development (TDD). TDD's basic idea is to write a failing test for an aspect of your program before you write any code, then get the test to pass as simply as possible, then look at how you can refactor your methods into better code. That idea makes sense to me, and seems important to me, so I decided it would be a good use of my time to revisit the challenge and see if I could do it better.

In order for TDD to be effective, you have to increment your code by tiny steps , and recognizing my own tendency to want to plow ahead, I spent all morning explicitly focused on writing sensible tests, getting them to pass with the simplest code possible, and thoroughly considering my refactors.

After lunch, I approached Jeffrey (one of our instructors) with what I thought was a simple question. For every challenge that's involved printing and reading data to and from the command line, we've had a ton of trouble figuring out effective tests. There are all sorts of different poorly documented workarounds, but they're all hacks that carry a nagging feeling that if you have to resort to these measures, you're probably doing something wrong. I thought I'd figured out a structure that would allow for easier testing, but was stuck on a design choice I didn't know how to resolve.

I posed my question to Jeffrey, expecting a simple answer. That is not exactly what I got.

He looked through my code, starting from where I was stuck, and began to completely dismantle it, piece by piece. I was completely flustered, and I even broke into a sweat (granted, that's my body's response for basically any emotion). I was totally put off- I'd spent all morning believing I was doing a great job on this challenge my second time around, only to be shown that nothing was where it belonged, and my understanding of what the structure of this program should be was utterly flawed!

Eventually I recovered from the shock, and that's where the true magic began. I had the huge privilege of sitting with Jeffrey for close to an hour working to understand why certain methods should belong in certain places, what parts of different classes should and needed to be visible, how the code I had written was implicitly making hazardous assumptions, and how the concerns of my classes were totally mixed up. I know I've only been doing this for 3 weeks (and one day), but it was completely amazing to see what I thought was good code be transformed before my eyes into what is actually good code. The learning was immense.

To return to the title of this post, code is poetry, not prose. Rather than paste my incomplete code below (code and explanation to come upon completion of the challenge), I consider the following to be an analogous example. Take the idea of courage, and think of how we might express it. You could go with the following:

Courage is the ability to confront intimidating circumstances with confidence, and to have the power to act even if you're afraid or uncertain. You can be physically courageous, for instance if you're jumping off something high, or maybe confronting an aggressive animal or human. You can also be morally courageous, like when you speak up on behalf of yourself or someone else because you know it's the right thing to do. It's a desirable quality. It's closely associated with bravery.

I could go on, but you get the point.

This is another way to express the same idea:

Two roads diverged in a wood, and I-

I took the one less traveled by,

And that has made all the difference.

Both quotes express the concept of courage, but to me, the second is far more beautiful, elegant, powerful, and effective at expressing that idea than the first. It has a misleading simplicity that makes it readily consumed but slowly digested. The careful choice and arrangement of the words amplify its power, and communicate a well thought out sense of artistry. I'll let you guess which expression corresponds to which version of my code. That's the version I'm aspiring to write.

[serialmilk]

750words.com MMP 10-19-12

again enough feeling // get going home

over productive think up

Background on what this is.

[serialmilk]

750words.com MMP 10-18-12

Background on what this is.

my point really think through totally until up well write //

actually also being challenge come foreign funny head idea

[serialmilk]

I really hope this spaceship works

One of the most popular movements to come out of the collective experience and wisdom of the tech industry are the dual concepts of lean and agile. As I understand it, lean is most often applied to the comprehensive experiment of launching and growing a new product or business whereas agile is most often used in the context of software/product development. Please let me know if this is a misinterpretation.

Semantics aside, the concepts are built on a shared philosophy: increment and iterate often when creating something new. It's important to define create in this context, because create does not simply mean make a new thing. I could tear a piece of paper into shreds (incrementally) and make something new. Create, at least by my terms, means building something sustainable that many people want and that does something productive to improve people's lives.

So how do you know what that thing looks like? Simply put, you ask! The idea behind incrementing and reiterating your product step my minute step is to avoid pouring your resources into making a great something that nobody wants. The startup graveyard is full of amazing software that nobody wanted. Instead, the lean philosophy demands that you check in with customers at every tiny point along the way, and continually ask them: is this something you really want?

If yes, fantastic! Now what about this thing?

If no, why not? Now what about this thing?

The agile approach applied to software development takes a similarly powerful, obvious, logical approach: iterate product development rapidly over short cycles to avoid creating an undesirable product and to keep the flow of ideas and decision making healthy and fresh.

Great ideas!

---

Tonight, in addition to watching Yukihiro Matsumoto, the creator of Ruby, speak about the future of the language at Twitter's beautiful new office, I also watched Ian McFarland give a concise and insightful presentation on agile development.

At the end of the presentation, an audience member posed a fantastic question: do the incremental iterations espoused the by lean/agile philosophies inhibit tech startups from tackling The Big Problems? He suggested that no SpaceX's or Tesla's could come out of Silicon Valley because of the focus on this incremental philosophy and the careful, measured process it advocates.

I was really impressed with this question, and waited intently for Ian's answer. The idea that this philosophy of product and business development, which seemed to make sense on every level to me, might actually inhibit me from accomplishing my goal of addressing The Big Problems was both fascinating and worrisome, and a prospect I hadn't considered at all.

Ian thought for a moment and then responded: "SpaceX doesn't just build a rocket, stick it on the platform, and say 'I really hope this spaceship works' before hitting ignition".

Duh.

The lean and agile philosophies are yet another paradigm I've encountered since beginning my transition into the tech world that appeals to me with such obvious clarity and logic that I can easily accept its premises as valid and sensible, and what's more, like so many of these paradigms, they seem to be easily applied to life broadly.

If you're pursuing something new, it makes sense to invest your resources incrementally until you know it's something that you want or something that works, rather than dumping all of your resources straight into something only to have it fail or not be interested in the outcome.

I think my approach to joining DBC was incremented, unintentionally. As I mentioned in this afternoon's post, that decision was put into motion as a thought exercise. First I wrote about the idea of joining the tech industry. Then once that seemed like a good idea, I started to dabble in code (2 weeks on the couch recovering from knee surgery is a great time to do the Hartl tutorial), and I continued to increment my interest before finally applying and getting accepted. Now I average over 80 hours a week of coding.

It would also be fantastic if our institutions were designed to support this approach. What if, instead of having to commit to four years of college at a premium time and money investment, learning could be pursued through exploration, iteration, and through the haphazard pursuit of an individual's interests according to that individual's timeline? What if careers weren't chosen, but discovered?

It seems to me like a lot of our experiences, choices, and lives could be optimized through an approach that relies more on incremental flexible decision making supported by strong feedback loops that evaluate the outcomes of those choices and perpetuate and grow our positive development. That would be nice.

[serialmilk]

750words.com and the Artist's Way

At the beginning of this year, I felt particularly lost about my trajectory. I don't compartmentalize well, and my dissatisfaction with a lack of purpose and direction was frustrating. Someone suggested that I reach out to a Tufts career counselor for advice. Being generally skeptical of my alma mater's institutions and opinions, I resisted for a few months until finally, after she made the suggestion again, I gave in.

Much to my surprise, the counselor I talked to was incredibly helpful. She recommended a book to me called the Artist's Way, which among other things, encourages participants to write three single spaced pages by hand every single morning right after you wake up. It's a challenge, especially if your writing muscles are out of shape, but I persisted for two months (plus or minus a few mornings) and ultimately, the things I learned about myself and what I want out of life led me to apply to DBC, a decision I couldn't be happier about.

Life got busy again, and my commitment to my morning pages faded until last week, when Nathaniel Whittemore, prolific writer, former VC, and current entrepreneur, came in to speak to us as our blogging consultant (how cool is that?? We have a blogging consultant!). Among many other super awesome suggestions, he proposed an optional challenge to commit to the Artist's Way via 750words.com, an online platform that anonymously documents your 'morning pages'. I decided to sacrifice fifteen minutes of precious sleep each morning to try to recommit to the practice.

Writing my pages out on the keyboard is a lot different than doing them by hand. They're more legible, for starters, and they take almost half the time. I think part of the experience is probably lost, but when time is this precious, you have to make sacrifices. The digital approach also makes some really neat features possible- you can view your statistics at the end of each session, which attempts to quantify your writing speed, feelings, mindset, time orientation, primary sense, perspective, and frequently used words. Out of all the stats, the last is my favorite. The floating prepositions mixed in with the substantial words it picks up form a unique mini-mindset-poem.

I might start each day off with a quick post of my mini-poem, formatted for clarity, as an experiment in computer art (I apply that term loosely) and as an atypical personal journal. Plus it'll keep me honest to the project.

This morning's MMP:

feeling like me more // only produce // think up // sleep

[serialmilk]

You aren't confused enough, and that's a problem.

I spend a lot of my time these days really, really confused. The kind of confused where words start to lose meaning as I stare at them on the screen, trying to glean a meager morsel of insight that might finally make a problem budge. We've started to transition from the surface of Ruby down into its depths (from shallow puddle to kiddie pool), and understanding is becoming less about reading and knowing the words on the screen (vocabulary) and more about relationships, dependencies, and associations (grammar and tone).

Somehow it's always the problems with the word 'simple' in the title that seem to bend my brain the furthest, probably due to our teacher's unique sense of humor. Today while working on "Refactor SimpleCRM", a very 'simple' 33 line program, we came across the code below:

https://gist.github.com/1f80ae19c01c22b34d54

Line 14 calls 'each', which iterates over a collection, on...nothing. This may seem trivial, but after 2 weeks developing eagle eye vision for any microscopic mistakes in our code that might throw an error, this line sticks out like a massive sore thumb. And we were confused.

And we still are! After a while, this particular use of 'each' without an obvious collection became clear to us, but the rest of the code did not, at least not entirely. The gist above is not a passing solution, and after spending an hour and a half trying to successfully refactor the thing (so much for simple) we decided to let it rest and see if we can find some clarity tomorrow. But I'm enjoying the feeling of being confused. In fact, I'm relishing in it.

---

Confusion gets a pretty bad rap. It's defined as having a 'lack of understanding', but the connotations imply shame and inadequacy. Confusion is scary, and like so many other 'scary' emotions, we as a society have loaded confusion with enough negative implications to dissuade many of us from wanting to experience it, let alone wanting to seek it out.

I'd like to speak out in favor of confusion, and even suggest that a well-lived life is one spent in a semi-perpetual state of confusion. My thesis is that confusion precipitates learning, and that I shouldn't have to explain why learning is good (at least not in this post).

Confusion precipitates learning by lighting a burning desire to understand in us. When I'm confused about a problem to the point where I think I've reached an impasse, I get a deep tension in my lower back that makes me so frustrated and uncomfortable as to almost lose focus and at the very least, make me readjust my sitting position every thirty seconds. That visceral, physiological manifestation of confusion gives me something to push back against and builds a sense of urgency that ultimately boosts the sense of accomplishment that comes with understanding once it's finally relieved.

Confusion is nature's complement to curiosity. Curiosity sucks you in, but confusion is the force that gets you from awe to understanding. And I would go so far as to guess that confusion, like so many of our behaviors, has evolved to keep you alive: confusion is intoxicating and possessive- for many of us, when we're confused about something, finding an answer or explanation becomes all consuming. Being caught up in a spell of confusion forces you to find an answer, and that knowledge, which you've worked so hard to secure, gives you a better chance of surviving or thriving over someone without the capacity or drive to seek a solution out.

So why is confusion weighed down with negative implications, and not honored and respected as a sign that someone is learning? Confusion can be embarrassing, or indicate weakness, and in that regard, it takes courage to both openly admit to being confused and to have the courage to see a solution through rather than let the problem pass you by.

Like so many of our behaviors, the decision to find a solution to something that confuses you or to pass up the opportunity is habit forming, and in many respects it's much, much easier to never admit to being confused and never forcing yourself to work through a problem than to risk the shame of confusion and the chance of 'not getting it'. There have been countless times in school where out of apathy or embarrassment I haven't raised my hand to clarify a point of confusion, and it's costly.

The learning environment at DBC is designed to keep us confused, and that confusion is a powerful catalyst for learning. I've come to recognize that confusion is critical- if i'm not confused about something, that means I'm not learning. Although feeling confused all the time can be frustrating and draining, the results of our progress in two and a half short weeks speak for itself.

In a video on Ruby I watched on the way to work this morning, the presenter encouraged his audience to take the hard way in approaching software architecture rather than relying on prebuilt structures they likely didn't entirely understand. He said: "If you want everything to be familiar, you'll never learn anything new". I think those words are highly applicable to our lives, and I encourage anyone out there whose taken the time to read this rambling essay to think about how often you force yourself into a position where you're confused, and what you might be missing if you solely stick to environments that are comfortable to you.

[serialmilk]

Repair Your Feedback Loops

For our second 'Engineering Empathy' session this morning, we talked about feedback. In the context of programming, exchanging productive feedback with your pair can make a good pair great, and more importantly, make a dysfunctional pair functional. But like everything we do at DBC, the lessons are more broadly applicable.

Shereef suggested that negativity in our lives can often be attributed to a series of broken feedback loops, which naturally got me thinking about my own relationships. How much more enriched could our relationships and our lives be if we weren't so afraid to give feedback? The risks, as they're currently defined, are high: poorly received feedback can have a dangerous and even destructive effect on a relationship. But that means that we're basically confined to whatever we can manage to construct with a person that doesn't rock the boat. Similar to my thoughts on the first EE session, it seems foolish to let something so important be settled so passively.

A bold suggestion was made to each of us: strive to develop the reputation that 'you can tell this person anything'. Again, so groundbreaking, and yet so simple.

Receiving feedback well doesn't mean striving to change yourself based on what other people are telling you, and it doesn't mean holding another person's opinion as gospel. When receiving feedback well, it's critical to try and discern what's yours (as opposed to what a person might feel the need to include about themselves and their needs, disappointments, or fears), and own it.

It's just as important to learn to give good feedback. I recognize that I have fears about giving other people feedback at all- we all recognize that the risks are high, and doing nothing and retaining the status quo generally feels like a more comfortable option. And sometimes, even when I have tried to give feedback, my efforts have fallen short.

Shereef suggested that when giving feedback, it's critical to make a clear distinction between intention and impact: impact is not always aligned with intention, and if you receive that as feedback (for instance, if the person you're giving feedback to feels attacked, accused, or persecuted), change your approach to change your impact so the person can see your true intention.

I'd like to make an effort to implement this in my own life, and I want to challenge my friends and family to not be afraid to give me feedback on our relationship, and also to not be afraid to receive it.

One question I didn't get to ask during the session today was: what can you do when no matter how many times you change your approach, the person receiving your feedback still can't discern impact from intention? There have been times when, trying to give someone I deeply care about feedback, I try every iteration of "I love you and I care about you, and this hurts me or makes me feel bad" and it seems to continuously fall on deaf ears. Is there an issue with the phrasing? The tone? Does that suggest some kind of basic incompatibility? I'm open to anyone's thoughts on the topic, and maybe I'll get a chance to pose the question next Wednesday.

The last thing I want to talk about is the relationship between feedback, complements, and criticisms. We're all familiar with criticism- it's sharp, generally uninvited, and almost always counterproductive. It was suggested that a complement is often merely the opposite of a criticism- suggesting that a shortcoming has been amended or reconciled. Feedback, on the other hand, brings you closer to a person because it's a truth spoken in loving kindness.

Shereef noted that one of the hardest things to do is gracefully accept positive feedback- without the need to deny it, downplay it, or pay the person giving you the feedback the same courtesy in return. He suggested that the ultimate response to positive feedback might be something along the lines of "Thanks. I'm glad you noticed."

Today, while receiving feedback from one of the six people I've paired with over the last eight days, I was so grateful and flattered when they suggested that I was one of the sharpest students in our cohort. I was humbled, and about to deny the suggestion, but instead I paused and told him "Thanks. I'm glad you noticed."

[serialmilk]

Battleship

Just a short one tonight. Home past midnight and exhausted from 16 hours 'completing' Battleship. I put it in quotes because there's a difference between completing an objective by fulfilling the requirements of the code, and actually producing something that I'm proud to call a solution, and in this case it is definitely the former. The code works, but it is heinous. Repetitive, inelegant, and generally a mess and far too long. The computer is also very dumb- it won't shoot for the same square twice, but it has no concept of clustering successive shots after scoring a hit in order to sink your ships. Even though I shouldn't be happy about this, I can't help but take a little bit of pride in the fact that this behemoth clocks in at a monstrous 400 lines of code (I'm sure I will laugh at this sentence in a month week).

Most of you fine readers out there should be able to run this thing on your computers! (I think).

Download the file here (right click it and select 'save link as', and name it battleship.rb) and place it on your desktop.

Open up your terminal.

Type 'cd desktop' (no quotes)

Type 'ruby battleship.rb' (no quotes)

Hopefully it works!

[serialmilk]

The Power of Community

It's no secret that at DBC, we're basically paying to be around each other. To some people, that might seem like an unthinkable rip off. Ten thousand dollars for nine weeks of 14 hour days around like-minded people interested in learning the same thing? Insane. A gip. Outrageous. Inflated.

After six days, I have complete conviction that the experience is worth every penny.

Today, while pairing with my new friend Daniel building battleship, he said something along the lines of "if only we were in the matrix and we could just download the knowledge to build this thing!" I laughed when he said it (we were struggling through a particularly murky part), but I realize now after a few hours of reflection, that the learning environment at DBC is the closet thing anyone could create to downloading information directly into our cerebral cortex via firewire twenty-point-oh or whatever that sterile looking future cable is.

How many other programs do you know of where you can acquire a lifelong foundation in a completely new complex skill in nine weeks? There is no other way that I would be building a program in which a user can play battleship against a computer after six days of 'instruction'. The secret is in the community.

So many of our technologies and institutions seem to disintegrate communities rather than grow them. Do you really feel like a part of a community when you like a post on Facebook, or watch tv? I suppose one could argue that internet memes and tv shows define the new required standards of knowledge to fit in and socialize with people when you do see them in person (increasingly rare, at least compared to the ancestral environment in which we were formed), but something about that content often feels 'lower-order', for lack of a better term.

I'm fascinated by technologies that enrich the human experience rather than detracting from it, and that's a major reason why I got into this game- because this is where I see real opportunity to make a positive impact on a lot of people's lives. And to that end, it really pleases me that the institution that will hopefully empower me to achieve that goal exemplifies that ideal itself.

It was apparent tonight, when we hosted a mixer for boots and mentors at the office. One hundred people in a room- students, teachers, engineers, consultants, entrepreneurs- all united by a common passion for our learning experience and for producing something great. And it was apparent this weekend, when more than half the boots spent their Saturday and Sunday in the office digesting the week's lessons in the office.

Each individual has a unique drive and passion, but only together do we create this vibrant learning community that empowers us all to achieve incredible results, and to me, that justifies the (still painful) price. I look forward to completing, and maybe even sharing a game of battleship with you all tomorrow.

[serialmilk]

Rock..Paper...Ugly If-Else Statements!

Today I paired with Daniela, who I think I met up with the most times before the program started (we share a fondness for beer) and who is, in my opinion, one of the brightest members of our cohort. My code and my learning benefitted in all kinds of ways from working together with her today, but there was one instance in particular that really struck me.

Learning to code well is about way more than just learning the "correct" syntax to express a problem. There are too many different problems and too many different ways of solving each of those problems to come up with a comprehensive reference of code solutions. Creating elegant code is a matter of learning to think in code as a language, a concept I touched on in a prior post, and a skill that I'm still in the earliest stage of refining.

Daniela, on the other hand, is a bit further along in that capacity (I credit her former life as a middle school teacher). For one of our challenges today, we had to assign our partner a problem to work on as practice writing 'pseudocode' a language-agnostic set of instructions for building a program. I assigned Daniela a two-player story creator game, and she assigned me rock, paper, scissors.

Rock, paper, scissors pseudocode:

https://gist.github.com/3838300

After an hour or so of working on our solutions, I was feeling pretty good. Building on Shereef's advice yesterday, I tried to pay really close attention to keeping all of my methods light- 3 lines of code or less- and creating many of them and linking them together. I ended up with this:

https://gist.github.com/3838308

Now, the astute among you, and probably even the non-techies, will notice that the outcome method, the heart of the logic of determining whether the player or the computer wins, is a bit longer than three lines. About seven times longer, to be exact. I couldn't conceptualize a way to simplify this logic, which first has to identify the player's choice and then identify the relationship between the player's choice and the computer's choice, into anything simpler.

I showed my code to Daniela, and she came up with a fantastic solution. I'll show it to you before I explain it so you can try and make sense of it yourself:

https://gist.github.com/3838304

Got it? Yes? No? I'm going to explain it regardless just so I can hammer the concept into my own head one more time. Here's how it works: combination_hash represents the series of winning combinations. Scissors is paired with paper, paper with rock, and rock with scissors. So how does this work?

We access the combination hash using the player's decision as the key, which means that the value returned by the hash is the losing pair to the player's decision. Then the ternary operator (if/else statement) checks to see if that value is equivalent to the computer's decision. For example: if the player picks scissors, the combination hash will return paper. If paper == the computer's decision (if the computer chose paper), the ternary operator returns "win".

Now what happens if you don't win? We have to determine whether you drew or you lost. To do that, we nested a second ternary statement in the first's "else" branch. This time, we access the hash using the computer's decision as the key (again, returning the losing pair to the inputted choice) and see if the returned value is equivalent to the player's decision. If so, the computer wins, if not it's a draw!

This refactoring decreased the length of that method from 23 lines down to 5, but it's about more than just the physical size of the program. The refactored version is simply more elegant than a bunch of nested if/else statements, and I think learning to conceptualize problems under these terms is a major part of becoming a better coder.

On another note, Steve Huffman, the co-founder of Reddit and Hipmunk, came and talked to us for our first Thursday night speaker series. He talked a lot about what coding as a craft means for him in terms of the kind of attitude, practices, and knowledge he expects from job applicants. Although it can sometimes be overwhelming, I really appreciate that our environment forces us to maintain a dual consciousness focused on both the micro and macro steps toward becoming programmers. On the one hand we're faced with micro-level Ruby challenges- figuring out methods to make pig latin or return prime numbers, and getting a basic understanding of all the different methods. On the other hand (Steve's talk was skewed toward this end), there are macro-level concepts like how the computer actually performs all of these methods, how a server works, or even how the internet works!

There's so much to learn, and on that note, I'm going to bed. I felt my brain shutting off after wrapping up the pig latin problem and decided to leave "early" at 9pm. Time to enjoy a few extra hours of sleep.

[serialmilk]

Engineering Empathy & Number Palindromes

I hope my previous two posts have made it clear that DBC is about a lot more than just learning to code. Every Wednesday we have a 4 hour 'Engineering Empathy' session, known by some as 'Touchy-Feely Day'. The basic (perhaps 'surface' is a better word?) rationale for EE - if you were to treat DBC as merely a coding program - is that to work successfully as part of a team of software engineers, you need to be able to interact with your teammates in a healthy, productive, and positive way.

But DBC isn't just a coding program.

Everyone dug really deep in our session this morning, and I can't describe it as anything less than intense. Steve and Shereef led us through a series of exercises that explored the way we perceive ourselves and others when we interact, forcing us to examine our prejudices and assumptions. We experienced what it might be like if we collectively decided to start trusting and loving each other, and what it might feel like to be comfortable and confident in the knowledge that everyone around you trusted you and loved you.

I recognized in a subsequent reflection session that my normal tendency would be to express skepticism around exercises like these, probably adopting some kind of 'too cool for school' angle, but I'd already swallowed the DBC pill, and I totally bought in- and I'm really glad I did. The exercises were fantastic- they brought out an incredibly powerful sense of casual, unshakeable intimacy with our fellow Boots in a profoundly positive way. I could sense the entire tone of the room change as we proceeded deeper and deeper into the exercises- and this occurred in a room of sixty people- keep in mind that I'm still learning half of the cohort's names.

At one point, Steve said something along the lines of 'recognize that every individual around you has a totally unique and unknown life experience, completely different than your own'. That really clicked for me. For as long as I can remember, I've tried hard to recognize that I've had an incredibly unique life experience, and that I would do a disservice to myself and others were I to assume that anyone else's life experience has been any less profoundly unique than my own. I don't always succeed in practicing this principal, but I hope that going forward, I can keep myself aware of it a little more often.

There's so much more to say about this morning's experience, but I'll wrap it up with this: in addition to everything I was feeling about myself and my fellow Boots, I also felt myself longing to go through the experience a second time with all of the other people in my life. I take a lot of pride in genuinely loving everyone I choose to surround myself with, and yet, despite the immense love I feel for all these people, my sense of intimacy in these relationships often comes up short. For how many of my friends do I know their dreams, aspirations, and fears? For how many of them do I know what they truly love? What drives them? What scares them? What keeps them awake at night, and what gets them out of bed in the morning?

I touched on the sense of reawakening I'm experiencing in my last post, and I choose that word intentionally, because I think at one point in our lives, even if it was early on, we entered this world sharing all these things, loving and trusting one another because we didn't know any better, until we were taught otherwise. Part of this reawakening is coming to an understanding that there are ways wholly within our grasp to get so much more out of our lives and our relationships than what we choose to settle for. I'm really looking forward to the next EE day, and I hope that I can find a way to bring what I'm learning from these experiences into those relationships that exist outside of DBC.

---

Oh sorry what? Coding? Yeah we did some of that today too. Powers and I paired together for the afternoon and since we'd both already gone through most of this week's DBC assigned challenges, we decided to try a Project Euler challenge. The objective: 

A palindromic number reads the same both ways. The largest palindrome made from the product of two 2-digit numbers is 9009 = 91 x 99.

Find the largest palindrome made from the product of two 3-digit numbers.

Alas, I have forgotten to save the code as a gist, so it's currently occupying space on the desktop of one of the computers in the office, but the logic of our solution can be summed up pretty easily:

Create an array of palindromes between the lower limit (100 x 100) and the upper limit (999 x 999). A number is a palindrome if number.to_s.reverse == num.to_s

Reverse the array of palindromes so the largest palindrome is at the front of the array (so we can return the largest palindrome immediately rather than checking from the smallest one until we determine the largest one).

For each palindrome in the array of palindromes, divide that palindrome by all the numbers between 100 and 999. If a number divides into the palindrome and produces an integer (not a number with a decimal), and if the quotient of that operation is a 3 digit number (we tested this by seeing if the range (100..999) included the quotient), then return that palindrome as the answer, cause it's the biggest!

If I remember, I'll try and upload our code tomorrow. It ended up getting somewhat convoluted toward the end because as an extra challenge, we tried to build a program that could take the digit length of the numbers you wanted to test for as a parameter and then find the largest palindrome. For instance, if you entered "4", the program would return the largest palindrome produced by two 4 digit numbers. (Turns out that's not so easy...our program conked out after a few minutes of trying to figure that out, I might attempt to refactor our code tomorrow and see if we can get it to actually determine an answer).

As with so many of these problems, someone else often has a better way of doing it. Once we solved the problem with our dense program, we found this simple, elegant solution in the Project Euler answer pages (only unlocked once you submit the right answer- no cheating allowed...anymore!). Something to aspire to:

https://gist.github.com/d0b504641b94883d2b53