It’s officially launch day!

Building Guess My Pay has been an incredible experience. I wanted to share 4 lessons I learned during the process. Thanks to my eternally patient teammate James Robinson – I am so proud of what we’ve built!

Don’t forget to visit www.guessmypay.com and join us in making pay transparent.

1. Diverse Teammates = Strong Team

Everyone says that diversity is the way to go, but until I worked with James on Guess My Pay, I really didn’t drink that Kool-Aid.

On the technical side, James is my polar opposite: great with back-end systems, a fastidious writer of tests, fluent across what seems like every language imaginable. Me, on the other, I am a hybrid designer/developer. My focus is always on the user experience, about making things flow.

The combination of our skillsets was an instant success. Workflow was natural. Tasks assigned themselves.

Our distinct thought processes made for engaging and productive code reviews (more on that later).

Before Guess My Pay, I wouldn’t have put much stock in the power of diversity, but this experience has totally shifted my point of view. If you have the choice, choose teammates that are complementary, rather than carbon-copies. It just works better.

2. Code Reviews Work

Do you think code reviews are a waste of time? Before Guess My Pay, I certainly did.

I used to wonder why teams would add yet another requirement to publishing code, forcing programmers to jump through an unnecessary hoop to getting things done.

Turns out, code reviews are not time sinks. They aren’t meant to inflict pain.

In fact, my experience working with my teammate, James, a more senior programmer, on Guess My Pay has taught me that code reviews are one of the most valuable steps in the development process. Here’s why:

First, more eyeballs means better code. Even for pull requests that fell outside my wheelhouse (as many of them did), it was surprisingly common to discover, during a review, a better approach to solving a problem. Likewise, James’ input on the Guess My Pay user interface often prompted me to take a different approach in designing the look and feel of the application.

Second, reviews are an opportunity for you to learn new skills. For me, an eternal sponge, it has been tremendously valuable to hear James’ thought process, to see how all the back-end pieces fit together.

And lastly, code reviews encourage constant communication on all aspects of the project, not just the current pull request. This communication enabled us to manage and prioritize our workflow, staying in sync as the app evolved.

The moral of the story is this: What once seemed an unnecessary box-ticking exercise is now one of my favorite parts of working in a team. Try it, you’ll see.

3. Users Break Everything

Imagine this: You build a thing. It works perfectly (on your machine). You launch it to the world and instantly get a million users.

It’s a beautiful vision, but unfortunately, a complete fantasy. Here’s how it really happens:

You build a thing. Sometimes it works for you; sometimes it works for your teammates. On the happiest of days, it works for everyone. 

You get closer to launch and decide, hey, this might be ready to give to a few friends for testing. Links are shared and…mayhem.

Open the floodgates for a suite of new errors, new edge cases and new feature requests. Everything you thought you prepared for pales in comparison to the stuff you apparently didn’t think of.

We built Guess My Pay rapidly during the two-month period when Bermuda was in lockdown. As we got closer to launch, we started sharing it with early beta testers. It’s such a simple thing, we thought. What features could we possibly have neglected to add? What edge cases could we have forgotten?

Trust me when I say – test early, test often. Users break everything and generate crucial feedback while doing so. 

4. You Can’t Know Unless You Try

Guess My Pay has been an adventure outside of my comfort zone. Truly, I’ve never done anything like this before.

From the moment James and I decided to explore this idea, there have been opportunities for me to say no, to run away. What could I possibly contribute? I struggled with imposter syndrome and the thought of being the junior member of a two-person team.

But something pushed me to embrace the unfamiliar. Rather than give into my introverted anxiety, I side-stepped it. And I decided to take a chance and do something that challenged me personally, technically and creatively.

And what a wildly exciting journey it has been.

In March, James and I applied for Y Combinator with our idea for Guess My Pay. Shortly thereafter, Bermuda went into lockdown due to COVID-19. While other people were watching Netflix, James and I were coding, building our idea, making it real.

By the time we were rejected by Y Combinator at the end of April, it didn’t really matter. We’d had become a team, rapidly progressing towards launch day.

Well, today is that day. I am writing this now, looking back on what we’ve done and the choices that led me to say yes, when I could have said no. I am so proud of what we’ve built.

In February, if you had told me I would spend every Sunday pair-programming for hours and hours, I would have said you were crazy. In February, I would never have imagined I would be co-founder of anything.

I got here by trying something new. And, would you look at that, I loved it.

---

Thanks so much for reading. Tweet me @amypeniston if you made it this far and don’t forget to check out Guess My Pay!