I’m a strong believer that with enough effort, anyone is capable of learning the skills necessary to start a company. Whether you’re rich or poor, whether you go to Harvard or a middle school in Zimbabwe, whether you’re 22 or 44, I believe you are capable of learning what it takes to successfully start your own business.

In this post, I’m going to spill out as many resources as I can related to design, development, and distribution/analytics (i.e. the three D’s), all of which are critical to startups. I don’t claim to be an expert in any of these fields, so take my advice with a grain of salt.  My main goal is to help you get off the ground and offer you the tools to start learning on your own.  Most of the content will only be applicable to web and possibly mobile products.

For those of you non-techy folks, this might be especially useful so that you can stop worrying about getting a technical co-founder and start building things yourself. Even if you want a technical co-founder, it will likely be easier once you’ve demonstrated some technical ability or some competence in these three areas that a techy person would rather have someone else deal with.

Feel free to suggest other resources. If you don’t find what you’re looking for here – Google is your best friend.

Design

Start with a problem that you’re passionate about solving and brainstorm product concepts that could potentially solve this problem.

A great way to brainstorm and solidify your idea is to start wireframing your application using a tool like Balsamiq or Pencil. Wireframing takes no time to learn and lets you quickly mock up what you envision your concept to be. This allows you to quickly get feedback on your concept from friends and potential users and seamlessly collaborate with someone on the initial design. The wireframe is a great way to get started in talking to customers, via customer development.

The “low-fi” nature of the wireframe also lets you focus on the functionality and flow of the app without getting distracted by aesthetics like color and typography.

If Balsamiq ends up not working for you or you’d like to try something else – here are 50 other tools, resources, and Photoshop web templates: http://www.smashingmagazine.com/2010/02/05/50-free-ui-and-web-design-wireframing-kits-resources-and-source-files/

Once you’ve gotten feedback from potential users and you’re happy with your wireframe, you’ll want to refine your design using a tool such as Photoshop.  This is where you start designing how exactly the app will look like. You have two options:

1. Take a stab at learning design on your own. Get inspiration from products/sites you admire. See what you can do in Photoshop with some trial and error. You may want to start by tweaking Photoshop web templates (see above).

Take a look at these resources if you’re interesting in learning:

• A book to learn basic design thinking and user experience: http://www.amazon.com/gp/product/0321534042/
• UI elements you can use in photoshop: http://acrisdesign.com/2011/07/33-free-and-pixel-perfect-ui-elements-psds/

Design inspiration:

• http://www.smashingmagazine.com/the-smashing-network/ - IMO one of the best design resources to start with for articles and inspiration related to design as well as HTML/CSS.
• http://dribbble.com/  – A place where awesome designers show off their portfolio. Great for inspiration for logos, buttons, any UI elements, and pretty much anything.
• http://uxmovement.com/ - Great focus on UX.
• http://webcreme.com/ - Exceptional site for more inspiration.
• http://freelanceswitch.com/working/34-places-to-get-design-inspiration-online-and-off/ - A bunch more links.

2. Get someone else to do it. If you’re serious about building your web app, but have no interest in learning design on your own, find someone to help you! Ideally you have friends/colleagues that are capable of helping you with design. If not, you can always outsource and buy a design off a site like 99designs.com to get you started.

Front-end Development

As a studious college student, I’ve always been used to depending on books as my main source to learn new subjects. As I’ve grown as a web developer, I’ve realized that coding is best learned by doing. I’ve found that I learn and master concepts much more quickly when I’m experimenting and failing on the keyboard rather than being nose deep in a book. As scary and difficult as it might sound, if you really want to learn, put that programming book down and start coding now.

The good news with front-end development, is that there isn’t much to it (at least to start). Front-end development deals mainly with the look of an app rather than the complicated functionality. To start building a web app, all you need is to open a text editor (even notepad would do, but go and google around to find a better one), slap some HTML code on it, rename the file extension to be .html, and you have a web page!

For your web app, start with HTML, the basic structure of your web app. You can think of HTML as sort of the skeleton–it is extremely important in dictating how your web app is organized, but it has less to do with your outward appearance. You will later use CSS (cascading stylesheets) to deal with the actual styling of your app.

Walk through an HTML tutorial like this one to get a very basic understanding of how the language works: http://www.w3schools.com/html/default.asp. You don’t need to go through every chapter; only the first several pages are really necessary. I recommend having a text editor open and trying out the exercises yourself.

The beauty of HTML is that there is little to memorize or understand, as there are only a handful of tags you need to know. Read through the tags to have an idea of each tag’s functions: http://www.w3schools.com/html5/html5_reference.asp.

After you’ve gained a very basic understanding of HTML, get to know CSS in a similar way: http://www.w3schools.com/css/css_intro.asp. Again, keep a text editor open to follow along and try everything. Play around with HTML tags and CSS properties to see what they all do in the browser.

There are a lot more things to know about in CSS, but when you start coding in it, you’ll want to spend most of your time googling for specific answers/tutorials rather than trying to memorize everything. For instance, want to learn how to make rounded corners? Google “how to make rounded corners css.” Many times, it’s that simple.

For supplemental help and extra confidence, you can pick up a book like this one as a reference. However, you can move on without it (like I did).

Now that you’ve gotten a basic understanding of HTML/CSS, you can move on to start building a whole web page. Walk through this tutorial to understand some of the latest features of HTML5/CSS3 and most importantly, learn about the process and thinking behind structuring a web page.

At this point, you should have at least a reasonable amount of confidence in how HTML and CSS work, and how you might be able to put up a simple web page. It’s natural to feel pretty shaky, but I would continue to dive deeper in the code. If you have a PSD/design that you’d like to finally turn into a web site, I think you’re ready to start taking it on. There are plenty of PSD to HTML tutorials out there, but this is just one of many decent ones: http://designinstruct.com/web-design/code-a-vibrant-professional-web-design-with-html5css3/

To make your web app actually functional, you’ll need a more complex scripting language – Javascript. Since you’re probably new to programming if you’re reading this, it’s probably best to stick to the simpler UI stuff in JS by taking advantage of awesome frameworks that do the dirty work for you. The most popular of which is http://jquery.com/. There is a massive variety of things that you can do with JS and jQuery, so going with a specific tutorial may not cover all your needs. jQuery has some of the best written documentation I’ve seen, so simply searching around the documentation for things you’re trying to do will get the job done for most of your javascript UI needs. It is difficult to take a deep dive and master javascript without strong fundamentals, which I discuss in the next section.

More front-end resources:

• Check out any of these tutorials aggregated by Mozilla to pump up your HTML/CSS/Javascript confidence and skills: https://developer.mozilla.org/En/Web_Development/Introduction_to_Web_development
• To take your Javascript skills to the next level, check out this book: http://shop.oreilly.com/product/9780596517748.do
• When you actually launch your site online, unfortunately not all browsers will be friendly to your code (*cough* Internet Explorer). You need to do cross-browser testing to make sure that the experience in each browser is consistent. Check out these tools for an easy way to see how your site looks on different browsers: http://www.smashingmagazine.com/2011/08/07/a-dozen-cross-browser-testing-tools/.
• The above is a good start to cross browser testing, but to do thorough testing, you’ll need something a bit more complex–virtual machines that run different operating systems (Windows/Mac OSX) and different browsers. This is a great overview of such tools: http://coding.smashingmagazine.com/2011/09/02/reliable-cross-browser-testing-part-1-internet-explorer/
• As you practice your CSS, it can be quite messy and tedious at times. You can explore a couple powerful CSS frameworks that are rising in popularity to help you write better CSS: less and sass. There’s a great debate on which is better, but do your own homework to figure out your preference.

Back-end Development

Back-end development (ruby, python, java, objective-c, etc.) is necessary if you want to store data and make your application truly powerful. A lot of the functionality you had in mind for your application will probably be in the back-end side of things. It takes a lot more time and commitment to pick up as a beginner programmer compared to front-end. I definitely recommend learning the front-end before the back if you don’t plan on being a hardcore developer and/or if you’re brand new to coding.

With that said, there are awesome resources out there to help you on your quest. To learn the basic fundamentals of programming, I suggest a beginner’s course. For a thorough understanding, I think it’s an invaluable investment to take free online CS introductory courses such as Stanford’s CS106A and B: http://see.stanford.edu/see/courses.aspx. These courses will teach you the basics that will give you enough knowledge to comfortably tackle most programming languages and books. I believe a course like this or your own university core CS coursework is a worthwhile investment if you’re serious about learning how to code.

If you’d prefer a quicker, less thorough route, there are other great courses such as: http://learnpythonthehardway.org/. I have not taken this course, but I’ve heard rave reviews about how it’s a great starting point.

After you’ve gain a solid grounding in programming, it’s time to pick a language and potential framework. That’s a tough cookie as there are tons of viable options, each with their own pros and cons.

For mobile apps, it’s easy. If you want to make iPhone apps, objective-C. If you want to make Android apps, Java. Stanford offers a great free course on iPhone development: http://itunes.apple.com/itunes-u/iphone-application-development/id384233225#ls=1. You can probably find similar courses and tutorials (albeit not as thorough) for Android out there with a little Googling.

For web apps, it’s complicated to pick a language. Ruby and Python are increasingly becoming the most popular for new web apps. PHP, Java, and others are still pretty popular for web apps. Each language has special frameworks with many helper functions, the most popular of which are Ruby on Rails (although I recommend checking out the simpler Sinatra framework to start out with), and django (Python). Do your research and figure out what most interests you and suits your needs. A few languages have fun tutorials to check out as a way to introduce you to them such as tryruby.org and railsforzombies.org.

Other resources:

• Check out http://www.udemy.com/ for worthwhile programming courses (including Learn Python the Hard Way, discussed above)
• http://stackoverflow.com/ for all your programming questions
• reddit.com/r/learnprogramming for a friendly community to get help
• If you’re on Windows, it is highly recommended that you move to a Unix platform like Ubuntu: http://blog.sudobits.com/2011/04/23/how-to-install-ubuntu-11-04-from-usb-or-cd/. You can dual boot your computer to load Ubuntu when you want to code, and windows for everything else (if you still want to use it). I can tell you from personal experience (and from many others’ experience), coding in Ruby in Windows is a pain in the ass. Other languages may have similar issues. Along with being a great programming environment, everything in Ubuntu is pretty much free, it’s more secure, and it’s fairly simple to install and use. If you’re on Mac, you’re probably fine, but Ubuntu and other Linux distros are options worth exploring .

Distribution/Analytics

Unless you’re incredibly lucky, you’re going to need figure out creative ways to drive traffic and get users to your web app. You should learn the basics of web analytics to understand what metrics you need to improve in order to meet your goals.

A great starting point is Dave McClure’s AARRR metrics: http://500hats.typepad.com/500blogs/2007/06/internet-market.html.

To get your hands really dirty in learning sales funnels and marketing channels, you’ll need to read David Skok’s blog: http://www.forentrepreneurs.com/.

A great way to drive traffic to your site for free is by getting high ranks in Google searches through SEO (Search Engine Optimization). Some sites may even depend on most of their traffic from SEO. Learn the basics: http://www.seomoz.org/beginners-guide-to-seo. Check out the other articles on SEOMoz to get a deeper expertise.

A big buzz word surrounding startups is “viral.” A common misconception is that you can turn any app into a viral app or depend on it as your main source of traffic. YouTube and Zynga are perfect examples of driving ridiculous amounts of traffic through virality, but they are the exception, not the rule. Don’t expect your app to go viral. However, you still have a decent chance of getting significant traffic through virality optimizations. Gain a basic understanding through one of my old blog posts: http://www.trueventurestec.com/2011/07/14/virality-for-zombies/ and get in depth lessons through David Skok’s posts. After you understand how virality works, the key to optimizing it is to give the user a compelling reason to share something in the simplest way possible.

Other resources:

• For solid examples of how you can practice some of the optimizations (A/B tests and the like) discussed by Skok and McClure, check out Ash Maurya’s blog: http://www.ashmaurya.com/
• Neil Patel has entertaining and extremely useful posts on marketing and analytics like this one: http://www.quicksprout.com/2011/09/08/21-big-marketing-ideas-for-small-marketing-budgets/
• Sean Ellis has excellent startup marketing posts: http://startup-marketing.com/
• Here is a list of other great distribution blogs: http://www.golocal.com/seo-articles/what-really-are-the-top-seo-blogs-a-post-from-someone-who-reads-way-too-many-of-them/
• And of course, the KISSmetrics blog has great guest bloggers that discuss analytics and distribution: http://blog.kissmetrics.com/

Misc startup stuff

• Paul Graham has a ton of amazing essays on startups, like this: http://www.paulgraham.com/start.html
• The Venturehacks blog offers invaluable resources on raising capital that are highly respected (hopefully I will get to practice such advice one day : http://venturehacks.com/
• Eric Ries, the guru behind the lean startup movement, has a blog that is a must read: http://www.startuplessonslearned.com/
• Steve Blank has great general advice on entrepreneurship and building something that customers actually want. Check out his posts on topics like building a web startup, the lean way: http://steveblank.com/2011/09/22/how-to-build-a-web-startup-lean-launchpad-edition/

Jeff Clavier
Last week, I got the chance to sit down and chat with Jeff Clavier, founder and managing partner of SoftTech VC (some of their representative exits include Mint and Tapulous). Before diving in, I want to give a shoutout to Lionel Vital for being totally awesome and setting this meeting up! So Jeff ran us through his background and told us the story of how SoftTech VC was founded, then opened the floor to questions. In the ensuing discussions, Jeff summarized three rules that he has found to be governing pillars for entrepreneurs and venture capitalists alike. The 3 Ds, the 3 Asses, and the Life Is Too Short Rule.

The 3 Ds: Design, Development, Distribution
The 3 Ds rule has to do with the core business processes of web 2.0 entrepreneurship. Design, development, and distribution (the 3 Ds) are the three elements that Jeff believes make up the foundation of web 2.0 startups and thus the core of the perfect web 2.0 startup team. Design refers to product design, development to software development, and distribution to, well, distribution of the product into consumer hands. Jeff also says that three is a good size for the founding team: one is too lonely, two is okay, but three allows for great specialization. However, these three elements do not necessarily have to be divided into three founders; sometimes, one founder possesses all three. The important thing is to make sure that a web 2.0 startup team has strong competencies in each of the areas.

The 3 Asses: Smart-Ass Team, Kick-Ass Product, Big-Ass Market
The 3 Asses rule is Jeff’s summary of how he evaluates startups. The ideal investment is a company with a smart-ass team, kick-ass product, and big-ass market. In addition, the ‘smart-ass team’ part is by far the most important. However, the evaluation process is never as simple as sitting in on a pitch and checking off 3 boxes. Jeff admits that it’s oftentimes more art than science, and that the best way to think of it is through a scale analogy: every positive factor weighs in on the scale until a tipping point is reached and investing begins to feel right. Something along the lines of ‘do this for long enough and you’ll know it when you see it’. The 3 Asses rule helps highlight specific factors that weigh in more than others, and once again, the smart-ass team is the number one most important factor by far.

The ‘Life is too short’ Rule
This one blows me away with its omnipresence. So many entrepreneurs and VCs I’ve chatted with this past summer have brought up this rule in one form or another. The rule is pretty literal: when considering an action, remember that life is short. With this in mind, decide on what you want to do. A common extension of this rule is ‘Life is too short to work with assholes’; for Jeff, it is “Life is too short to invest in assholes.” He stressed the importance of this rule and that despite its nebulous nature, it comes into play quite often. Many times, the question of “do I want to spend 5 years of my life working with these guys” trumps the question of whether the investment will make financial returns. Jeff emphasized that despite the possibility of asshole teams generating incredible returns for investors, he has never regretted turning down a deal on the basis of the ‘life is too short’ rule.

Fin
The chat with Jeff Clavier was an awesome close to an unforgettable summer. I will be missing California/startup/TEC life. Thank you True for an incredible 3 months!

TEC has come to a close, and I’m now in my first week of classes at Yale. In the three short months since the program began, it’s incredible how much has changed, and how much those changes are a direct result of my experiences with True and Schematic Labs in San Francisco this summer.

Just like anybody else starting their junior year in college, I’ve been thinking a lot about what I want to do when I finish school (and even before that), but even as I ask myself that question, I have a feeling that I already know the answer.

Before this summer, I hadn’t really done much of anything related to entrepreneurship. This semester, I’m working on starting an Idea Institute as a branch of the Yale Entrepreneurial Society, I spent the weeks after the TEC program in the final stages of launching a microfinance nonprofit in Arizona (my hometown), and right now I’m working on building an application that will help people focus and be more productive through the application of feedback loops. My major is Economics, but somehow my schedule includes a class on Law and Technology, Introduction to Computer Science, and a seminar on the legal aspects of VC and startups.

In short, I feel like all my energies are focused on innovation and technology, and it’s no coincidence that this is all coming after my summer with True in San Francisco. The lifestyle, the energy, and the pure excitement of startups and venture capital couldn’t have been revealed in a better way. I met people I never would’ve imagined I would get a chance to meet; I learned more than I ever could have expected; and I experienced some of the best summer months I could hope for. Not to mention that everyone I met at True, and the other TEC interns, are some incredible people that I know I’ll stay in touch with, and see again soon.

Thanks for an amazing summer, True, and I hope to be back soon.

tl;dr

I recently had the opportunity to meet with Alex Moore, the founder and CEO of Baydin. Baydin, which means “foretelling the future through magic” in Burmese, is the company that brought Boomerang for Gmail and the Email Game into the lives of all of us who struggle every day to fight back the incessant flow of email into our inboxes. Alex’s motivation for starting the company was motivated by a predicament that many students and professionals face: every day, he would go into his office and sit down at his desk ready for a day of work, only to find himself still dealing with emails even two or three hours after arriving. The deluge is constant, and it’s easy to become overwhelmed or lose track of important emails. The products that his company has created are designed to make the process of dealing with emails as painless, efficient, and fun as possible.

Alex never thought much about entrepreneurship until his fifth year at MIT, when he was pursuing his Master’s degree. One weekend that year, the Alpha Delta Phi fraternity hosted an event in a mansion that was more or less an entrepreneurship boot camp. Most of the 40 or so people there had never even thought about starting a company; the culture at MIT then was very focused on getting a job with a big company. But at the end of the camp, which essentially consisted of “make up an idea and think about how to execute it”, the people leading the camp told all those present that all they needed to start a company were these very same ideas that they came up with that weekend. And now, 8 of the 40 that were present are still entrepreneurs in some capacity. Alex is one of them.

Most had never even thought about starting a company – but at the end of the camp (which consisted of ‘make up an idea, think about how to execute it’) they said, look, you don’t need much to start a company, just these ideas. Now, 8 of the 40 that were there are still in entrepreneurship

At the time of his first real exposure to the idea of starting his own company, Alex still didn’t think too much of it – he had a job lined up, and was already set to start his career. After graduating, he started work at Analog Devices, and was rising fast. By year three, though, he was starting to notice a real problem. Every day he would get in to work, and 2.5 hours later, he would find himself still in Outlook dealing with emails. Between product releases, troubleshooting, and general work-related communication, it became overwhelming, and he was worried that as he stayed in the company and rose higher, 2.5 hours might not be where it stopped.

A great idea for a business comes from having a great problem to solve, and this was definitely a problem. At the time, Alex had no kids and no mortgage – as he puts it, his only liabilities were his two pet rats, and he could scrounge food out of a dumpster for them. There opportunity was there; it was time. In 2009, Alex left his job and started Baydin.

When I asked Alex about how optimistic he was from the outset, about building a successful product and raising funding, he told me that he wasn’t too worried – with a great product, a solid market, and hard work, he felt that things would be alright. But early on, he learned that life sometimes isn’t as meritocratic as it should be. Baydin’s first product, Unsearch, provided users with automatic access to relevant emails and documents when replying to an email, without any explicit searching. It was a great idea with a lot of potential for success, but he soon found that access to high-level privileges by IT departments was hard to gain by three guys in a garage. Those kinds of relationships were a prerequisite to the product’s success, and they didn’t have them. Xerox came out with a similar product a year later, and Xerox’s pre-existing relationships immediately created more interest among CIOs and IT professionals than Baydin had been able to generate.

But, as Alex says, sometimes startups will survive like cockroaches, and his company kept going. His team changed, though it stayed small, and they moved on to the next wave of email-related products: Boomerang for Gmail and the Email Game. Today, these are the company’s main products – and they are amazing.

Boomerang for Gmail is a service seamlessly integrated into Gmail that allows users to “boomerang” outgoing or incoming messages into their inbox at a specified time. This is incredibly useful in a variety of contexts. For example, when scheduling a meeting or asking somebody for feedback, sometimes they will never get back to you, and it can be difficult to remember to follow up. Boomerang has an option to boomerang the message only if the email is never replied to, or whether or not there is a reply. This also comes in handy when there are emails you want to deal with at a certain point, but not right now – instead of letting them build up as unread emails in your inbox, they come back to your inbox at precisely the time you specify. Boomerang also has other useful features, such as the ability to send mail later and specify what should happen when a message is boomeranged.

It is customizable, extremely user-friendly, and has become such an intrinsic part of so many people’s systems of dealing with email (including my own) that when Baydin exited the beta and started charging for the service, people were ready to pay the $5/month without hesitation.

The Email Game is another successful product that is both functional and fun. The name explains it all: it turns your inbox into a game, rewarding you points for responding quickly and detracting points for when you skip a message or take too long, forcing you to be extremely efficient in getting to Inbox Zero. Of course, Boomerang is also integrated into the game, so you can go back to messages later if you don’t want to deal with them at the time.

Clearly the path to launching a company, raising funding, and making successful products was not without challenges. Alex, like many other successful entrepreneurs, took on the risks of leaving a stable job, starting a company, and evolving when first product didn’t work out. When Boomerang for Gmail launched, the service required access to Gmail account information, and even though they took every possible security measure, Alex said that he still had nightmares every night that a day would come when they got hacked. But they were very, very careful, and set up a system such with the highest level of security (integrating Google’s standard secure API and no passwords stored anywhere), and their dedication and precautions paid off: that day never came.

I would encourage readers to try Baydin’s products; I personally feel that they really change the way people handle email, and can help you become much more organized and effective if used consistently. And also, take inspiration from Alex when creating your own products: create something that solves a problem you have, and a problem that other people probably have too, and you could end up changing the way people do things every day of their lives, just like Baydin has.

In my first blog post I noted that my main objective for my time at Kiip and TEC was to learn as much as I possibly could. Mission accomplished. More than accomplished. I feel like I learned more this summer than in a whole year at school. So what exactly am I taking away? There were a lot of little bits of wisdom I picked up here and there, but I think the following are the most universal. Simple, and no-brainers, perhaps, but super important in my humble opinion.

Pick up the phone

I wrote a few blog posts about my experience working in Business Development at Kiip and what I had learned along the way. I spent a lot of time doing outreach to developers via email, but it wasn’t until the end that I finally manned up and got on the phone and talked to people. Was it nerve-racking? Sure, especially given that the first call was to a thirteen year-old super-genius developer =P. I’m naturally a pretty shy person, but I realized that although phone calls can be intimidating, they are so much more efficient–and personal–than endless email threads. Lesson learned.

Set measurable goals for yourself

When I started working Biz Dev at Kiip, I kind of just attacked it without any real, set game plan. I think that doing it this way helped me to learn a lot by having the freedom to explore a number of different approaches, but keeping track of my progress wasn’t as productive or useful as it could have been. Were I to have set goals (e.g., sign X amount of developers over X weeks) I could have looked at my accomplishments at the end of the set time period and said “Awesome! Maybe I set the bar too low?” or “Well, hmm. Either the goals were too lofty, or I’m not doing something right. How can I change and improve this? Who knows this stuff and how might they be able to help out?” Which brings me to my next point:

Ask for help whether you need it or you don’t

I worked with some really incredible and talented people during my time at Kiip, and while I learned a lot by asking questions, I almost wish that I had bugged them even more. I can’t speak for the rest of the TECsters, but it was great to work with a small company that had such a diverse skill set. If you ever find yourself in such a situation, take advantage of it. I was able to get the lowdown on analytics, operating softwares, languages, operations and a ton more this summer, simply by asking. Feed your curiosity. You might not understand exactly what the other person is saying (admittedly, operations still kind of baffles me.. our ops guru Mitchell is just on another level than I am and I’m slowly learning to accept that) but you’ll at least be able to get your feet wet in the subject matter and be more capable to understand opportunities or constraints when they arise in the company.

Play dumb and learn

This was something that Brian mentioned during his visit to NYU and again reiterated during a TEC curriculum day. It’s so simple it’s genius. If you’re always trying to act like you know everything, you’re never going to learn anything new. By asking lots of question and sounding like a n00b, you’re bound to pick up something you didn’t know when you’re talking to an expert on the matter at hand. Plus, people love to talk–especially about themselves. Win-win situation all around.

The answer to every unasked question is always no

It was incredible having Shervin Pishevar drop by True and share his experiences in life and the tech industry. He has a fascinating story that was built on a lot of guts and gut instinct. Even though the lesson might be obvious, he let us know by example that every opportunity not taken in life could close an endless amount of doors, and that there’s really nothing to fear out of failure if things turn out for the worse.

The best for last

I certainly learned a ton over the past few weeks, but by far the best part of the experience was getting to meet and work with some really incredible people–both at Kiip and at True Ventures. It was through them that I was able to learn and grow as an entrepreneur and all-around human being, and I definitely won’t be forgetting them anytime soon =)

Coding at BrightRoll has been intense, and unlike anything I’ve ever done before.  I knew it would be hard and that I would learn a lot this summer.  What I wasn’t expecting was how much of a difference it would make to be a part of a team.

When you’re the only one working on a project, you don’t have to worry about trying to understand other people’s code, and you don’t have to worry about making sure other people can understand yours.  You also (theoretically) know how every part of the system works, since you’ve been working on it since the beginning.

But when you come up on an existing codebase and have to work together with the other engineers to make changes, that is a whole different story.  Now you have to spend time upfront getting to know a little bit about how everything works, though it’s going to be a long time before you understand everything.  Then, you have to get to know the specific team’s style of coding (BrightRoll: NO EXTRA WHITESPACE).  After a while, you can start writing, but you have to coordinate your work, so that no one steps on anyone else’s toes.

Also, you have to have periodic code reviews, so that every time someone makes a change, everyone knows what it was and why it had to happen.   Code reviews can come in many shapes and sizes, but in the end, it just means that at least one person reviews your code thoroughly before you check it in and push it out where real users can see it.

If this sounds like a lot of process, that’s because it is.  It takes a significant amount of time and energy to accomplish a level of harmony, and it’s not hard to screw it up.  But this is what makes large-scale projects possible.   It’s like have a team of artists working on one painting, or having many writers make on novel.  Things like that require organizing time.

They also require trust.

At BrightRoll, there are two types of code reviews.  There are individual reviews, where one experienced person sits down and checks things over, and group reviews, where the whole team goes into a room and projects the new code for all to see.

Both kinds freaked me out.

I was just not comfortable with showing my code to other people.  I was learning Ruby on Rails as I went along, so everything I had written came with a lot of help from Google, and I wasn’t entirely sure how it worked (Rails is full of magic), or whether I did it the right way.   I imagined that a code review would be like getting stabbed repeatedly with tiny swords.

So I stuck to individual code reviews for a couple weeks, from the least intimidating person I could find.

During those weeks, I went out to lunch every day with the team.  New people joined, and so there were many welcoming lunches with rounds of introductions.  My desk was moved to be near the center of engineering, where I heard and took part in daily discussions of the newest technology.  I quickly found out that everyone around me was a teddy bear inside, and started enjoying and looking forward to my time at work.  I started asking my neighbors for help interpreting code.  I started asking everyone how to become a real software engineer, and what their opinions were on the gaming industry, and what their thoughts were on entrepreneurship.

BrightRoll’s atmosphere forced me to become comfortable and happy – I couldn’t have stayed shy and nervous, even if I’d wanted to.  I’ll never forget that.

After a few rounds of fixes, Adolfo, my non-intimidating reviewer, declared that I was past making embarrassing programming mistakes and needed a group code review.  And I wasn’t freaked out anymore.  I looked forward to projecting my code up front.  And I was sincerely happy when people pointed out things that were wrong with it, because I knew that they were trying to build me up, not tear me down.

After tons of mistakes had been pointed out, someone in the group said, “So this is your first time using Rails?”

“Yeah,” I said, “And Ruby and JQuery and MySQL too.”

“Nice.”

Spending the summer at BrightRoll has been a big step for me in terms of becoming a useful engineer.  I’ve learned a lot at school, and I’ve done coding projects on my own, but there’s no substitute for working with real engineers in the real world.  When I came to BrightRoll, I knew that I would have a lot to learn, and I was right.

So, in addition to learning specific things from the Brightroll engineers, I’ve spent this summer going around to various engineers and asking them the following question: “How does someone become a real software engineer?”

And, even though we are in Silicon Valley, the most common answer wasn’t “Start a company.”  It was “Get a job.”

There’s only so much you can learn from Google, and working at a company is an excellent way to get foundational experience.  This is best done at a company where the technology is new or growing or changing, so that you will have the opportunity to participate in design discussions and architecture decisions.

But “Get a job” is not the most useful advice for an undergraduate who wants to build engineering credentials while still at school.  So, that brings me to the second most common piece of advice: “Write code.”  Pick up side projects.  Code a web game, or mess around with the Twitter API, or make a mobile app.  Actually, code a web game AND mess around with Twitter AND make a mobile app.  The more coding, the better.

Your first attempt may be a hackish blob of code, half of which you don’t understand because you copied from the internet.  But the next one will be better, and the next one after than might not be embarrassing.  After a while, you will start using the things you’re being taught in school, like keeping code DRY, using design patterns, refactoring, and avoiding magic numbers, because they’re actually HELPING you.

Yeah, it’s not the most surprising advice.  But it’s not like there are any shortcuts here.

To make up for it, here are two actual, specific recommendations to consider while you’re doing all this coding:

• Use version control, even if you’re the only one working on the project.  I recommend Git.  I also recommend cheatsheets:

• Get basic proficiency at the command line, even if you can get around using it.  This includes basic use of vi or vim.  Again, cheatsheet.

Also, read The Pragmatic Programmer http://pragprog.com/book/tpp/the-pragmatic-programmer.

The final day of TEC was last week and I’ve spent a lot of time since then thinking about how much has changed since the first day of the program. I’ve met more people, learned more things, and had more fun than I would have had spending my summer any other way. Everyone at True Ventures, specifically Shea and Christiaan, have put an incredible amount of time and effort into making this summer a great experience for all of us interns. Their benevolence and willingness to help us grow and develop at every turn surprised me every day.

I give thanks to everyone at True, but also to everyone at Tello—I fit very well into the culture of the company, and feel very fortunate to have been paired up with such a fun, smart, and hardworking group of people.

The program was, as I say in the title of this post, a formative experience. It has solidified my interests and given me a great wealth of knowledge and experience that I will draw upon months and years down the road. So if you’re a future applicant reading this and are deciding whether or not to apply, let me say this: if you are even remotely interested in technology and entrepreneurship, then you need to be in this program.

—

Peace out, San Francisco. Don’t worry, this won’t be the last time you hear from me.

It does not matter how slow you go so long as you do not stop. – Confucius

11 interns. 13 books. 18 speakers. 8 weeks in San Francisco. One priceless summer.

This summer has been the best summer ever. Why? I’ve learned and experienced so many things I never thought I’d try. Here’s a short and sweet list:

The Things I’ve experienced:

• tried out tons of new stuff: Plancast, Turntable.fm, Spotify, Soundtracking, SaveUp, Fitbit, RescueTime, hashtagging (don’t hate the noob), Foursquare
• ate tons of great food from filet mignon to fresh sushi to watermelon/mint/feta appetizers
• met tons of amazing people like the Sparked guys (Ben, Boris, Jacob, Joseph), the Kiip guys (Courtney, Amadeus, Brian), Dave Rosenberg, Danny Shader, Shervin Pishevar, Jeremy LaTrasse, Steve Blank, Alex Osterwalder, Jeff Cavalier….and many more that I didn’t list!
• made an epic video about TEC, available to view here: http://vimeo.com/27365611

• Go paintballing
• Bike 16 miles from San Francisco to Tiburon. Sixteen miles!
• Visit a former high-security prison
• Go to a baseball game. Go Giants!
• Decide to do a Computer Science minor
• Attend the TechCrunch/August Capital annual summer outing
• Have a bonfire on the beach

The Things I’ve learned:

• More HTML
• Improved communication skills
• A spoonful of Ruby
• How to be lucky via Vishal
• ABC: Always Be Closing via Nolan
• Virality for Zombies via Lionel
• The steps to becoming an entrepreneur, in 8 short weeks

But most importantly, I have learned more about myself.

I have decision ADD. That means that it’s almost impossible for me to figure out exactly what I want in life and much flailing ensues.

Pokemon references make everyone happy.

In the past two years, my major in college has undergone more changes than the number of an average start-up’s fashionable pivots. My major has gone from pre-med to business and chemistry to business and classical civilizations to business and pre-med to its final destination of business and computer science. Whew. Clearly, I was all over the place and nowhere at the same time.  I wanted everything, and the lack of focus was not only confusing, but held me back from pursuing what I really wanted in life.

In this path of self-discovery, I learned a couple of things about myself–data makes me happy, I’m always up to try something new, and I have an intense desire to become better at everything. But more importantly, I’ve learned how to channel my ambitions and dreams. I wrote earlier about entrepreneurship/business as the most effective method for change, but it took me five weeks to really know it. Even more so it’s taken me years, but now I understand what I want to do, and I feel it in my bones to realize that being an entrepeneur is it.

I have figured out the big WHY in my life and because of that, everything has started to come together and fall into place.

Doing start-ups is a hard life. 99% of startups fail hard. But this is my calling, and figuring that out has made all the difference.

I took the one less traveled by,

And that has made all the difference.

- Robert Frost

After hearing Manish Shah talk at StartupRoots, I wanted to hear more about Rapleaf and Manish’s beginnings and story. Though I learned how Rapleaf ended up at its current state, I learned even more about team-building, a different way to look at rejection, and how to shape your start-up. Thanks, Manish, for all of your insights!

Introduction

Rapleaf was started around five years ago, in November 2005 with the two co-founders Manish Shah and Auren Hoffman. The founding team initially noticied that people were starting to do more personal transactions over the net, and that the internet had become less static and more experience-based. While commerce sites such as eBay and Amazon had reputation systems, Rapleaf aimed to have a reputation system that went beyond those to help businesses get information on its over five biolion consumers buying their stuff.

Rapleaf is still focused on getting consumers the best experience possible on the internet. An important piece of information to glean from this: although not a single one of Rapleaf’s starting team had previously worked a data company, they still became a successful data start-up. Which brings me to the next topic…

Have a vision for your start-up

Despite not having worked in a data company, Rapleaf still found success because they had a specific vision of what the world should have been like. Because of their frustration, they were able to deliver on their vision.

Again, this extremely relevant graphic.

Having a burning desire to change the status quo not only validates your start-up, but can also be an integral factor to team-building and cult-creation.

The Team, the Team, the Team

Manish, who wants to create the best team in the world, is an expert on team-building. In fact, each of Rapleaf’s employees are CEO of something, to increase ownership. Even more than that, communicating the large-scale vision of the start-up helps the team step away from the daily grind and realize this: your start-up is changing the world.

An excellent resource on cult-creation written by Powerset co-founder Steve Newcomb: http://blognewcomb.squarespace.com/essays/2010/10/14/cult-creation.html

Rejection

Persistence. Is there another way to get what you want? Don’t focus on the rejection but think–is there something that they’d say yes to? More persistence.

Manish told me this story: as an undergrad at Berkeley, he pitched an idea to Peter Thiel, who told him it sucked. But it’s important to realize that rejection is not personal, and to be persistent. Years later, he pitched Rapleaf to Thiel, who this time loved his pitch. Thiel ended up leading the seed round funding for Rapleaf.

It’s not you; it’s the idea. Or it is you and it’s not the idea. Or whatever. But the point is to keep trying. Keep rethinking the situation, be persistent, have a vision, and build your team.