A seemingly universal truth about engineers is that they like to complain about the codebases and technologies that they are tasked with working on. When it’s a small, early-stage startup, those complaints are typically aimed at databases (👋🏻 Mongo), web app frameworks (👋🏻 Expresss), or third-party dependencies (👋🏻 npm & co). As the company and its codebases grow, those complaints are eventually going to be directed towards internal codebases.

If you’re an early stage startup employee, those “internal codebases” also happen to be your work.

The complaints come in all shapes and sizes. It’s that sense of questioning—that wondering just what they were thinking when decision X or Y or Z was made. It can happen in code reviews, design docs, architecture forums, and even discussions over lunch.

I spent 6 years on the engineering team of a startup that went from a handful of people to a few hundred. I experienced a lot of these moments firsthand. And though it feels silly to say this now, I must admit that those moments stung at first and at times even felt like personal attacks.

When you join an early stage company, you’re taking a leap of faith, stepping into a near complete unknown with the hope that, through nothing but hard work and tremendous luck, you’ll come out on the other side with a product that people not only love but are willing to pay for. It’s not a sure thing. It’s very nearly the opposite of a sure thing.

But this isn’t about how the early employees of a startup were omniscient or infallible. Most of the time, those comments about past technical decisions were spot on. Many of the early services we built had serious scaling issues—from a technical perspective, people perspective, or both. Many could have scaled longer or been easier to maintain and extend if a different path had been taken at the outset.

In some ways that is a harsh reality to face. It made me realize that although I wasn’t a great programmer, probably not even a good one, I was at least a good builder.

And that’s why I felt proud in these moments—proud that my past work was no longer good enough. Because reaching that point meant the company had survived, thrived even, and made it through another month or quarter or year, due in some part to my work, flaws and all. And not only had the company survived, the team had grown and levelled up, a team that I helped build.

These new team members were pointing out the flaws in my past work, what I didn’t know, and what bad assumptions I had made. But I’d interviewed many of these people, helped gauge whether or not they’d be a fit, and sold them on the vision of where we were headed. And I learned so much from them. They made me better.

This pride wraps up neatly to present in a blog post but it didn’t come for free or quickly. It was ugly. I was ugly at times, allowing my feelings of less than-ness and hurt in these moments to manifest as defensiveness. But with time (and feedback) I got there. I learned to embrace my own missteps and shortcomings, seeing them at long last as opportunities for growth and learning. They were there all along, it just took me awhile to see it.

So if you’re in a situation where you’re feeling bad about your work, like it’s not good enough for the company or team today, embrace it. Take pride in the fact that your crappy code helped to build a company that attracted these teammates around you now that so impress you. Seize that opportunity, run headfirst into it, embrace the crappiness, let them know all that you didn’t know—and learn from it.

I owe an apology to Mongo, Express, and npm—everything bad that we said about you was almost certainly our own fault. If you’re a contributor to any of these, thank you. ❤️