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 to refine on each of these points. Development is a team sport!
***
We have a simple mission as developers:
We design, build, and ship products that we are proud to have created.
This helps to define our “Crema Code” and direct our day-to-day work. It’s easy to say, but hard to do correctly and consistently. Let’s start with the “Why” and look at three patterns and philosophies that keep us on track.
Predictable
Our products need to function as expected.
While this is an ongoing process depending on shifting needs, we all know what it means for a product to achieve the desired result without error.
Building a codebase that meets these requirements is a team effort, requiring collaboration, dedication, and skill in eliminating as many edge-cases as possible.
Example: We require at least one fresh set of eyes on every pull request that we submit. Having someone else look through your solution with the acceptance criteria in mind increases the predictability of our solutions.
Maintainable
Creating features from scratch is relatively straight-forward. Accommodating new requirements while maintaining existing functionality is another story.
This is where planning and standardization should be embraced. Not to slow us down — to keep us moving forward.
We choose to write modularized, tested, documented, and statically-typed code, because it is both reusable and can be confidently changed to meet new requirements.
Example: We rely on TypeScript to keep ourselves in check. Many cases of over-engineering can be avoided before they start when your IDE is constantly reminding you of how all the pieces (should) fit together.
Documented
Programming is fundamentally an exercise in communication.
The main challenge when writing code is not communicating with the computer, it’s communicating with other people. They may be other developers, technical managers, or even ourselves as we review our code in the future!
Our goal is for others to understand how our code achieves the desired result. This is essential when collaborating with others to build an ever-growing and necessarily-complex system. We utilize a standardized documentation process, static types, and thorough testing to keep everyone on the same page.
Example: Some of our projects enjoy the benefits of self-documenting patterns and toolsets. Focusing on that knowledge transfer at every level — in the code, in the repo, in the release notes — helps to align each member of the team.
We are obsessed with finding the correct solution(s) for the product and client we are serving. Constant Improvement or bust! There’s no single hammer that will drive every nail — ask our team to use the wrong tool for the job, and you’ll see a lot of sour looks passed around the room. I love this.
Your deliverables are determined by devotion to your disciplines! When you start to ask “Why” your team has specific practices, habits, or behaviors, it’s a lot easier to influence the resulting “What” you actually do.
What does it look like to create digital products that are predictable, maintainable, and documented? In the next article, we’ll take a look at some of the tangible pieces that flow from these simple patterns and philosophies.
