Guiding Principles

There are a few guiding principles/ideals behind True Market’s development process. They’re held pretty fast and loose, it’s okay if you stray from these principles, but make sure they were included in the decision to do something differently.

Consistency

Our goal is to do the highest quality of work through every project, over the span of years. That is a big commitment and requires a shift from the common view of doing my best work now because it requires reflection on what you’re doing now, what’s come before and how you are contributing to the future of the team.

It’s pretty easy for a new project to build everything as if it’s unique. Resist doing that. Almost nothing you’re doing hasn’t been done before by thousands of other developers. There’s probably some prior art, an open-source library, or whatever available for you to use in a project. We try to use as few external dependencies as possible, but when the opportunity calls for it, make sure it’s something that’s performant, accessible and something we can integrate back into our development process for future sites.

The same goes for unique, one-off code: don’t be afraid to take things into your own hands (in fact, the whole team is pulling for you to push your boundaries!), we only ask that you reflect on whether this is something we can abstract and reuse in other projects. Flashy code is great, it makes you feel excited about the job at hand; but better code functions as a multiplier, shortening the effort and time required of you and the people who depend on you well into the future. You could be a 10x developer, not by doing ten times the work (a goal few will ever accomplish) but by enabling a team to do their work even more effectively.

Communication

Comments and clear commit messages. Code should be clear and readable on its own, but comments are expected. Use a comment as an opportunity to explain why you’ve done something. No one, including yourself in 15 minutes, will understand why you’ve hacked something together (e.g., was it to work around a failing package, old server requirements, horrible deadlines), so give them a fighting chance and one less opportunity to curse your name.

The code you write is not for you, or for this moment in time, it’s for some poor Junior Developer 3 years from now who has to make a heading bigger for a small business’ new marketing promotion. Act accordingly and write that 2 sentence comment.