David was the epitome of success.

At the time, he was the chairman of the board of the company that I was interviewing at. Previously, he founded multiple companies that sold for hundreds of millions of dollars.  

I was incredibly nervous.

I had just gotten into web development. David would be interviewing me, and I felt incredibly inferior.

I sat in my car, nervously waiting for the meeting to start. I didn’t want to be late. So I overcompensated, arriving nearly an hour early.

I sat in my car for about 45 minutes. I drank 3 Monster energy drinks. Finally, with far more caffeine in my system than any doctor would ever say was safe, I forced myself to walk into the building.  


“Come on in,” David said.  

“We had a meeting with a bunch of extra Pizza.  Feel free to take some.”

He grabbed a slice himself for himself, doing so in the most affable way you could imagine. We chatted about business and technology for a bit. Then he fired up the web browser. My stomach felt like it was going to burst.

David pulled my web application up onto the screen. This was the first application that I ever built. All I could think about were all of the things that I wished I had done better with the application.

3 days later, a recruiter called me. She offered me my first job in web development.

How the heck did I get here?

Let’s rewind a little bit.  

People love talking about the moment that they landed their first developer job. But it seems like almost all of them skip the part that comes before they landed the job.

I want to tell you about what came before my first web application, the meeting with David, and the surprising job offer that came out of all of it.

So let’s do that.

It was my senior year of college.

I had a handful of opportunities to work at companies that I had interned for in college, but I turned them all down.

I eventually landed what seemed like the dream job: a remote contract gig programming with a small freelancing company. There was only one gotcha…. I wasn’t any good at it.

I worked more hours than I billed for, got very little accomplished, and lacked the oversight someone with my level of experience needed to achieve my boss’ goals.

So I started looking to branch out.

Ruby on Rails was fairly new at the time. I was interested. The founder, DHH, was an opinionated guy. Everyone was talking about him, and there was so much buzz around the Ruby on Rails community. I wanted to check it out.

I went to Barnes and Noble and bought the first book about Ruby on Rails that I could find. I picked that book because it has the coolest looking cover.

I got home, rifled through the pages, and noticed something labeled Chapter 0: Installing the Programs. How hard could that be, right?

I knew my way around computers. So I quickly went through the steps outlined in the instructions of the book. But surprisingly, I ran into some error messages in the install process. It was a little frustrating, so I decided to take a break and pick it up later.

Over the next couple of weeks, I tried for 20+ hours to setup my environment.

Although I was a power user of my computer, I didn’t have a strong handle on the command line or how programs were installed and run behind the scenes. And man, it seemed like MySQL was allergic to my computer.

I struggled through a ton of StackOverflow posts and tried to copy and paste anything that could possibly help me setup my environment. I felt like an idiot. I was bad at it and I knew it. But I wasn’t going to give up.

But after working through a ton of different resources (many of which I didn’t understand), I finally figured out how to setup my environment. It’s worth noting, that despite being totally new to web development, I had been writing computer programs for years. I also had a few other programming internships previously. Without these years of experience, it’s likely I would have given up.

But finally, I overcame it and was excited to actually dive into the world of web development.

I went through the first few chapters of the book.  I started going through the instructions the book laid out.  Step-by-step I was able to get a reasonable grasp of databases, controllers, views, migrations and many of the most important aspects of web programming.

In the process… I had an app idea. And I thought it was a pretty awesome app idea.

Here’s the backstory.

Craiglist was pretty popular at the time. And my roommate was looking to sublet his apartment. I decided that I should build an app that would showcase our apartment in a unique and beautiful way. My plan was simple. We’d link to the app from a post on Craigslist, and the sublet offers would start flowing in. I bought the domain for the project, took the best pictures I could of the apartment, and wrote up an awesome description of all the cool features that it has to offer.

The only thing missing: the technical skills I needed to make my idea a reality.

I decided to just start trying stuff. And it was hard. I still remember the huge mistake that took me hours to figure out. I called a database field name type. It turns out, the field type in Rails is actually used for a very advanced feature that I was unaware of at the time. I spent two weeks trying to figure out the problem. I had no idea what was wrong in my app. It was bad, which made me feel like I was bad. But I couldn’t understand why.  And I wasn’t going to give up.

Finally, I tried the exact same steps again. This time with a different, but similar field of post_type. Strangely, it worked seamlessly. I discovered that there was an advanced feature supported by Rails known as “Single Table Inheritance.” Not knowing about this was what held me back. So once I identified it, I was able to learn it and move forward. My project was slowly starting to come together. This was very exciting.

I could access the application from my personal computer, but I wanted to be able to access the application from anywhere on the Internet.

This was before there were companies like Heroku that made it easy to do this. In order to get my application live, I had to learn about hosting, servers, Apache, and something called Mongrel.  

This was all way outside the scope of the book that I bought. So I turned to the web, teaching myself the bare minimum of Linux, Apache, weird XML configurations, and Mongrel.

I struggled to get the entire setup working, and I spent weeks working through it.  Servers were more complicated than I ever anticipated, and getting it up and running was one of the most challenging things I’ve ever run into in programming. I hacked together some solutions.

I tried a lot of different steps to get my application up and running. Finally, I got my application running on a server that I was renting from a company. I didn’t fully understand how it all worked, but it was working and I was closer than ever to finally finishing the app. Still, I thought that the app was pretty bad, even if I was making progress.  

Over the next months, I added features to the application. I kept updating the app and making small improvements along the way. Things got easier. I got more of a rhythm.  I started to see how the whole thing was fitting together. And when I wanted to add a new feature, I was able to build a plan of attack to make it happen.

Eventually, the app even served its original purpose. We posted it on Craigslist, some people clicked through to it, and we were eventually able to sublet the apartment. This made me feel cool. But I still felt like my app wasn’t really that great.

Nobody would have described my app as “well architected.”

It was clear that there were a lot of areas for improvement. But I kept building this app out, long after we were able to successfully sublet the apartment. I kept making improvements and spending time on it.

While this was all happening… I became fed up with my consulting gig.

One Saturday, I sent out over 100 job applications. I got a handful of responses, including one from David’s company.

Here’s what he said when I showed him my app during the interview:

“That’s neat that you took the time to build that.”

He didn’t glow over it. But he was impressed that I decided to build something from scratch and improve it over time.

As bad as I thought the app was, it was still proof of the fact that I was a developer that was capable of building my ideas and adding value to a company.

This is an essential lesson for any beginner developer.

If you’re trying to get into programming, two things are most likely true:

  • You are a highly achieving individual. If you weren’t, you wouldn’t try to learn something as challenging as programming in the first place.
  • Your output will be below your standard for quite some time. And that’s ok.

When you first start, you’re not going to be very good. You’ll try to learn complex concepts and teach yourself things to build the ideas you have, but the stuff you build won’t be very good. And you’ll know that it’s not good because you have good taste.

This causes a lot of people to give up, and they never reach their “meeting with David” moment.

Don’t let that happen.

Instead, take a step back. Recognize that the only reason why you might feel like a failure when learning to code is because you are an extraordinary person. If you do so, then you’ll give yourself the opportunity to achieve what you want through code.

The path to becoming a self sufficient developer, who is capable of solving the problems in their way and landing a jobis very different than what you might be imagining. It’s messy.  It’s frustrating. It makes you doubt yourself. And it requires you to lower your standards in order to gain the necessary momentum to keep going. I went through all of these things.

In fact, the key to getting through it comes down to 3 key mindset changes:

  1. Understand that coding is about making constant improvements. You’re not building a car that can’t be fixed (pretty much)  once it’s shipped. You’re building software, which can be updated whenever you want. The original version of my first web application worked, but that was about it. The second version looked better. And the third version had some nice features. I kept making it better as time went on, and that made all the difference in helping me land a job that I wanted.
  2. Know that programming is a lot different than learning things in school.  It doesn’t involve knowing all the answers, and you can’t expect to be perfect throughout the process.
  3. Recognize that the only way to get better at programming is to work with stuff that you don’t know. You level up by working right on the edge of your comfort zone. This is where you will make the most mistakes, but it’s also where the real learning happens.

Once you do these things, you’ll be ok with pushing out your own first web application, which I can guarantee will not live up to your highest expectations.

Being ok with that is one of the most important steps you can take on your path to learning to code.

Want to start building stuff with code? You can do it in our free, 2-week, no-strings attached intro course here. 

Recommended For You

One thought on “The Surprising Lesson I Learned From Building My First App

Leave a Reply

Your email address will not be published. Required fields are marked *