Zack Shapiro

I'm Zack, an iOS developer at Splash in New York City. Before moving to New York, I lived in San Francisco. There I helped build TaskRabbit for Business and then Product Hunt in its earliest days. I also founded Luna, a nighttime delivery company in San Francisco which was acquired in May 2014. 

[zackshapiro]

Some big news, I've been invited to join the Svbtle network!

From now on, I'll be blogging at blog.zackshapiro.com. I hope to see you over there!

[zackshapiro]

My favorite habit: Write three positive things about today

I’ve been talking about this habit a lot recently and I thought it deserved its own blog post. It’s a really simple thing you can do to change how your brain scans the past. Rather than scan for negative, you’ll start scanning for the positive things, the little victories that you had throughout your day.

All you have to do is write down three positive things that happened to you that day.

In Evernote, I have a document called “Three Positive Things - December 2012” and in it each for each day, I have something that looks like this:

12/16

Matthew gave me a book on investing in the stock market and taught me a bunch

Brunch with Fabien, SheShe and Emily was a lot of fun

This was a nice, restful weekend

This habit comes from Shawn Achor’s The Happiness Advantage where he suggests tiny changes you can make to your life to dramatically alter your happiness.

I also use Lift to log and monitor each time I do the habit. I created a community on Lift which is growing quickly where you can join and get support from peers who are trying to start and continue this habit in their lives.

I log my three positive things every night or if I forget, first thing in the morning. I’m not too strict about when I write my three things down, as long as I do it.

In terms of habits, this one is pretty easy to start and continue. It’s one of my favorite parts of each day, I hope it can be for you too!

What are your favorite habits? Let me know on Hacker News!

If you enjoyed this post, I'd be humbled if you'd follow me on Twitter.

[zackshapiro]

A few weeks ago, Brad McCarty mentioned to me how much he loved his Svbtle blog and the platform itself. He just wished there was some kind of way to archive your posts.

So I wrote it that night and threw it on GitHub for any and all Svbtle bloggers to use. 

The 29 line Ruby script will save all of your posts to a svbtle_archive.txt file for you.

I also wanted to start adding some of my own, non-work code to my GitHub account and this seemed like a great place to start. If you'd like to improve upon it at all, feel free. Enjoy!

[zackshapiro]

Thank you

2012 was full of surprises and it pushed me way beyond my comfort zones. It was one of the hardest years of my life, as I transitioned away from college and school life and into the real world.

I started the year working at Path. When that didn't work out, I interviewed unsuccessfully at seven different well-known startups for business development or product roles. In March, I thought a lot about what I really wanted to do and started teaching myself how to code. This time I wouldn't quit.

I became an intern at TaskRabbit in June, got hired full-time in September and never looked back.

In the last year, I got out to San Francisco all fresh-faced. Made amazing new friends and solidified existing friendships. I have new mentors and a new direction as an engineer, a great girlfriend, and I'm happy.

So in no particular order:

Thank you to my parents, Devon, Mitchell, Steve, Victor, BL, BR, Yee, Dave, MVH, Brian, Nell, Leigh, Matthew, Jana, Rob, Josh, Jon, Lauren, Tom, Cesar, Marianne, Patrick, Matt, Danny, Jeff, Sarah, Amber, Josh C, Char, Benzer, Finkel, good friends in Boulder and San Francisco and anyone else who has been a part of my life this year.

Thank you for reading.

I hope you, your family and your loved ones have a happy and healthy holiday season and a wonderful new year.

Onward, to 2013. Let's go.

[zackshapiro]

I'm trying to be less hyperbolic.

I'm trying not to speak in hyperbole because I feel that the majority of our disagreements come from statements that mean to be everything though they never can be. I'm trying to avoid hyperbole in my life because a hyperbole is a lie - sometimes for effect, sometimes for art, sometimes because thinking the rest of a thought through is difficult and time consuming.

In Shunryu Suzuki's brilliant "Zen Mind, Beginner's Mind," Suzuki-roshi talks about controlling others and how it is impossible. The way we can control others' actions is to control our own, Suzuki says (I'm paraphrasing).

So it is with that thought that I'd like to try to be less hyperbolic in my own thoughts and speech. 

No more 'This is the best {noun} ever!'

No more 'That person is the funniest person ever!'

No more 'Oh my god, this is incredible!'

Or 'That event was the worst.'

Or 'This is the best way to write this code.'

Or 'The Republicans/Democrats are going to screw up America.'

Because none of those are true. 

Those statements exist to draw your attention away from the truth of each statement.

"This {noun} is very good."

"That event wasn't a good use of my time."

"You should write this function in this way because…"

"American politics is a pendulum that sways back and forth, it will all even itself out in time."

And so I hope to make this effort and if it interests you, I hope you will do it too.

To be less hyperbolic.

Because I believe it will make our large world, marginally better.

If you enjoyed this post, I'd be honored if you'd follow me on Twitter.

[zackshapiro]

How to Hack Any Application and Set Yourself Apart From Other Candidates

In the last few years, I've been thinking a lot about applications while applying to a lot of different things. Just a few years ago, I sent five applications to universities, hoping that at least one of them would let me in. Four out of the five did.

Last summer, I had the privilege of being a Summer Associate at TechStars in Boulder where I worked with twelve incredibly talented young companies for three months. I applied the year before and was turned down for the same position.

I recently applied for the second class of The Bold Academy in San Francisco and I got in. I'm incredibly excited to take part in Bold's journey to help people unlock their fullest potential!

In movies, characters going through the tense interview with a cold faculty member at a college who seemingly will decide their fate is commonplace. The university brings the character in to ask them questions and size them up before determining who gets in and who doesn't.

Yet for me and most people I know, we never had this experience. Most of us were a set of numbers, some extracurriculars, and proof that we could articulate ourselves in some essay format. 

Many other applications and their processes can be easily hacked, and that's what I want to talk about here.

How I got into TechStars and The Bold Academy

Every year, the Summer Associate position at the TechStars Boulder program gets more and more competitive. It's the chance to go through one of the top accelerators in the world and get an amazing education in all things startup. And the first time I applied, after the second round of interviews, I found out that I didn't get in. I was disappointed but I came up with a plan. 

I was going to meet and get to know all three of the Summer Associates for the summer of 2010, take them to coffee, develop those relationships, and let them know how badly I wanted to be in there next summer helping out and learning from the best.

I got to know Adam, Gregg and Al quite well over the next year. We developed genuine friendships and when it came time to apply for the Summer Associate position, they knew at least one of the applicants pretty damn well.

Fast forward a year and a half, I'm applying for The Bold Academy, Amber Rae's "life accelerator." I reached out to Amber with a few questions about the program to see if the program and I would be a good mutual fit.

Amber and I ended up jumping on Skype a few days after we first chatted on Twitter. A few weeks later we had tea at her house in Boulder the day that applications opened. I made a few suggestions about challenges that her upcoming group could take part in.  After that, we had a really good conversation about figuring out your life's purpose, past achievements and failures, and then we ate some of Amber's delicious baked apple slices. 

A few weeks and two parts of the application later, I found out that I'd been accepted into the next class of The Bold Academy. 

The Secret

The secret to getting into both TechStars and Bold was making myself human. So many people applied to both programs and never followed up, never attempted to make themselves more than an applicant, in the most basic form of the word. Gregg, Adam, Al, and Amber all got to know me, they all learned how genuinely interested and serious I was about the spot that I was applying for. 

If I were in their position, I'm guessing that it's a whole lot harder to deny someone you know, compared to someone that you don't.

Go forward and stand out on everything that you apply to. Reach out to those who run programs and those who help out, make yourself human and make it known that you really want to be a part of what they're doing. It's undoubtedly one of the best thing you can do to hack most application processes.

And regardless of the rules that they tell you about the application, always remember: There are no rules.

--

How do you set yourself apart when applying to things? Let me know over on the Hacker News Discussion

If you enjoyed this post, I'd be very humbled if you followed me on Twitter.

[zackshapiro]

The truth is in the "Fish"

(Photo Credit: Robin Sloan)

For years, I can't remember loving much on the Internet. I can count on both hands the things that I've loved, cited repeatedly, and told people were really important.

Yesterday, I came across one of these things (which I have since experienced three more times): "Fish," by Robin Sloan.

Fish is a meditation on what it means to love something on the Internet, a problem I've been thinking about for about two years now (but haven't articulated nearly this well). 

In Fish, Sloan argues that we never really look deeply into the things that we "like" or "fave," or share online, that we merely tell others "this is something that I enjoyed" and then we move on. How weird is that, right? At the tail end of my experience with this video/article/photo/blog, "I'm done here but I'm leaving this for you." Spend your time on it, my time with it has passed. And then we likely never return to that piece. 

The Internet has done weird things to our brains. So have follower counts and the ability to see how many people clicked the link to see this blog post. Vanity pageviews, vanity shares, vanity everything.

The point of this post is about Robin Sloan and his excellent and truthful meditation he entitled "Fish." All I'd like is for you to download it. Watch it. Experience it. I'm not sure what exact form of media it is but I really enjoyed it and I hope you do too. 

I'm going to go think about what it is I believe and believe to be true.

Please, take part of your day and experience Fish. Your future self will thank your present self. 

[zackshapiro]

Quick thoughts on the sea of To-Do list apps

I work really well off of lists. I love to make them and I love to plow through them. Most of the tools in the To-Do list market make me depressed though. We haven't even come close to figuring out how track and manage our lives, work and tasks effectively through software.  

Some quick thoughts:

I like that in Asana I can press enter and create a new task.

I like that in Lift I have a big button to press to mark that I've accomplished something.

I like in Trello the Doing, To-Do, Done columns (that they've created but I've arranged in that order). Dragging something between columns feels satisfying, like a micro-manipulation of the work I'm doing.

I like the feeling of seeing a giant list of things that I've done that day, but separate from what I'm doing, or still have to do. Those are different things and should be in a different list, not part of the main list of things left to do but visually represented as being in a different state of action.

I like that in Well, you can add an Instagram picture as the cover of a list. It gives a list some personality which usually has absolutely none. 

Clear had nice sounds and animations, giving life to all of this productivity management.

I'm very curious about what Mailbox is working on with their pivot of Orchestra. Orchestra was a well-done To-Do app, their voice recognition was decent. The app felt good; it felt progressive. 

None of these tools feel tailored for me though. They feel so general and impersonal. 

None, to my knowledge, let you easily export your data or import from another To-Do app. There's no standard file format for import/export (although I'm sure CSV would work).

Conclusion:

Maybe we need to pitch future To-Do apps for teams to use. Use it with friends. Use it for family. Join as a cluster. Social - but in the sense that my work and your work are tied together and we need to always be on the same page. When you check off an errand, I want to know. There's a give and a take to our work. But this all needs to have personality and feel like it was built just for me.

Which To-Do apps do you love (or hate) to use? Continue this discussion over on Hacker News.

I'd also be humbled if you would follow me on Twitter.

[zackshapiro]

A Cross-section of the Creative Process

(Photo by Craig Mod)

Our brains do this tricky thing. When they sense negative space, they fill that space with stories. And unfortunately, it seems as if the best things just appear out of thin air. So when your favorite band releases their latest album that absolutely blows you away, your brain tells itself that these guys must just have it and that the way you create things is totally different from the way that they do.

The comforting thing is, it's not. 

I love when companies like Apple release or leak prototypes of devices because you get some insight into the fact that the final product didn't just emerge from their brains, pristine and polished. The first draft of anything came out looking chunky and ugly. And then it was crafted and sculpted into something that people eventually appreciated.

The creative process is the silent, hidden foundation that lies beneath every product. To be great creators, we must understand that the process exists and happens to everyone. And that those that we look up to go through the same steps and have the same struggles.

Long before you ever play with a new app, there's a long line of sketches, designs, redesigns, dummy text, code written and code deleted. There are buttons that exist just to prove that something works before they're whisked away, never to be seen again. Your favorite software started off as a bunch of ugly ducklings. 

A few months ago, Craig Mod, formerly of Flipboard, wrote about how he created an eight pound book of nearly every piece he could capture of the creative process of Flipboard for iPhone: 

997 design comps in a shared folder, 9,695 git commits, a bundle of notebooks full of sketches, and dozens of photographs from launch night.

That's what it took to create a beautiful, simple news-reading app. I doubt many first drafts made it into the final product with nearly 1,000 design comps and a bundle of notebooks full of sketches. Those guys struggled for months to build something elegant and easy to use and this is what goes into it. 

It's fun when a cross-section of someone prominent's creative process comes out because it humanizes both them and the product. Flipboard suddenly turns into the product of a lot of good people working on a hard problem, rather than just the Flipboard app itself. Revealing the process shows that the product is the process, just at one particular stopping point.

It also shows that you can do it too. That the toils and problems that you face aren't unique. That all creators go through the same thing. 

We all struggle. We all bang our head against something that we can't quite figure out right now.

Because we get to have these a-ha moments. And that's the beauty of it all.

[zackshapiro]

for someone who wants to start learning about programming, where does one start? without going to school, is there any basic things one can learn on their own?

There absolutely are. I'm completely self taught. Check out my post, Want To Learn Rails? Start Here. Good luck to you!

Email me if there's anything I can do to help!

[zackshapiro]

Build what you want. Create from the heart.

In my life I've made a bunch of things. I've created and released a four iOS apps. I wrote, produced and directed a 12 minute documentary on Rosewood, an abandoned insane asylum in Owings Mills, Maryland. My intention with this paragraph is not to boast about the things I've done but to talk about how I see each of these in relation to creating things from my heart.

In my first semester of college, the professor of my Intro to Computer Science class gave us a very open-ended final assignment: create something useful with the concepts from this semester. We could make what we wanted with any language or technology.

I thought about the problems in my life and since I was an out of state student, I took the bus a lot from Boulder to Denver for concerts and from Boulder to DIA to fly home. This was Fall 2008, there were no iPhone apps or web apps for the bus system in Colorado, called RTD. So my final project was a simple one: six gigantic PDFs that I stitched together from smaller PDFs that I crammed into an iPhone app. The app was called RTD Mobile Bus times and showed me the schedules for just two bus routes. I made the app purely for myself because it solved my own problem. That summer, I released it to the public, selling it for 99 cents with resounding feedback, "Why are there only two buses in here?"

I took that feedback and went back to the drawing board, releasing Beeline RTD the next summer and Beeline RTD 2 the summer after that. I love those apps. I know they'll never be the next Angry Birds but I made them because I wanted them and it turned out that a bunch of other people did too. The first time I held a build of Beeline RTD in my hand, after getting it from my developers, I literally jumped up and down at the though that this app had come out of my head and I could now put it in my pocket and use it whenever I wanted. One of the most rewarding feelings I've found.

When I was 18, my senior project in high school was again, a completely open-ended one. I had to create a group of students and make something. Some kids went to Hawaii and did a report on the surf there, some kids worked in museums and wrote about their experiences. I made a documentary about Rosewood with my friend Zack.

Zack and I had been fascinated with Rosewood for years. We'd snuck around inside of its buildings late at night on weekends with other groups of curious 16-year-olds. We were obsessed with its architecture, its history, its soul. So we made a documentary from start to finish and to this day, it's one of the things I'm most proud of.

We made the documentary because we wanted it to exist, not because we cared what anyone else though of our idea. We loved those buildings and haunting ideas of ghost stories and things that went bump in the night. So while other kids used their senior projects to go on vacation, we ran through abandoned buildings with a camera, bringing what we wanted into the world.

And what I've come to realize is that each of these things that I create that I'm most proud of - it really comes from my heart; it comes from a piece of me which I think the general public would say is "weird." Apps for readers or public transit riders. A documentary about an abandoned insane asylum. These aren't mainstream things.

Ben Huh touched on this in his post, Here's to the weirdos:

And when I say “weirdos”...I’m talking about those who believe passionately in the world you want to build for them.

Choosing your audience limits the pool that sees your work, but it also sets you free. You know who you're going after now as much as you know who you aren't going after. Being comfortable that someone isn't going to like your post or your software is part of the game.

You know that thing that you want? Build it. Create it. Make it happen. Because even if you want some of your work to be incredibly popular, your audience has to start with a group of weirds who, like you, believe in the exact same thing and support you as you make it happen.

I'd love to hear your thoughts. Continue this discussion over on the thread on Hacker News.

If you enjoyed this post, I'd be humbled if you followed me on Twitter.

[zackshapiro]

So ive read your post about ADD and Programing, and i was wandering if you have any ideas for someone with severe ADD who has tried a couple of times to get into programing but keeps on failing. i know, love and have a strong passion for all things tech but i was never able to "get" the core idea of it. any advise ?

Take it slow, pick one language and don't let anyone deter you from that. Build obnoxiously small projects and then make the next one a little bigger with a new concept. Push yourself to try new things you've never done before. Put on some instrumental music and let yourself have good days and bad days. We all struggle and then we all get better. Good luck!

[zackshapiro]

Programming as a cure for A.D.D.?

I guess all my life I've had A.D.D. It's mild and never really precluded me from doing anything. But I don't think I've been able to be as effective as I want to be. I never noticed or accepted that I had mild A.D.D. until a few months ago and around that time, I started thinking about methods to work with it.

The A.D.D. brain is an interesting one. It's creative, often thinking down multiple paths around the same time. This can be good or really bad, depending on the context.

But I've noticed that my A.D.D. has gotten better ever since I started programming full time.

Most of the work that I did pre-engineering was done in Word, email or in person. With the first two, it was pretty easy to do that work without paying my full attention to it. I could write a paper for school and watch two football games at the same time. 

The thing is, you can't really write code without thinking about it. Most of the time when I'm writing code, I thinking about the information that I'm passing from one place to another, if my syntax is correct, if the data is in the right format and if it's as clean as I want it to be. I think a lot about writing tests to catch edge cases and how to refactor what I've already written to be more clever or concise. And it's really hard to do that with the game on in the background.

I think I stumbled on a really great way to address my mild A.D.D. When I code, I have to dive in deep. Coding requires my full attention and I think that my brain has started to reconfigure itself to optimize for long periods of intense focus.

When I notice A.D.D. rising, I put on my headphones, start an album from the beginning, make sure I know what the task at hand is and start by breaking that task down into smaller mini-tasks. From there, I know exactly where I am and what I'm doing next. 

Ruby on Rails. Zack on Rails. 

It's nice. I can let the A.D.D. run wild when I'm thinking about a problem or how to solve it but when I sit down to solve the problem, I force myself into that zone and try my hardest not to let anything in while I check mini-task after mini-task off on my list.

Some days are better than others but I think that since my primary job is to focus intensely, building software, my brain has started to realize that sometimes, it gets to calm down and just do one thing, instead of six.

If you have A.D.D. or thoughts on the subject, I'd love to hear about them on the Hacker News Discussion.

I'd also be humbled if you follow me on Twitter.

[zackshapiro]

A beginner's guide to Redirect and Render in Rails

When I first started learning Rails, it took me a few weeks to figure out that Redirect and Render did different things. I overlooked them and figured that I'd throw one into my controller as needed and everything would be handled. Tubes on the Internet are all the same, right? Wrong.

Let's start with Redirects. With a Redirect, Rails tells the browser to do a new HTTP request to that specific path. Your code stops running while your browser pushes you to a new page. With Render, you can load many different pieces of your view, from partials and error messages to forms or even entire pages, like a 404 error page.

In the code below, a user will create a new Lesson. A Lesson is like a tweet, it's 140 characters or less containing what they learned that day. If the Lesson is between 1 and 140 characters in length, @lesson.save will work successfully and a new entry will be recorded in the database.

After that, the app will redirect itself back to the root path where I display a running list of all of the Lessons created, sorted by date. When Rails does a Redirect, by default it's a 302 (or a temporary redirect) since your redirect only happens in certain cases, like when the app successfully submits and saves a Lesson. 

  def create

    @lesson = Lesson.new(params[:lesson])

    if @lesson.save 

      redirect_to root_path

    else

      render :new

    end

  end

But let's say that our little Lesson doesn't save. Bummer. Maybe you learned a lot that day. and couldn't fit it all into 140 characters. Maybe you just pressed return and submitted the form by accident. You've now bumped up against Render.

Render is great because it's so versatile. In this case, I render the new Lesson view. In my directories, the new Lesson view is located at /lessons/new.html.erb. Since I generated a Rails app quickly with a scaffold command, the code in that file is all pre-written for me by Rails to help out.

When Rails renders the new Lesson view, it will show me any errors that were made in the creation of my Lesson. It will also pre-fill the fields that a Lesson requires with the pieces that failed before so that I can reference the error for necessary changes that need to be made and make them directly below before I submit my new Lesson. That's pretty handy and all built straight into Rails. 

If you were to do a redirect_to root_path on the Lesson not saving, you wouldn't know why the Lesson didn't save, since in this code there's no messaging telling you one way or another. Since this is a simple application, I fork the user experience here but what I'd rather do is bring the user back to the same page as they'd see on a successful Lesson entry but with rendered errors related to their Lesson so that they could give it another try without adding more routes through the app's flow.

I hope this was helpful. If you have questions or comments, contribute to the discussion about this post on Hacker News.

I'd also be humbled if you followed me on Twitter.

[zackshapiro]

Forget the last one. Do the next one.

In high school, our lacrosse team had shirts and across the shoulders was printed a simple fragment of a sentence, "The next one."

The idea was simple: if you got a ground ball, get the next one. If you scored a goal, score the next one. If you did something good, don't dwell on it, do the next one.

Recently this notion came back to me, not to stay stagnant for too long and think about what I just did, no matter what it was. Appreciate it briefly, celebrate, then go get the next one. Go do the next one.

For me, this has been a powerful way to approach life and work. I wrote a feature I'm really proud of. I've never written that kind of a feature before. Okay. Write the next one. I just swam a mile. Okay. Swim the next one. 

Do. Accomplish. Pause. Appreciate. Do the next one.

[zackshapiro]

Want to learn Rails? Start here.

I’m teaching an online course on Rails on June 22, 2013. It costs $99 and lasts three hours. If you’ve always wanted to learn how to code, this could be your perfect excuse and introduction. Sign up now

As you learn any skills, your brain is constantly wiring and re-wiring itself, teaching itself to think and understand in the context of your skill. Learning how to code is no different. The way I think through a problem now versus the way I did six months ago is essentially night and day.

This post is about the resources that I used to learn how to code. This isn’t gospel; this are just what have helped me. Play with your process. Find what tools you can’t live without and what works for you.

The Rails 3 Tutorial - This is available online for free but I found it most helpful to do the book as a Kindle book on my iPad. I had my iPad open next to my laptop and I could only focus on the one page that was presented on the screen. You learn how to build an early version of Twitter with the book and it helps provide light on a lot of Rails basics.

I found this book to be the most useful when I came up with a tiny side project and did that alongside my following the book. I used the book as a reference material and applied those same concepts to my project so that I wasn’t only just following along, I was participating in another context and training my brain to think in a certain way.

Railscasts - There are so many tips and interesting new technologies demoed and explained. I got in the habit of doing random ones, regardless of their content, just to learn new stuff. The Pro plan is $9 per month and has updated code for older episodes and is even more valuable. I recommend it.

Stack Overflow - When you ask a question on SO, make sure you show them your current code, tell them what your goal is with the code. Tell them that you’ve done the work and research on your own and can’t figure out the answer and that any help they give you is incredibly appreciated. It leads to a lot of quality answers and much less “You’re new and stupid, get out of here” responses.

Find a technical mentor - One of the things that’s helped me a ton at TaskRabbit is having great mentors whose brains I can pick after I’ve exhausted trying to learn on my own. I want to thank Victor, BL, Steve, Loren, BR and Evan for being invaluable assets and devoting the time to teaching me how to be the best I can be.

Give yourself projects - No matter how small, make sure you’re building something that matters to you, even if it doesn’t see the light of day. I have a ton of files on my computer of Ruby projects that I built just to learn a simple skill like “this is how I submit a form and record a new Thing in the database” or “This is how routing and resources work together.”

Devote real time to it - Programming, I learned long before starting at TaskRabbit, isn’t something that you can get a lot done with only doing it for an hour a day. It takes two to four hours, I’d say, to make significant headway on fixing a bug or making a dent in a feature on my to-do list (at least in the beginning it did). Give yourself some time to get into a flow, start cruising and feel comfortable.

Celebrate every tiny victory - You’re going to be learning a lot really quickly. You’re going to be leaving a whole bunch of people in the dust who just say the want to learn to code but aren’t really doing it. Relish in the fact that you learned something new, regardless of the size of what you’ve learned. And there are going to be days where the code gets the better of you. Just come back tomorrow and be prepared to kick its ass.

Oh, and make sure you’re having fun.

I’d love to hear about your experience learning how to code or what has helped you. Contribute to the discussion on Hacker News.

If you enjoyed this post, I’d be humbled if you followed me on Twitter.

[zackshapiro]

Being honest with myself: my journey to learning how to code

For the past eight years I've been building things in one way or another. It started with blogs and podcasts and moved to things that were essentially ideas for the web and went nowhere. I didn't know how to stick with an idea and I didn't know that people built things for a living. In college, I met an early mentor who taught me about startups and told me that Boulder was chock full of them. Suddenly my web ideas started to feel less like impulses and more like ideas and even businesses worth pursuing.

In my first semester of college, I built and released my first iPhone app as a final project for a CS 101 class. The app was a bus schedule for Denver and Boulder that I built for myself, a dead-simple PDF viewer that exceeded my expectations after going on to sell about 1,200 copies.

It's been a consistent theme though to find other people to build stuff for me. Three of the four iOS apps I released in college I worked with others to build. The two web apps I worked on, I didn't write a line of code. After eight years of doing all of the non-technical stuff, I had to be really honest with myself.

My happiest moments were the ones where something had come out of my head and had been coded into some physical form. Not being able to build something - or at least make headway on realizing an idea through code - was really irking me and frankly, it was holding me back.

So I made a change.

Last October, I bought The Rails 3 Tutorial as a Kindle book and went through it on my iPad. Here's the strategy I used and it worked magnificently: Since it's an ebook, I could only focus on one page at a time. No leafing through the book to get to the parts I wanted. Patience. Learn each tiny piece and follow along. One page at a time.

Fast-forward five months. I had the opportunity to attend the First Round Capital BBQ at SXSW. There I met Brian Leonard, VP of Engineering at TaskRabbit. We chatted briefly about my background a possible engineering internship at TaskRabbit. After realizing the direction I needed to take - learning how to build - Brian was the first and only person I emailed. I wanted to get serious about building things in a professional capacity, not messing around with code behind closed doors.

In the middle of June, I started at TaskRabbit as a combination business development and engineering intern. I started by building internal tools, ways to visualize the referrals paths of users who came to TaskRabbit.com. After writing more code than I ever have in my life and coming home every day feeling like my brain had been wrung out, I stopped for a moment.

I realized that building software myself, crafting it day in and day out, made me the happiest that I'd ever been. I'd been completely honest with myself, in a scary sense, and started learning something intimidating but incredibly rewarding. In three months, I've made massive strides in my abilities to build things. I know I have a very long way to go and that I've only seen the tip of the iceberg; it's humbling.

There are a lot of opinions out there about whether you should learn to code or not. I'm not sure what's right for you, only you know that. What I can tell you is that the thing in the back - or maybe it's in the front - of your mind, that thing that terrifies you, that looks like Everest when you look at the whole picture, go all in and do that. Because the rewards of being honest with yourself are well worth the fear.

Any thoughts on learning how to code? I'd love your to hear them over on the Hacker News discussion!

I'd be humbled if you followed me on Twitter, too