Project Philosophy

Community

We are a welcoming and friendly group of embedded development enthusiasts. However, respect must be earned — it is not given automatically, and special treatment should not be expected.

When you join the conversation, come not just to take, but also to share with others.

We have a wealth of resources and a rich history of discussions. Before asking questions, explore the knowledge base, including the discussion history in both Discord and Telegram, read the wiki, and use the search function.

Spread the word, and help newcomers find their way.

Approach

In Thingino, common sense is the foundation of our development decisions. While it's easy to get lost in technical details and complex solutions, we believe that simplicity and practicality should guide our work.

Embedded development often lacks this straightforward approach — we aim to change that.

We prioritize clear, effective solutions over unnecessary complexity. This means thinking critically about what truly needs to be done and finding the most efficient way to achieve it. If a solution is obvious and works well, we embrace it — prioritizing simplicity and effectiveness over complexity.

In a field where over-engineering is common, we stand by the principle that good development is driven by a balance of knowledge, experience, and simple, practical thinking.

Let common sense lead the way.

Development

“Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius — and a lot of courage to move in the opposite direction.” ― E.F. Schumacher

Less is more. Try to get the best result with the least amount of code and the simplest tools.

Any camera-specific configuration and customization should be done outside the camera, if possible.

Bad code is better than no code at all, but good code is always better than bad code.

Scripts, comments, documentation, and examples should go to off-camera resources: project website, project wiki, etc. Remember that we only have so much space in embedded.

Good readable code with little or no comments is better than bad obfuscated code with comments.

Debug messages must contain details: what happened, where it happened, what data came in, what data came out, etc. "Shit happened!!!!" is not a good debug message. While "Shit happened while running make_it_good(a) with a=123. Got 567 when 987 was expected." is.

We are hobbyists and we do things the way we know how. If you know better, come and teach us!