How To Make It as a
First-Time Entrepreneur

How to Make it as a First-Time Entrepreneur

Vinicius Vacanti is co-founder and CEO of Yipit. Next posts on how to acquire users for free and how to raise a Series A. Don’t miss them by subscribing via email or via twitter.

The spread of the internet will put people into two groups: “People who tell computers what to do, and people who are told by computers what to do.” - Marc Andreessen

Hello-WorldFive years ago, I was firmly in Andreessen’s second group: the non-coders.

We had written an 80-page spec for a prototype and, since we didn’t know how to implement any of it, we handed it to an outsourcer. Six painful months later, we knew the outsourcers weren’t working out.

We were up against the wall and we decided the only way forward was for me to learn how to tell computers what to do. I needed to be in Andreessen’s first group. I needed to learn to code.

Since then, I started telling computers what to do. We went on to build Yipit and it changed our lives.

It’s abundantly obvious to me that teaching myself to code is the number one reason we’re here. Learning to code allowed us to build and iterate prototypes in days, not months.

It’s also one of the biggest pieces of advice I give struggling non-technical founders.

But, that’s actually something that has always bothered me at Yipit.

One of the core tenants at Yipit is that everyone should think and act like an entrepreneur.

But, how can they be successful as entrepreneurs without a basic technical background. I would not have been. If it’s the advice I give other entrepreneurs, shouldn’t I give it to people at Yipit?

So, we’re trying something new at Yipit. We want everyone to have the opportunity to learn to code. We want everyone to be able to tell computers what to do. We want to put everyone in the first group.

That might sound crazy and part of it is crazy. But, we’re not afraid to try things and, the further we get along with it, the more excited we’re getting.

What’s the practical benefit?

In finance, everyone learns accounting. It’s not because everyone is going to be an accountant but because it’s the language of finance. At a tech startup, code is that language. The idea isn’t for everyone to become a developer but for everyone to learn the language of tech startups.

It means everyone will start to get a better sense of what certain words mean: roll-outs, the build, breaking the build, commits, github, back-end, front-end, APIs, databases and more.

It means people will start to get a better sense of what’s hard and what’s not as hard.

It means that instead of people asking for things, they can start making those things happen. Anything from copy changes on the site, small bug fixes, writing their own reports, writing one off scripts to do their own analysis when excel just isn’t enough.

It could mean pairing with one of our more experienced developers on a new feature reducing the communication cost.

It could mean us moving our infrastructure into more of a service oriented architecture and having people work on their components without fear of bringing everything down.

It could mean hacking together quick tests and, when they work, bringing them back and having our more experienced developers build solid components.

But how exactly?

Several of our younger engineers came to Yipit with little to no technical background. And, during that time, our more experienced engineers have successfully been able to mentor them into becoming core contributors to our code base.

Along the way, we’ve built a curriculum. Each person gets paired with a more experienced developer and goes through the program:

  • We kick it off with a talk on the major components of the web stack largely based on the 6 things you need to learn to build your own prototype
  • We spend two weeks learning the basics of python via the excellent Learning Python the Hard Way
  • We then get a very basic understating of our web framework, Django, by working through the Django Tutorial
  • Everyone spends a day coming up with a super basic idea for a fun web app that they might use with their friends or family
  • We then spend the next two weeks getting practice building a web app by working through more Django tutorials including a todo, blog and calendar apps
  • Once done, they’ll spend two weeks building their own simple web app based on what they’ve learned
  • From there, we’ll spend some time learning the basics of systems work by getting their app deployed on Heroku, they can dive more into HTML/CSS and strengthen their knowledge of programming via Udacity’s course

The goal isn’t for everyone to become full developers but rather for everyone to learn the language of tech startups, to make better decisions, to become more self-sufficient, to truly become entrepreneurs within Yipit.

Interested?

If you’re smart, hard working and want to learn how to build things online, send an email to jobs at yipit dot com or go to our jobs page. We’re looking for new developers (no CS background necessary) and a data analyst for Yipit. In both positions, you’ll learn to code.

If you’re in finance and consulting and looking to break into tech startups, this could be a great opportunity to take the leap.

If other tech startups have tried this, we’d love to hear about your experiences. We’ll make sure to follow up a in a few months with the good and the bad that we’ve learned.

Think this is a terrible idea?

There’s definitely a chance that this isn’t a great idea. But, at Yipit, we are scientists and we try things. If it doesn’t work out like we hope, we’ll learn and iterate on the concept, just like we do our product.

Vinicius Vacanti is co-founder and CEO of Yipit. Next posts on how to acquire users for free and how to raise a Series A. Don’t miss them by subscribing via email or via twitter.

  • http://twitter.com/manish_reddy manishreddy

    Great initiative! I really love the idea of everyone understanding the basics of web at a tech startup. It makes a ton of things easier. How many hours are they putting in each week?

    Btw, your other article ’6 Things You Need to Learn To Build Your Own Prototype’ was really useful to me, when I started learning programming.

    • http://viniciusvacanti.com Vinicius Vacanti

      We’re doing about two weeks per bullet point above. People are spending both time at work and nights and weekends working through it.

  • pseudononymous

    Ok, so let’s say your whole content team learns to code and then wants a 40% pay raise to code. What do you do then?

    • http://viniciusvacanti.com Vinicius Vacanti

      At Yipit, people get compensated based on their contributions. If they start to contribute more, then their compensation will go up along with it.

      • http://www.facebook.com/austinhulak Austin Fösh Hulak

        This is a fascinating approach to compensation. Do you mean they are actually paid a commission on code commits, bugs solved, etc? If so how does that work? Or do you simply mean that the workplace is a true meritocracy and the larger contributors are rewarded appropriately? I guess what I am driving at is.. How do you determine who is contributing the most?

    • http://www.theroadtosiliconvalley.com/ Ernest Semerda

      lol but this sounds like your saying “I might have a problem if my employees start adding more value to the company”.. actually what will happen here is people with the right attitude will develop a new skill set and help the company accelerate. Retention & employee satisfaction rates will go up (ref Daniel Pink’s Drive research on what motivates us).. all I see is positives! The financial side will be offset by the company as a whole increasing in value and revenue.

      • http://viniciusvacanti.com Vinicius Vacanti

        exactly.

  • http://www.theroadtosiliconvalley.com/ Ernest Semerda

    I think you nailed it home with this “At a tech startup, code is that language.” .. and the finance comparison. So bloody true. It amazes me when people are in tech running companies and have no f**kin clue about tech. As you pointed out the value here is everyone in the company “will start to get a better sense of what certain words mean”. No more blank faces when tech buzzwords are mentioned.

    I could even see this benefiting the release of great code without QA teams. The non-developers (but tech savvy) could write unit tests to help test the code developers are pushing out. Sometimes the more business savvy will have a better feel/view of how the customers might use the product, thus empowering to write some unit tests to simulate this behaviour and ultimately testing for quality.

    Brilliant! Thanks for an awesome post. Really enjoyed this one.

    • http://viniciusvacanti.com Vinicius Vacanti

      Love the idea of non-developers writing the unit tests.

  • Nick Bauman

    The real analogy here is literacy in the middle ages. In the 1200′s, if you could read, you had a job for life. People would ask you to write letters for them, to read letters for them, to write down financial contracts, to make, explain or even promulgate enforcement of laws; even to tell people when and how to plant and harvest their food. A literate person would add to the economic viability of the place in which they lived.

    Today, people who can’t write code (98% of people) are the new illiterate.

    • http://viniciusvacanti.com Vinicius Vacanti

      Interesting analogy.

  • Kevin Codey

    I think the learning curve is too great. IMO you are better off with employees perfecting the job they already have. Productivity will most likely decrease because of the attention required to learn to code. At face value I think sounds great but in practicality I don’t think it will work. Can’t wait to see what the result is though! You got to where you are by trying new things, who knows what will happen here.

    • http://viniciusvacanti.com Vinicius Vacanti

      The learning curve is steep but I’m optimistic.

      • http://twitter.com/srikrishnang Srikrishnan Ganesan

        Instead of a full fledged curriculum, you can do just “We spend two weeks learning the basics of python via the excellent Learning Python the Hard Way” to start with. And then it should be based on what the person needs to help him/her in the daily job.
        I helped a content programmer+meta-data guy learn how to do macros, made him write a python script to rename files in a format he needed.
        All it takes is usually having a pressing need, and then the joy of solving it on your own takes over.

  • DemianBrecht

    I think it’s a great idea to have non-technical people familiarize themselves with the technical side of things. God knows I’ve dealt with my fair share of non-technical production types who, because of their lack of technical knowledge have made me want to bang my head against a keyboard until I see impressions of the keys on the opposite site. Having everyone be familiar with the tech side of things can definitely be fruitful in every work environment, startup or not. Why? You can all speak the same language (or at least variants of a common dialect).

    Now having said that, I think that’s where the line should be drawn. You want to learn to code and write utility scripts that helps you in your day-to-day as a non-techie? Awesome, I’m even happy to help you when you run into issues (mentoring is something that I’ve enjoyed for quite a while now). /However/.. If I run into code from a non-techie who

    a) Doesn’t understand basic engineering principles such as: /Understand/ the problem before you start solving it (research, prototype, design, implement, etc),

    b) Doesn’t understand the simple, yet immensely powerful usefulness of having a multi-paradigm language such as Python (I glanced over “Learn Python the Hard Way” and it doesn’t seem to cover it) and is implementing things in a pure OO manner because the websites they read told them to, or

    c) Doesn’t understand the concepts employed because they have little or knowledge of the underlying algorithms but still proceeds to make changes and commit them because they pass the unit tests, or

    d) (related to b)) Doesn’t understand the CPU and/or memory implications of what they’re doing because someone told them that splicing a list (i.e. my_array[:1024]) is a good idea, but don’t understand that they’re actually creating a new list, which can be a Bad Thing

    …I’m going to be angry. You wouldn’t like me when I’m angry ;)

    To be fair though, I’m not academically trained either and am a hacker and am a product of a) having an immense amount of passion for what I do and b) being incredibly lucky to have had the career path that I’ve had, so it’s definitely possible to get surprising results from otherwise unsuspecting company. However, no matter how inclined someone is to learn how to “code”, becoming an “engineer” takes time, dedication and isn’t for everyone (just as management or accounting isn’t for many engineers).

    TL;DR: IMHO, if you’re encouraging non-techies to eventually start committing code to your project, it’s likely a bad idea. The incredibly /good/ part of this however, is breaking down language barriers between tech and non-tech types. /That/ in itself is worth the work.

    Good luck.

    • http://viniciusvacanti.com Vinicius Vacanti

      This is a great point and something we will be very cautious about. We expect initial contributions on the fringes such that the more experienced developers don’t have to run into them.

  • http://www.justinmccandless.com/ Justin McCandless

    Great idea and I’m curious to see how it works out. I don’t care if my CEO isn’t contributing to the codebase, but it’s terribly inefficient (and frustrating) being told what to build by someone who doesn’t understand the implementation.

    • http://viniciusvacanti.com Vinicius Vacanti

      Completely agree on that frustration.

  • nishabatra

    I think this is awesome! As a former non-technical founder of a startup, I experienced so many of the same issues. I recently decided to shut my company down and am now teaching myself code. I couldn’t agree more!

    • http://viniciusvacanti.com Vinicius Vacanti

      Good luck learning to code! It’s a great decision.

      • nishabatra

        Thanks Vinicius. I’m also on the lookout for a new job and sent my resume in this morning… (hint, ahem).

  • evanish

    I’m curious how you think about time commitment?

    You have a pretty comprehensive curriculum that even if they went Full Time on it I would think could take over a month. Do you literally have employees stop work in their area of expertise (sales, marketing, etc) to do this full time or how do you break up the tasks?

    Also – do you have them work on a project or focus the curriculum towards something that would add value to their job (like a marketer working on your blog) or is everyone’s learning exactly the same?

  • http://twitter.com/bennyskinner Ben Skinner

    Vinicius. I love it.

    I’m a finance guy and a couple of years ago realised so much of what I was doing was dictated by software. After seeing way too many $1B+ portfolios being managed on Excel, I set out to teach myself to code, albeit in Ruby. It has been one of the most rewarding and empowering things I have done.

    I think it has given me a different perspective on approaching problems and improved my analytical skills. There is something special about writing a very concise method/function which is certainly transferable into many parts of finance.

    Yipit sounds like a refreshingly dynamic company worth looking at!

    Cheers
    Ben

    • http://viniciusvacanti.com Vinicius Vacanti

      That’s great that you start teaching yourself! Really helps to have a project in mind while learning. Find it’s the best way not to give up.

  • http://twitter.com/NeerajT4 Neeraj Thakur

    I like the processes you guys have implemented in order to teach the newbies!

  • Ray

    That’s a true can-do attitude… amazingly, refreshingly original, I’ve always hated job roles that are so specialized that you get yelled at for even being interested in a neighbor’s functions.