Working With A Safety Net: A Developer Interview With Procore

In the “Developer Interview” series we talk to developers from some of the companies using Semaphore to find out how they work and share their insights with you. Here we had with us Michael Siegfried, Senior Engineer at Procore, one of the fastest growing companies in USA.

Tell us a little bit about your company and what it does.

Procore is a cloud-based construction software company. We aim to help construction companies work more quickly and efficiently. There are a lot of one-off tools for managing blueprints or contracts out there, but we give companies the ability to access all of their construction information in one place. A lot of our customers were keeping track of huge Excel files, so having all of their information available on any computer is huge for them!

“For any non-trivial feature we typically go through a research process that includes getting on calls with current customers”

What does your workflow typically look like, from an idea until it’s shipped?

For any non-trivial feature we typically go through a research process that includes getting on calls with current customers to suss out how it should behave. We have at least one member from the product, development, and quality assurance teams on these calls. That ensures that requirements don’t get passed down through hearsay and that we arrive at the best solution for all three departments.

If it’s a large project, we continue to work very closely with customers through a beta release to iteratively get closer and closer to the ideal feature. As development works on distinct parts of the feature, these branches will go through a quality assurance iteration before they are code reviewed and released.

What tools and guidelines do you use to write tests?

The two main resources for test-writing that we use are Thoughtbot’s guide to testing Rails applications and Better Specs. We write our specs in RSpec.

How do you approach refactoring, as the system grows?

One of the last refactorings I worked on was a large method called all_contract_buttons, which was, as the name implies, a method for gathering all of the buttons related to the contract. The method was 72 lines long and just had a bunch of duplication and irrelevant logic.

“Sometimes the act of refactoring costs more than the benefits of clean code.”

The way I approached the situation was to begin writing unit tests for the current implementation. Once I had this safety net, I began working on splitting up the logic and creating helper methods. The unit test became more of an integration test, but it enabled me to take this 72 line method and reduce it to 20 lines. The code was much easier to read and reason about. This approach gives you confidence that you are not breaking current functionality as you refactor.

What’s the last big realization about programming that you had?

One of the last big realizations about programming I had is that refactoring doesn’t necessarily justify its own cost. Sometimes the act of refactoring costs more than the benefits of clean code. It certainly makes sense to refactor something if you are touching that part of the code base, but sometimes there are bigger fish to fry.

How does Semaphore help you achieve your goals?

Semaphore is integral to our development process. We never deploy code to production unless the build is green in Semaphore. We also don’t merge branches into our master branch unless they are green.

A handful of times Semaphore has helped us find bugs in code that we were about to ship, but more often it helps us find bugs before we even consider the code ready to ship. Semaphore finds potential bugs before they become user-facing issues and gives us peace of mind that we are not breaking any tested code. While we have ways to go to get better spec coverage, it will only make Semaphore an even more important part of our process!

Related Articles

Get future posts like this one in your inbox.

Follow us on

comments powered by Disqus