May 31, 2012


Achieve Flow

When I participated in Y Combinator in 2009, the first thing that happened is we were given plain gray t-shirts that simply read: "Make something people want." I still have and wear this shirt today.  I believe the phrase originated from Jessica Livingston as she was interviewing founders for [Founders at Work](http://www.amazon.com/gp/product/1590597141). We've been lucky to have finally found something that people want and are paying us for.

When I sat and thought about what I wanted my students to embrace, I realized what it was: [Mental Flow](http://en.wikipedia.org/wiki/Flow_\(psychology\)). It's hard to reach mental flow as a beginner. It's the single best feeling you'll ever have as a programmer. Time disappears and hours feel like minutes. You're fully immersed in the code you're writing and the application you're building.

For beginners, [it's difficult to achieve Flow because the conditions aren't right for it](http://en.wikipedia.org/wiki/Flow_\(psychology\)#Conditions_for_flow). Flow occurs when both the challenge level and skill level are equal and maximized. Most beginners have a project they want to build, so the challenge level is high. But their skill level is low and remains low until they learn [everything they need to build a web application](http://trybloc.s3.amazonaws.com/rails%20dependencies.png). The result is anxiety.

The t-shirts I send my students will be simple, much like the YC shirts. The front will simply read "Achieve Flow." It's something I want them to strive for. It's something I want them to experience because until it happens, they won't appreciate programming the same way I do. Achieve Flow serves as a reminder that while they may struggle now with learning about blocks, iterators, symbols, models, and database associations, these are merely keys that unlock a mental door so that they can finally experience Flow.

This is what every beginner should strive for: Achieve Flow.

Tweet about this on TwitterShare on LinkedInShare on FacebookShare on RedditEmail this to someone

May 22, 2012

What a computer can’t teach you

Designing a course that teaches people web development in 8 weeks presents a bunch of interesting challenges.  Some people have been programming for 8 years, some 1 year, some never.  Some have been exposed to HTML and CSS, some haven't, and some are experts.  Take any particular knowledge and divide it into those three buckets: no experience, some experience, and experienced.  Now put all those people together.  What do you get?  A mess.  It's very difficult to cleanly divide the world into beginner, intermediate, and expert.

Half of our job is to curate content.  Bloc is not just another resource.  There are, for all practical purposes, an infinite number of "resources" for learning rails, javascript, jquery, SQL, test driven development, MVC, vim/emacs/textmate/edlin, ruby, HTML, CSS, and everything remotely related to any of those.  A large part of what we do is cut away all the bad stuff and curate the web into the absolute best bits of content for our students to eat.  At Bloc, you eat one juicy filet (with grilled asparagus) rather than a metric ton of Taco Bell quasi-meat in a mass-produced cardboard shell.

Computer-aided instruction is really promising.  There are tons of companies exploring all the different facets of allowing students to self-teach, with various levels of success.  However, I believe very deeply that what people need is a guide, not an assistant.

Once more: what you need is a **guide**, not an assistant.

Why?  Because guides can teach you meta-lessons.  What's a meta-lesson?

As programmers, we use skills everyday that apply to life in general.  Tenacity, problem solving, courage, self-awareness, and more are all (to various degrees) required to be a good software developer.  If this were not so, then we'd all give up as soon as we hit a wall.  Sometimes it means googling an error and sifting through 15 stack overflow questions.  Sometimes it means hopping onto IRC and questioning a bunch of strangers.  Sometimes it means taking a break, and sometimes it means discovering the solution [in the shower](http://www.paulgraham.com/top.html) in the morning.  These are things a computer cannot teach you.

You know that feeling of frustration when you've tried **everything** and the goddamn thing still doesn't work?  An assistant can't help you there.  Remember the last time you felt like an idiot because you mistyped a git command?  An assistant can't help you with that feeling.  When you don't even know *what* to ask, an assistant is worthless.

Assistants can't help you grow.

At Bloc, we teach you meta-lessons.  We're **guides**, not assistants.  We help you grow.

Tweet about this on TwitterShare on LinkedInShare on FacebookShare on RedditEmail this to someone

May 21, 2012

Stop intimidating beginners

We did our weekly drive to [Dev Bootcamp](http://devbootcamp.com/), and somehow, the conversation came up about people in the development community who are assholes. And basically, there's just no reason or excuse that anyone should be acting like an asshole to anyone else. I'm not going to name anyone in particular, but they exist and they're out there. To say that it's unfortunate is an understatement. It's disappointing.

I told Shereef from Dev Bootcamp that I was reluctant to recommend beginners in my class to go to #ror. Why? Because increasingly, people in the community have become intimidating to beginners. My own co-founder, who I regard as one of the smartest hackers I know, used IRC once and never did it again. Why? Because the community intimidated him.

Most people in the Rails room will make you feel like an idiot for asking certain questions, typically the ones that beginners will ask. With the exception of a few people like Radar, it's disgusting that the channel and certain individuals in the larger learning community have become like this. And this is why our business model works now. This is why people are paying us $3,000 to mentor them. Because IRC is too intimidating and way too judgmental of people who want to learn. They're tired of people judging them when they get stuck on a piece of code. One of my students was tired of getting down voted on Stack Overflow, and that's why they're now a Bloc member.

We're all human, and we're doing the best we can right now. We struggle, and we want help. If you think you don't fall into that category, you've merely forgotten what it was like to be a beginner. It's the same circle that we experienced when we started out. Someone else extended a hand and pulled us up when we got stuck. To close off that loop and make beginners feel intimidated is pretty pathetic, and we as a community aren't doing our job right when it's happening.

Stop being judgmental. Stop being intimidating. Stop putting people down. There's no excuse for doing that.

Tweet about this on TwitterShare on LinkedInShare on FacebookShare on RedditEmail this to someone

May 16, 2012

Getting your ass kicked

![](http://kidsdontgetit.files.wordpress.com/2008/10/drill-sergeant.jpg)

When's the last time you got your ass kicked?

I'm not talking about a fight.  I'm talking about getting absolutely beaten senseless at your own game; having someone more experienced than you utterly shatter your view of a particular subject.  These can be the biggest opportunities for growth.

At Bloc, we like to think of ourselves as personal trainers.  It's a great analogy for what we're trying to do — whip people into shape.  Becoming a web developer in 8 weeks is REALLY hard.  If you hit the snooze button 6 times every  morning, it's probably not for you.  We don't hold your hand; we push you into the deep end.  Learning to swim is hard, no doubt. But imagine getting pushed into the deep end with 10 other people.  Nobody is going to drown.

Once you show up to the gym, the personal trainer will kick your ass.  And often this is exactly what you  need.  It's a position of extreme vulnerability, awesome potential, and it can ultimately be transformative.  I've been privileged enough to witness folks go from zero coding experience to obtaining jobs as software developers within a span of two months.  This is a quantum leap.

The biggest lesson so far, for me, has been that being nice is not always the right answer.  People seem to have an intrinsic urge to prove themselves; our society tends to either mock this process (often sarcastically), but from what I've seen, the natural tendency can be an excellent catalyst for growth.


We all have much to learn; as the phrase goes, "The more you learn, the less you know."  There's no better way to connect and learn with your fellow human beings than being pushed into the deep end of the pool together. 

Tweet about this on TwitterShare on LinkedInShare on FacebookShare on RedditEmail this to someone

May 16, 2012

The point of the first week

I had a student approach me and raise this concern:

Q: Seeing as I'm new to this, I'm definitely going at a slower pace and having to re-read things. Should I stop re-reading and just move on? I guess I just don't see how I could really grasp anything if i'm going through it very quickly, or "too quickly".

A:  The goal is _not_ to have everything click. It's like a first pass algorithm on sorting, and you progressively fit all of the missing pieces in as you read. Expecting everything to click would be counterproductive because you actually won't use everything you learn.

*You just want to build up some basic pattern recognition, became familiar and comfortable with Ruby, [and reduce the fear/anxiety](http://en.wikipedia.org/wiki/Flow_\(psychology\)#Conditions_for_flow) that you'd otherwise get stuck on if you just went into building rails apps.*

You will always feel like you don't fully understand stuff, especially when you start. It's very tempting to stop and spend lots of time on one thing, but you can drill down infinitely on any given topic. You could spend an entire 10 weeks on unit testing, but we just go over it so that if you need to learn it in the future, you have some baseline knowledge.

You have roughly 2,000 pages to read in your first two weeks. Get through it, don't get hung up on any individual thing. Highlight the parts that don't make sense, and then ask your mentor to explain them (or ask your fellow students).

Tweet about this on TwitterShare on LinkedInShare on FacebookShare on RedditEmail this to someone

May 15, 2013

Wireframes, Databases, and Migrations

I had some issues running migrations when a student shared their code with me. When I looked at their migrations, they had a long list of a lot of changes they were performing on-the-fly to the database.

In general, you don't want to do that because you can prevent others from doing a rake db:migrate starting out from scratch with no schema. I've done that in the past before, and it's a headache that ultimately is caused by a lack of upfront planning.

Always write down your whole schema before you start building your application. Know every table, every column, and every association (the associations are less important since they're easily written to the models, but write as few migrations as possible).

This is why wire-framing is crucial. It not only keeps your migrations clean and makes it easy for others to migrate up to your current schema, but it also helps you learn to program faster. Wire-framing forces you to think about all the possible interactions in your application. Instead of thinking about the contrived examples given by a book author, you're thinking specifically about how it relates to what you're building, and the learning sticks faster. The neurons in your brain like this better, and they'll more eagerly make room for new connections to form based on this more relevant way of learning.

In summary:

– Always start with a piece of paper and a pen. Write down your database tables and columns. Know the data types. Write down all assocations.

– Always spend time wire-framing in advance. It helps speed up the learning process.

– The more time you spend thinking about your application now means the less time you spend altering schemas, adding migrations, and throwing out code later.

Tweet about this on TwitterShare on LinkedInShare on FacebookShare on RedditEmail this to someone

May 14, 2012

The danger of mockups

I've been a proponent of MVP and agile startups for so long that I forgot what it was like to be doing anything else. I build applications so quickly that it has become second nature to me.

I felt like I was able to step back into the shoes of someone non-technical when I had my first call with a student today on Bloc. I saw his mockup, in all its glory and polish and all of the users so busily creating new data and contributing inside the Photoshop layers.

The problem with mockups is they show what the final product should look like. They skip over the entire customer development cycle and all of the iterative development that goes on in a real startup or project. They look so good, yet they're so uninformed and misguided with all of these users that aren't actually on the site yet.

If someone was trying to create Facebook, they might mock up something that looks like it does today, but Facebook started out as an ugly web site for Harvard students to see who else was in their class.

I would recommend to future students that they not bring mockups to their first call, just ideas and simple wireframes. The user will do the rest of the work.

Tweet about this on TwitterShare on LinkedInShare on FacebookShare on RedditEmail this to someone

May 13, 2012

A Better Way to Set Up Rails on Windows

In this post we'll go over how we have our Windows students set up a modern Rails environment for our courses.

Setting up a modern Ruby on Rails environment on a Windows computer  is a tormenting experience. Even after you set it up, you'll continue to be plagued by incompatibilities. While it's possible to write Ruby code that works on any operating system, many programmers ignore the Windows platforms so that some portion of the libraries available to most programmers will not be available to Windows users. Check out [this StackOverflow post](http://stackoverflow.com/questions/164896/limitations-in-running-ruby-rails-on-windows) for a list of all the incompatibilities and potential problems you might run into with Rails on Windows.

At one point, I would have told anyone who wanted to seriously learn how to program that they couldn't do it unless they installed Linux or bought a Mac. Thanks to virtualization technologies, we have much better options today that can give you a pretty great approximation of a Linux computer with a minimal amount of effort.

### VirtualBox and Vagrant

VirtualBox is a tool from Oracle that allows you to create virtual machines on your computer. A virtual machine is essentially a whole new virtual computer inside of your own computer. Unfortunately, configuring and bootstrapping a new virtual machine can be complicated, and that's where Vagrant comes in.

Vagrant allows you to specify a "recipe" for a virtual machine inside of a single Vagrantfile and then create and bootstrap your virtual machine with a simple `$ vagrant up` command. I would highly recommend watching Ryan Bate's [Railscast on Vagrant](http://railscasts.com/episodes/292-virtual-machines-with-vagrant) to get a more clear picture of how you use Vagrant. The official documentation for Vagrant is very well written and easy to understand as well, check it out at http://vagrantup.com

### Setting Up Your Rails Environment

1. Install VirtualBox: https://www.virtualbox.org/wiki/Downloads

2. Install Vagrant: http://downloads.vagrantup.com/tags/v1.0.3

3. Download this Vagrantfile into the directory you're going to code in: http://bloc.s3.amazonaws.com/Vagrantfile

4. From the command line prompt, run: `

$ vagrant box add base http://files.vagrantup.com/lucid32.box`

5. From the command line prompt and in the directory of your Vagrantfile, run `$ vagrant up` **Note**: this could take up to an hour, and you'll get many `Gem.specification` deprecation warnings that you can ignore.

6. Set up PuTTY to allow you to SSH into Vagrant (see directions on the Vagrant site in the "Using Microsoft Windows?" section here: http://vagrantup.com/docs/getting-started/ssh.html)

7. You're now on a virtual box within your computer, except this one is running Linux. If you do `$ cd /vagrant` you'll be able to see the Vagrantfile you copied into a directory earlier. This is a special directory on your virtual box that links back to the directory you created from Windows. If you create a file in there from Windows, you'll be able to see it in this directory and vice versa.

Done. You now have all of the essentials of a modern Rails environment set up on an Ubuntu VirtualBox on your Windows computer.  Try creating a new app within your VirtualBox with `$ rails new <app name>`.

If you'd like to see what you can do with your new virtual machine instance, be sure to check out the official documentation at http://vagrantup.com and the Railscast [here](http://railscasts.com/episodes/292-virtual-machines-with-vagrant)

Tweet about this on TwitterShare on LinkedInShare on FacebookShare on RedditEmail this to someone