Welcome to this brief mini-series focusing on the Why, What, and How of being a developer at Crema. Note that I’m pulling heavily from language that our team worked on to refine each of these points. Development is a team sport!
Designing effective workflows is an important part of any efficient system. Four methods developers at Crema use to build digital products include: GitFlow, Code Reviews, Testing, and Dev Chat.
In the first part of this series, we defined the “Why” of our specific team practices, habits, and behaviors. We start there to ensure we can build software that is predictable, maintainable, and well-documented.
Our principles influence the resulting “What” we do. Let’s take a look at four tangible actions that flow from those core philosophies.
GitFlow
It takes clarity of thought to compartmentalize edits into meaningful and related groups of changes.
It sounds simple — just update the repo as you write your code — but it’s more of a discipline unto itself than a toolkit or practice.
Every line of code we write is version controlled using Git and follows the standard GitFlow branching strategy. This ensures that every new feature, release, or hotfix can be versioned and released in a standardized way (SemVer). Beyond this, we ensure that base branches are protected, requiring approval via Code Reviews and validated Testing before merging is allowed.
Example: GitHub integrations like TravisCI and Codecov run each time new code is pushed, giving the team full insight into how the changes are affecting overall quality in the codebase.
Code Reviews
Each member of our team is the most valuable part of the process, so we always review our code with one another.
When we promise to deliver a quality product, that commitment extends beyond tooling, correctness, and functionality. The human check has to pass as well — all code goes through a standard code review process before being shipped.
It’s not just about eliminating mistakes, though that is often an immediate benefit of this workflow. We also use this time for general improvement in the codebase: does it both work well and make sense to another developer?
Example: Merge rules are enforced at the repository level. This guarantees that each product is comprised of code that is understandable, tested, and upholds Crema standards, on top of satisfying written acceptance criteria.
Testing
We work to employ high-coverage testing throughout our applications.
Testing takes a handful of forms and each meets a particular need. These tend to include: Unit, Visual, Integration, and Accessibility.
Every person at our company has a hand in quality assurance. This is true even when there is staff dedicated to quality roles. Thinking about equal access and accessibility standards, I found myself coming back to that same belief but replacing quality with accessibility.
— Courtney Johnston von Nieda
We believe that problems are best solved when broken down to their simplest component parts. This helps during the process of planning as we attempt to visualize what success looks like. It also confirms that our assertions are correct based on the desired end-state.
Example: Our projects are written in TypeScript, so our tests can focus on the logic unique to each product instead of syntax and composition. We use our time to create the application and leverage tools to help ensure code integrity.
Dev Chat
Getting everyone in a room or on a call is our favorite team-centric approach to maintaining a healthy community of developers.
Our bi-weekly chats are regularly-scheduled opportunities for the team to come together and share what has been learned in the trenches. Crema is committed to Constant Improvement — this ought to produce results that can become shared knowledge for the entire team.
Example: Dev Chat topics can include presenting new tools, dissecting new techniques, talking through the dynamics and process of personal growth, and much more.
