How To Move Fast And Not Break Things

"Can you describe a time when you had to work in a fast-paced environment? How did you approach it? How did you trade off between speed and code quality/sustainability?"

I co-founded a startup, Arcade, in 2020, and we were doing demos for companies like Spotify, T-Mobile, Adobe, Mailchimp and more. Each demo gave us insight into what customers expected our product to do, so we had to have prototype features ready for the next demo to avoid disappointing. This required extremely fast engineering efforts, and as a small team, we had certain expectations of each other, which boiled down to two rules:

Rule 1: Document everything in writing.

This means proposals in writing that the other eng can look over, documenting decisions as you go, and writing extremely thorough comments in code explaining the whats and whys. The writing didn't have to be perfect. What it enabled was very open conversations and a growing knowledge base of engineering efforts. It helped us explain ourselves to customers, as well as stay on the same page in a fast-moving environment. Documented decisions also allow us to go back in time and try a new thing, replace the old thing, or see that something was already attempted and to not waste time.

Rule 2: Don't over-optimize.

Shipping was always the priority. If we spent too much time perfecting a single function or frontend experience, we're taking time away from engineering something else. Perfection is the enemy of good. Of course we didn't want to break things, but if we weren't shipping, we weren't selling. Rule 1 also helps us move fast without breaking things, because it allows deeper thinking into implementation details. We always kept a mindset that nothing we build is permanent, so enabling flexibility and not "shooting ourselves in the foot" was top priority. Sometimes things break, you can't avoid that, but if we have proper documentation and code insight, any problem could be fixed quickly.