Letter #274: Christina Cacioppo (2014)
Cofounder & CEO of Vanta | Build Products
Hi there! Welcome to A Letter a Day. If you want to know more about this newsletter, see "The Archive.” At a high level, you can expect to receive a memo/essay or speech/presentation transcript from an investor, founder, or entrepreneur (IFO) each edition. More here. If you find yourself interested in any of these IFOs and wanting to learn more, shoot me a DM or email and I’m happy to point you to more or similar resources.
If you like this piece, please consider tapping the ❤️ above or subscribing below! It helps me understand which types of letters you like best and helps me choose which ones to share in the future. Thank you!
Christina Cacioppo is Cofounder and CEO of Vanta, an automated security and compliance firm that was founded in 2018, reached $10mn in ARR in 2021 and passed $100mn in ARR in 2024. Prior to founding Vanta, Christina was a Product Manager at Dropbox working on Dropbox Paper. Before joining Dropbox, she was the Cofounder of Nebula Labs. She officially started her career as a venture capitalist at Union Square Ventures, but traces her entrepreneurialism back to when she was an 11 year old selling Beanie Babies on eBay.
Today’s letter is a note Christina wrote about building products aptly titled “Build Products.” In this note, she shares that once she started taking the idea that anyone could building things on the internet, she did. Then, she shares 27 lessons about learning to program and 22 lessons about creating things that she learned as she started building things on the internet. If you’ve been wanting to build something but haven’t yet, this is your sign to stop waiting and start creating.
I hope you enjoy this post as much as I did!
Related Resources:
Union Square Ventures
Women Founders/Operators
Women Investors
Mary Meeker Compilation (3,341 pages)
Sarah Tavel Compilation (300 pages)
Letter
Around this time a few years back, I started taking seriously the idea that I – not just one, but literally me – could build things on the internet.
I spent the first few weeks working alone from Hunch; starting alone has its benefits and drawbacks, as does every other tack. If you’re more the bowling-together sort, Orbital Boot Camp might be the place for you – and they’re accepting applicants for their second session until December 8.
ABOUT LEARNING TO PROGRAM
Programming is the surest way I know to feel brilliant one second and idiotic the next.
There’s no easy or quick way to learn to program, just as there’s no easy or quick way to learn most valuable things.
Learning to program requires tenacity, not brilliance. Most professional programming isn’t rocket science, metaphorically or actually.
If you tell someone you’re going back to school, they get it; if you tell them you quit your job to code, they’ll think you’re insane. Enter Dev Bootcamp, Flatiron School, App Academy, Hackbright Academy, etc. – coding schools.
Use whichever programming language those of whom you can ask advice – friends, coworkers, a partner – know.
Don’t worry too much about the language choice. The point is to choose something with which you can start learning, not something you’ll use for the next 3-30 years.
Okay okay: start off with a stable, forward-looking, well-documented language. In 2014, this practically means Python, Ruby, or Objective-C. Save the Node, Scala, Go, Android, Swift, etc. for when you’ve better mental models and will more easily fill in documentation gaps. (PHP and Java are stable and well-documented, but they’re not very forward looking for a new, web-focused developer.)
Once you’ve chosen a language, start building your thing in it.
3,000-line main.py files (or their equivalents) are, I think, a rite of passage. You get one.
Don’t worry about models or abstractions too much in the beginning. As you start writing code, you’ll stumble on all sorts of ways to improve what you’re doing.
You won’t write tests, because they feel like make work, and then you’ll make yourself very sad, and so you’ll start writing tests. As far as I can tell, everyone does this.
If you need a database, use an ORM. Google “[Python] ORM” and choose the one whose documentation you like best.
Using SEO to choose a framework/library/package/whathaveyou isn’t crazy: highly-ranked pages are a decent proxy for better documentation. When you’re starting out, you want good documentation.
Deploy your first projects on Heroku; it’s horribly confusing the first time through, but it’s less confusing than everything else.
Rebuilding a prior project in a new language/on a new platform is a helpful, if academic, exercise.
Write an API for your project if you want to learn about HTTP requests.
Computers are deterministic. Running the same code, on the same machine, hoping for a different outcome never works. Even if it seems like it will.
So it’s absolutely worth learning how the console/debugger in your environment-of-choice works. This will probably feel like make-work, but it’s not: you’ll speed future development and debugging.
When programming, the thing you’re making won’t work 98% of the time. In other disciplines – say, writing an essay – your thing isn’t broken most of the time, even if it might not be good. It’s odd in the beginning, but remember that things being broken, not just bad, is a characteristic of programming – not you.
Once you’ve finally got something working, you’ll often need to break it to do something new. This is painful, but if you got it working once, you’ll get it working again. (Version control helps too.)
If you can tell you’re hitting related errors/StackOverflow pages, it’s worth understanding how the underlying thing actually works. This is true even though it takes longer to understand something that to copy-paste promising StackOverflow code.
When you’re not building, read everything you can muster about your language – HN is a good source for posts. Don’t worry if you don’t understand much at first; you’ll pick up more over time.
Conversely, reading about entirely unfamiliar things (e.g. gdb debuggers when you’re all Ruby/Sinatra) will probably be frustrating.
If someone tells you that using language X would be a better choice than language Y, ask him/her if s/he’d mind showing you how their favorite thing in X works in both languages. The person’s being a doofus, but at least you’ll learn something.
Questions like “Express doesn’t work. What should I do?” are hard to answer (and ask.) Describing your problem and asking for direction is a better bet: “I put ‘Error: Route.get() requires callback functions but got a [object Undefined]’ into Google and can’t get any relevant results. What should I search for instead?”
If you can, put yourself physically next to a bunch of engineers in the beginning. Engineers like to talk to other engineers about what they’re building. When you look really upset, they’ll probably ask what’s wrong, too. (No one likes sitting next to an upset person.)
Get code reviews if you can, preferably from someone who’ll say “I see what you did there. Let’s do that part together” rather than “What were you thinking? Did you test X, Y, and Z? It couldn’t possibly have worked!”
ABOUT CREATING THINGS
In startups today, there’s not a great conception of projects for projects’ sake. So even if you’re adamant you’re not starting a startup – you’re just building something for yourself! – most people will still think you’re starting a startup. (They’ll just assume you’re too modest to tell them.)
If you’ve left a job to make things, figure out a way to explain that to your parents.
When you don’t have a job, most will assume you’re not working. (In truth, you’re probably working harder than you ever did.) Don’t be mean to these people – they’re confused, not malicious.
Like most decisions, this one wasn’t as risky as it seemed. If you’re the sort of person who can afford to quit his/her job to make things, everything’ll be okay regardless of how this all turns out.
That said, this is one of those things that’s easier to do in college than after. And it’s easier to do without a family than with one. But whatever your situation: thousands of other people have done this. Given time and effort, you can too.
If you’ve graduated from college, most people – including those who work with startups – will tell you that you shouldn’t do what you’re doing: you’ll never be as good at making things as those who’ve done it longer, and you should specialize in whatever you’ve been specializing in. How correct they are is up to you.
Start by making something you want.
Forget what everyone else wants. They want a product and – at least initially – you want to learn.
The first thing you make probably won’t work; neither will the second or, probably, the third. This is all okay.
You’ll make bad things. You will eventually, if not immediately, realize they’re bad. Keep going. (cf Ira Glass.)
Turns out everything is bad initially, so where things start doesn’t matter; what matters – all that matters – is how quickly they improve.
Since the first things you make will be bad, it’ll behoove you to abandon them; you’re learning too quickly to spend time on rescue missions. Here’s my list.
Cycling through projects can come off as dilettante-ish to others. Ignore them (to the extent you can.)
Keep a daily changelog in the beginning. You’re learning more and faster than you realize.
Making anything good is exceedingly hard, which most people don’t understand; they just wonder “why everything sucks.” Gravitate toward people who’ve made things before. They get it.
It’s worth figuring out what makes something “good” to you. (For me, it’s something at the intersection of “valuable,” “useful,” and “fun.”)
If you don’t have definite ideas about what you’re building, abandon it. There’s too many other things to build and learn, and doing so is sufficiently tough without having impostor syndrome about the product too.
Friends are great and will try whatever you put in front of them once. Many will not come back. Don’t resent them for it.
Most friends won’t tell you your thing is bad or why it’s bad. Keep close to those who do.
Find your 1,000 True Fans. You probably don’t know more than three yet.
Having users is essential if you want to make anything good. Launching is not. Often, “getting users” is conflated with “launching,” but they’re pretty different.
You can learn things from a dying product that’s further along – say, one that’s built but will never have many users versus one that’s in progress with no users – but you’ll learn more when you’ve got a living product (and you’ll enjoy everything infinitely more.) Best optimize for a living product.
If you got this far and you liked this piece, please consider tapping the ❤️ above or sharing this letter! It helps me understand which types of letters you like best and helps me choose which ones to share in the future. Thank you!
Wrap-up
If you’ve got any thoughts, questions, or feedback, please drop me a line - I would love to chat! You can find me on twitter at @kevg1412 or my email at kevin@12mv2.com.
If you're a fan of business or technology in general, please check out some of my other projects!
Speedwell Research — Comprehensive research on great public companies including CSU, META, CPRT, CSGP, AXON, ABNB, and interesting new frameworks like the Consumer’s Hierarchy of Preferences and the Piton Network.
Cloud Valley — Beautifully written, in-depth biographies that explore the defining moments, investments, and life decisions of investing, business, and tech legends like Dan Loeb, Bob Iger, Steve Jurvetson, and Cyan Banister.
DJY Research — Comprehensive research on publicly-traded Asian companies like Alibaba, Tencent, Nintendo, Coupang, Sea Limited (no paywall), and more.
Compilations — “An international treasure”
Memos — A selection of some of my favorite investor memos
Bookshelves — Collection of recommended booklists.
Good tips to learn programming without going to college which is rigid and takes a long time. College computer science major does not really teach programming, only gives you a degree