Development Principles

We use these development principles to make it easier for us to make decisions and ensure we do things our way. You might disagree with some, so keep in mind these are the principles we feel apply the best to Tjek.

Put People First

Always try to question what is right and put yourself in someone else's shoes when building products. Don't optimize for the quick buck but instead creating real value to real people.

Remember We’re a Small Team

Don’t adopt the practices of large corporations. Exploit we're a small team. That means we need to do things the smart way and not the hard way. 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.

Don’t Reinvent the Wheel

Use open-source libraries and spend time searching for possible solutions instead of trying to solve them yourself. Try to spend your time in the places where we are unique and can provide value.

Seek the Simple Solution

Simple defined by few moving parts. While this is sometimes hard to do, the initial investment in finding the simple solution usually pays off in the long-run.

Watch Out for Over-Engineering

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

Our Products Should Feel Nice

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

Seek Incremental Improvements

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 if you're building something completely from scratch, try to figure out what the minimum loveable product is. Instead of launching a car as the first thing, sometimes starting out with a skateboard or a bike is good enough to get people from a to b.

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.

Watch Out for Abstractions

Abstractions can be great when you need the same logic again and again different places and you're pretty sure of 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, 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.

Comments Should Explain Why

Comments should not explain what code does. The code says that. Comments should explain why you ended up with that solution.

Avoid Data Silos

We don’t want to have important data stored all over the place. We should strive towards one source of truth. This is a tendency especially in larger companies and we should not fall into this pitfall. It’s sort of like micro-services but for databases.

Use Few Technologies and Languages

Our primary programming language at Tjek is JavaScript. We then use Kotlin for Android, Swift for iOS. Some Go and Python too. We should 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.