Development principles

Development principles

We use these development principles to make it easier for us to make decisions and to ensure that we do consistently do things in our way. You may disagree to these principles, so keep in mind that these are the principles we have found apply the best to Tjek. Principles can be stupefying so it's important we always question and refresh these principles.

We are a team of builders and innovators from all over the world, based in Copenhagen, dedicated to creating new and innovative ways to simplify, lower costs, and optimize the shopping experience.

Our principles

Our principles

Put people first

Always try to question what is right and put yourself in someone else's shoes when building products. Examples:

  • We don't track people and send their data to 3rd parties.

  • Don't optimize for the quick buck but instead create real value to real people in the long-term. Revenue is not an argument alone.

  • Make long-term decisions.

Exploit we're a small team

Don’t adopt the practices of large corporations.


We are a small team, and we need to use that as our advantage—that means we can't just throw a lot of money and people at a problem. We need to be thinking in terms of simple, efficient, and low-cost solutions.

Also, working with boundaries is a good thing, as it usually fosters more creative solutions.


Don't reinvent the wheel

Use open-source libraries and spend time searching for existing solutions instead of trying to solve them yourself. Try to spend your time in the places where we are unique and can provide value. Let's contribute to existing open-source projects instead of making our own half-baked solutions.

Always seek the simple solution

What does simple even mean? We define simple as few moving parts. The more parts, the more complex it is. While this is sometimes hard to do, the initial investment in finding the simple solution usually pays off in the long run.

  • Example: Avoid over-engineering

  • Example: Don’t use a SaaS solution when e.g. an email works just fine

  • Example: Don't automatically use what other, larger corporations use. Usually, a SQL database can solve most of your needs. You don't need yet another service

Our products should feel nice

Quality should be the common denominator in what we do, for example, making our apps and API's faster. It’s not good enough to have a feature if it sucks to use.


  • Example: If there's a bug, fix it within within a day or two. Don't create a bug tracking system. We need a focus on quality and a strong foundation.

Incrementally improve

Instead of working on something for months and months, strive towards incremental improvements. We want to deliver value to people using our products continually, and we want to get feedback quickly and make small changes until we get to a point that people really love.

We're software writers

We are writing code for others to read. Make it elegant and easy to read. Code should be viewed as a user interface.


In a perfect world, the code you write should be easily readable and self-explanatory, but sometimes you lack the proper context, historical reasoning, limitations in 3rd party libraries and services. Here, comments can be helpful. Sometimes comments can be helpful to prime your mind and that of the reader of a complex code-block or algorithm, so that there are no ambiguities in regard to intent. Always consider this though: if you need to comment on some code to make it understandable, maybe a refactor and simpler code is the better solution?

Watch out for abstractions

Abstractions can be great when you need the same logic again and again in different places and when you're pretty sure what functionality is needed now and going forward.


Abstractions, however, can also make things unnecessarily complex. Just because you have to do the same thing twice, this doesn't mean you need to abstract it away. Duplicating the code might be just as fine if not better. Abstractions can make the code more abstract, harder to follow, harder to read, and they also lock you into a specific design that might not be future proof.


Use abstractions with caution because it can make code so much harder to read and follow. We're software writers, writing codes for others to read.

Use few technologies and languages

Our primary programming language at Tjek is JavaScript.


For Android, it's Kotlin. For iOS, it's Swift. And, in some cases, we go for Python and Go depending on the use-case. Sometimes, Go is better if we need more performance.


That's it.


We prioritize using as few languages as possible because we have to consider it in a larger picture. When selecting a new programming language, we now have to support it, maintain the services using it, hire for it, teach people, etc. A new language can make things more complicated for Tjek as a whole.


Also, no language is ever perfect. You might have certain issues with a programming language but switching to a new language just gives you a set of other issues. Maybe it's not the language and perhaps you just need a refactor?

Avoid silos

In general, we strive towards as few silos as possible to foster collaboration, knowledge sharing, and better/easier/simpler technical solutions.

Examples:

  • We don’t want to have important data stored all over the place. We should strive towards one source of truth.

  • DevOps should not be a single person. DevOps is a culture that the entire team should embrace.

  • Few services, programming languages, and technologies.

  • Less one-person projects.


In practice, this is not always possible, and you sometimes have to compromise.

Tjek © 2023