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.

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!