Our Guiding Principles

As individuals and engineers, we want to control our destiny. We want to make a difference. We want to have an impact. We want to enjoy our journeys.

We work with a great deal of trust and autonomy here at Ryalto. These principles aim to capture our individual ideals and the considerations that help guide our processes on a daily basis.

These are our starting point. We should aim to keep them at the heart of everything we do, keep these in mind when we’re working and reference them when when working together to make decisions, to build a better ryalto

As we grow, we’ll iteratively improve these principles and we’ll do this together.

Build Something Beautiful

Building things is much more rewarding when what you’re creating is beautiful. This refers to both the UI and the code that you're writing. It's much nicer to test a front end which is pleasant to look at. It's much easier to debug code which is clean, well formatted and, well, beautiful.

Keep It Simple

One of the hardest challenges in software engineering is to make a complex problem simple. Extra effort is needed but, if done at an early stage, it pays dividends in the future.

We write code for each other (and our future selves). Keeping it simple and tidy means it’s easier to debug and expand in the future.

Ownership

Ryalto is ours. We build it, we maintain it, we use it. Let’s look after everything around us and keep things tidy. If you see a piece of litter, pick it up.

If you see some code that could be improved, a bug that can be fixed, or some docs that can be enhanced, then take a little time to make it better. If it’s too much effort to do there and then, or you don’t have the expertise, then create a ticket so we can come back to it later. Never say “that’s not my job."

Leave the code base cleaner than you found it. Small improvements matter.

Marginal Gains (Dave Brailsford, British Cycling) and World Class Basics (Clive Woodward, England Rugby)

“Don’t Live with Broken Windows. Fix bad designs, wrong decisions, and poor code when you see them.” David Thomas and Andrew Hunt, The Pragmatic Programmer, Tip #4

Open Communication

Asking questions and discussing challenges in open channels gives the opportunity for everyone to contribute. Those with the required expertise can jump in and help if they’re able, and everyone can learn from the discussion.

If you disagree with a decision, you should respectfully challenge it. Present evidence and reason logically to defend your position. If the chosen course of action is not the one that any particular team member might have wanted, they'll still need to join the team effort without second guessing it along the way

Invest in Ourselves

Our most valuable assets are our knowledge, experiences and attitudes. We want to invest in our shared knowledge portfolio. As such, ½ a day a week is dedicated to growing, consolidating and sharing our knowledge.

Learn and be curious. We are never done learning and should always seek to improve ourselves. Be curious about new possibilities and act to explore them.

Communication isn’t Easy

Communication is hard. Written communication is harder. When most of our communication is written, the absence of visual and audible cues can distort the intended meaning. Osmo Wiio said, “If communication can fail, it will. If a message can be understood in different ways, it will be understood in just that way which does the most harm.”

Be patient, be kind, assume the best in each other and be open: open to asking questions, and open to receiving them.

Bias for Action

Ignore details early on. Shape up the idea, the functionality, the design and the code as you go along. The right questions to ask will reveal themselves as you work. You’ll feel what is missing. Get a prototype working ASAP. Make decisions, make mistakes, correct, adapt and iterate to improve.

Keep it small. Keep it simple. Let it happen. - Andrew Hunt

It’s a problem when it’s a problem

While it is always worth being aware of potential challenges, we believe in not trying to fix them early. There is no point building a system that can handle a million concurrent users if you never make it to a thousand. Make decisions just in time.

The only way to go fast, is to go well.

“There is no trade-off of quality vs. speed in software. There never has been. Low quality means low speed. Always. The only way to go fast is to go well.” - Robert C. Martin, Clean Architecture (and Twitter)

Sometimes we do have to move fast and sacrifice some quality, but this will always have consequences. A short-term fix is a long-term headache. Think ahead, and don’t sacrifice long-term value for short-term results. We always aim to write code that is readable and high quality.

This is similar to the popular quote attributed to Kent Beck, which importantly should be interpreted in relation to a specific task not an overall project, “Make it work, make it right, make it fast”.

Some Sources

https://www.amazon.jobs/en-gb/principles

https://pragprog.com/tips/

https://basecamp.com/gettingreal