Two Years at Enzoic: Lessons in Building Quality Software

Today marks both my two year anniversary and my last day of employment at what has been the best job I’ve ever had as a senior software developer at Enzoic (I actually wasn’t aware that today was my two year anniversary until I started writing this post). Mike Wilson, the founder, is an absolute beast of a programmer and I’ve learned a lot about product leadership from him and have really benefited from his generosity as an employer.

Learning from Past Experience

One of the most difficult things about selling my own software company three years ago was that when we were acquired, a very in-depth survey went out to all of our customers. In some ways reading the feedback was encouraging – our best customers said we did a lot of things well. They liked our design and how intuitive the user experiences were. They appreciated that we prioritized the end user experience and focused on the metrics that mattered most to their customers. They loved our personalized customer support and onboarding.

But there were two specific areas where we weren’t meeting muster: we shipped code before it was well tested and we needed to hire more staff. While I’ll come back to the second point in another post, that first criticism was really difficult to hear. Until then, I hadn’t realized how broadly our approach to code quality had hurt our customers and their businesses.

The Challenge of Quality at Speed

Turns out shipping fast and writing high quality code isn’t easy. As the main developer who also happened to be the entire sales and marketing team, I had a very difficult time balancing responsibilities. I didn’t feel like I had the luxury of putting processes in place, writing unit tests, and running things through QA before deploying. Instead, when customers had problems or wanted features, I would work as hard and fast as I could, trying to be thoughtful about the user experience, do quick testing locally, and ship to production.

At first this worked well. My early customers agreed to be beta testers in exchange for input into the product’s direction and knew some bugs were expected. They got features fast and I got quick feedback; in some ways it was actually a benefit.

But as the years went by, my product leadership didn’t grow to support the new phase of the company. While I was extremely fast to fix bugs when customers complained, hearing some of my most loyal customers describe their pain made me realize I was really failing on quality.

Growth at Enzoic

When I interviewed at Enzoic after selling the company and taking time off, one concern they had was my limited experience with testing and QA engineers. While I knew learning something new wouldn’t be easy, I assured them I was up to the challenge.

Enzoic had roughly .8 Quality Assurance Engineers for every Software Engineer – a very high ratio. That meant I had one or two QA engineers consistently pushing and prodding my code to ensure customers wouldn’t have problems.

At first, it was frustrating. Sometimes they called out bugs I considered unimportant edge cases. Other times they used the code in unintuitive ways or understood the design differently than me and broke things that made me roll my eyes. But I was committed to working through all those issues.

The turning point came when my engineering manager told me my QA engineers were unhappy with the bugs they were finding. When I questioned this – isn’t finding bugs their job? – he explained that our job was to write high enough quality code that they don’t find many bugs when we mark it as ready. Context switching is extremely costly. If QA has to send code back multiple times, it wastes their time moving around in the codebase.

This led me to become a more thorough tester of my own code. While I’ve always been an exceptionally fast coder focused on “getting things done,” I learned to take an extra day to review with fresh eyes before marking work as complete. Surprisingly, this helped me catch about 80% of issues early on.

Over time, I started seeing patterns and anti-patterns more quickly, learned to account for them, and significantly lowered that number. I got better at documenting my code and decisions, and writing thorough tests to ensure new features didn’t break existing functionality.

A Grateful Farewell

There’s a lot more I could say about my time at Enzoic, but I want to shout out Mike Wilson and the team, as well as my original engineering manager Pat, who has since moved to a new venture. They’ve been incredibly generous as employers and product leaders and have taught me so much about code quality.

Thank you and I hope my contributions to you have been as impactful as yours have to me.