Thanks for all the feedback and comments on the Learning to Program series with Nate Abbott and Natty Zola from Everlater. In the last post, titled Web Sites and Books for Novice Programmers, I foreshadowed some of the tools that Nate and Natty chose to build Everlater. Now that you know how they got started, here’s what they ended up choosing.
Everlater is built on Ruby on Rails, postgreSQL and is hosted on Engine Yard using a passenger/nginx combination. Nate and Natty use several standard Ruby/Rails packages (gems) to extend the base functionality of Rails. On the front end, they use a combination of jQuery and Prototype for Javascript.
The technology stack that they’ve ended up with has evolved over time. The very first decision – which web framework/backend language to use – was the toughest. Once again, our friend Google appeared – this time for the phrase “web framework comparison.” A few days later, the exploration shifted from simply finding and poking around in the various languages (most notably Ruby/Rails, PHP/CakePHP/codeIgniter, Python/Django, ColdFusion, .net, and Java), to figuring out the salient points in the debate: speed, ease of use, active development of the platform, security, and cost.
Over beers, Nate and Natty put on blindfolds and threw darts at a board. After incorporating these results into their decision matrix, they chose Ruby/Rails mostly because they felt that it had an active community developing it and seemed to be the easiest to learn the quickest. It took roughly a week to come do a decision, start to finish.
After choosing Ruby as the main language they would be working with, they immediately began searching out every possible Ruby coding Meetup. Through those meetings they became connected with Boulder’s Ruby community which is an amazing group of incredibly smart people. They also found two great people, Charlie and Ryan who began working with Everlater for equity early on and helped make some of the key early decisions.
If you are a senior Java developer anywhere in the US and are interested in moving to Boulder, I’d like to hear from you.
There was a nice article in Bloomberg Businessweek last week about Why Boulder Is America’s Best Town for Startups. With the combination of the new startup activity over the past few years combined with the rapid growth of a number of medium sized companies and renewed hiring from some of the outposts of major tech companies based here, we’ve clearly entered another cycle in Boulder where talent is tight and demand for senior folks is once again at a high point.
Of course, if you are living in Boulder or Denver and aren’t happy with your current job, feel free to reach out to me. But I’m also game to talk to people that are interested in relocating to what I think is the best small city in America.
In the continuation of the Learning to Program series with Nate Abbott and Natty Zola from Everlater, I asked them a few questions about which web sites, books, and blogs they consumed at the beginning of their journey when they knew nothing about programming.
It turns out that Nate and Natty spent most of their time simply searching for what they were looking for. Whenever a specific topic came up, they’d use Google, be patient when reading through the search results and forums, refine their search, and keep trying. They discovered that there are an amazing number of programmers who publish code on their personal blogs. As they were trying to get basic stuff to work, they spent time searching for and then reading the full posts and comments.
While they like sites like Stack Overflow and Github’s wiki pages on different open source projects, Nate and Natty never found a great site on the web that has comprehensive documentation on how to program. Instead, they concentrated on being smarter than the problem, really thinking it through and isolating what they needed to learn, and then being patient in searching for and researching the answer.
As Nate and Natty landed on a language and a set of frameworks to work with (more on that in another post) they spent a lot of time with the API documentation for languages and frameworks. As dry as it might be, they waded through the Rails API, the jQuery API, and even the WC3 documentation. But they often quickly ended up back at Google searching away.
It turns out that Nate and Natty have only bought three programming books in the history of Everlater and one was a forgettable SEO book that doesn’t even merit being mentioned. The other two were HTML, XHTML, and CSS published by Visual Blueprint and RailsSpace by Michael Hartl and Aurelius Prochazka. They felt the HTML/CSS book was so-so but it was enough to get them started. On the other hand, they thought RailsSpace was an incredible book that taught Ruby on Rails by walking through the steps to create a social network for Rails programmers. While they felt this was a little corny, it also ended up being very effective.
Not surprisingly, Nate and Natty read a lot of blogs. They read typical tech news blogs like TechCrunch and VentureBeat, popular VC blogs like Fred Wilson’s and Dave McClure’s, and entrepreneur blogs like 37signals blog Signals vs Noise. But when they went deep technically, they spent a lot of time with RailsCast, the Engine Yard blog, and Yehuda Katz’s blog. For design, they went with SpeckyBoy and Smashing Magazine. And when they needed a break from development they read Tech Trader Daily which was a holdover from their old life as junior investment bankers.
As I reflected on this, I found it fascinating how little they relied on books. True to form, they sat down in front of their computers and just got started. All of the information was already out there – they just had to be disciplined about finding it, reading it, and learning it.
What have you read lately?
To start off the Learning to Program series with Nate Abbott and Natty Zola from Everlater, I asked them the simple question “What Was Day 1 Like?” Nate responded first:
Day one was totally overwhelming. Overwhelming because we didn’t know what we didn’t know. It’s one thing when you don’t know how to do something (e.g., validate email addresses or change a button’s hover state). But we didn’t know what we needed to learn, and that made it difficult to even start down a path. The first week was spent just googling "web site design", "web site architecture" and "web server" to try to get a handle on all of the acronyms we were coming across (such as CSS, HTML PHP MYSQL, ROR, JS, AJAX). Our goal was to piece together the list of skills that we were going to collectively learn in order to create a web service like Everlater.
Day one was also thrilling and exciting. It’s the same feeling I get when I’m starting a long bike ride in the mountains, the same feeling I got when I first got to college, or when I got my first offer letter for ibanking in New York. To me, there’s nothing more exciting than beginning a large task, and nothing I had done was quite like the task at hand.
Natty responded shortly there after with a few things to add:
We also researched sites we liked and benchmarked what they were doing/using to get a feel for what the popular/hot sites were using. Most notably I remember looking at Facebook and seeing .php at the end of the url string. This gave us ideas of where we should start our research.
I was excited like Nate, but also somewhat afraid. We quickly realized we were going to be learning another language, but much harder than a foreign language because we couldn’t rely on familiarities like verbs, nouns, and sentence structure. Worse, we would have to learn the basics of speech in becoming functional at the command line, databases, and editing programs.
The other interesting thing was that before we put any code down or started day 1 of our idea, we had spent a month brainstorming what we wanted to build. While this was pre-day 1 it enabled us to focus on making code/tech decisions and learning the code rather than also having to think about what we were doing with it. I think this sped our research because we had a framework within which to think about the decisions we were making.
Lastly, it really helped to research with Nate because we could bounce ideas around, problem solve, and challenge each other. Plus, it made it significantly more fun knowing we were diving into the unknown together.
To summarize. They were simultaneously overwhelmed and excited. But fearless – they just jumped into the swimming pool off of the high dive and hoped there was water in the pool.
I had lunch today with Nate Abbott and Natty Zola, the co-founders of Everlater, a TechStars 2009 company. Nate and Natty are two of my favorites – not only because they regularly kick my partner Seth Levine’s ass on bike rides but also because they starred in last year’s TechStars The Founders video series.
Today, while enjoying a veggie burger at Mustard’s Last Stand, we talked about how Nate and Natty learned to program. When they came up with the idea for Everlater, they were both young finance geeks on wall street. Nate was a math major; Natty was a econ major, but neither had a clue how to build a web app. They decided that rather than find a “developer” to team up with, they would learn how to program.
I regularly get asked questions (via email, face to face, and this blog) by non-technical entrepreneurs how they should get started if they don’t have a technical co-founder. There are a variety of answers – one is “learn to program.” In Nate and Natty’s case it’s worked out great and their story is an instructive one. So we’ve decided to work on a series of blog posts together about their story of how they learned to program, the resources they used, decisions they made, struggles they had, and beer they drank (well – maybe not the beer).
Now, both Nate and Natty are smart, which is obviously a pre-requisite. But neither were computer science majors, nor were they “hackers” (although apparently Nate is pretty good at a wide range of video games.)
Look for some posts over the next few weeks on this topic. Of course, like any of the series I’ve written, your feedback matters a lot to how much I keep it going. If you decide that the story is great and/or helpful, tell us and we’ll keep it going. If not, we won’t.