We use these development principles to make it easier for us to make decisions and ensure we do things our way.
You may disagree, so keep in mind these are the principles we feel apply the best to Tjek. Principles can be stupefying so it's important we always question and refresh these principles.
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.
- Example: We don't track people and send their data to 3rd parties
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 to 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 are a good thing, as it usually fosters more creative solutions.
- Example: Don’t build microservices as it only fits the organizational shape of very large corporations
- 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
Putting people first is our main principle but this principle comes right after.
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. And 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.
Incrementally Improve When Possible
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.
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 of the intent. Always consider this though: if you need to comment 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 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 because it can make code so much harder to read and follow. And we're software writers, writing for others to read.
Use Few Technologies and Languages
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.