5 Amazing Engineering Practices That Lead to Great UI at Qumulo

Authored by:

Before I came to Qumulo, I had gotten so jaded as a software engineer working on UI at other companies, that I gave up on good engineering practices. I felt like Code Monkey for much of my career, working hard on meeting deadlines and building, leaving no time for good engineering.

That changed at Qumulo. We work on a deeply technical product, and the quality is supported by good engineering practices. And while following these practices might feel slow when we’re doing it, in the long run, they really help us go fast.

5 Engineering Best Practices 

Following are 5 engineering best practices we follow that empowers everyone working at Qumulo.

1. We work together as a team

Qumulo is my first experience where the teams truly function as teams. Because we work in a flat organization with no managers, our teams work together by requiring consensus in decisions. The team members also get to decide how they want to work with each other through working agreements; this includes work hours, how the team tracks the work and how conflicts are resolved.

For UI and UX, after learning through experiments and iterations, we’ve introduced design sprints to help create mockups for our UI design and flow. Designing together allow us to all understand how we’ve arrived at a decision because everyone was involved, so we continue making good decisions going forward and don’t end up re-sharing the context and questioning the decisions after the fact.

2. We own the codebase

When I find a problem in our code, I’m empowered to find a way to fix it because we, as engineers, own this codebase. As a result, we clean up after ourselves and fix the small bugs we find, and we drive to have the larger issues addressed — I can improve the tools to help do the job I  need to do.

Contrast this with a major software company where I used to work: once I found a simple, 1-liner bug while working on a task and decided to incorporate the fix into my change (today I’d make a separate patch of course). A PM came by a week later to ask me why I had fixed a bug that was “not approved” to be    fixed, and that I was going to get into trouble and had better revert that change. Boy am I glad I left THAT company!

3. We work in pairs

This is not only programming, but also includes design and investigation. We use our daily standup time to organize pairs and to keep the pairs accountable.

Working in pairs allows us benefit from different perspectives while working on a problem, so the final solution is more comprehensive. Similar to the teamwork I described above, working in pairs also helps us to share context, which prevents one person from being a bottleneck and supports our unlimited vacation policy — I can take time off knowing that my team already knows everything I know.

4. We think and work in small patches

Our code changes are in patches, and we want each code patch to do one thing and contain only one concept — for example, one patch for variable rename and one patch for a bug fix. A large refactor is broken down into sometimes dozens of patches where each patch expresses a very small change but the patch stack adds up to a large refactor. Our version control and code review systems support us in working with small patches. This means we are looking at small patches in all contexts, which allows us to understand the patches quickly.

5. We obsess over testing

Tests help verify that our code works correctly. They ensure our refactor was done correctly, and they keep us safe when code changes have unintended consequences.

This year, we made a few major upgrades to our UI code base: we enabled TypeScript, and our tests gave us assurance that our migration did not cause intended problems in our existing code. We also upgraded React and were able to verify that the upgrade to the latest React 15 worked great, and failed tests confirmed that we needed to do more work to clear the breaking changes before upgrading to React 16.

These practices allow me to be an empowered member of my team and of Qumulo. I am encouraged to write good code with tests, create framework and tooling to help me do good work, and take the time to share and work with my teammates. These practices have become a part of my craft as an engineer, and it’s been very exciting to work at a place where I am encouraged to get good at my job — not my output. I feel like I am learning and growing all the time at Qumulo, and I LOVE the feeling that with each day, I am becoming a better engineer.


Related Posts

Scroll to Top