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
- Example: No 3rd party trackers and tracking of you in general
- Example: Do unto others as you would have them do unto you
- Example: Build a product we want to use ourselves
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.
- Example: Don’t build microservices as they embrace a multi-team culture
- Example: We can’t maintain huge solutions ourselves easily. That’s why we use the cloud, for example. We don’t want to build a data center and all the tooling around it ourselves
- Example: Use very few programming languages
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.
Do things the simple way
Simple and 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.
Make sure our products feel nice
Prioritize performance such as making our apps and APIs faster. It’s not good enough to have a feature if it sucks to use.
Don’t strive for excellence in version 1
It’s very rare you know exactly what you want to build in version 1 because it’s new. We are building something new that didn’t exist before. Therefore, cutting corners and making temporary solutions in version 1 is completely okay because if it works we will be wanting to improve it. Others call it “fail fast” but we’re not aiming to fail. We just accept that we don’t have a crystal ball and sometimes you build the wrong thing. Therefore, you don’t want to have made the perfect solution behind the scenes
Consider yourself 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.
Avoid too many abstractions
Make abstractions when really needed. Just because you need to do something twice doesn’t necessarily mean you should make an abstraction.
Make comments that 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.
Keep programming language palette small
Avoid Big Bangs
Instead of working on something for months and months, strive towards incremental improvements. We want to deliver value to people using our products continually. Although, it is not always possible.