Unleashing dev culture: yasoon’s engineering principles

[#1]

We agree with Atlassian Presents Unleash: Tools alone don’t create culture. It’s the combination of people, practices, and tools that does. 

But what does this so-called “dev culture” feel like in practice? What principles do we work by at yasoon? We have put together a few guiding principles, along with examples from our day-to-day dev work: 

#1 ”Impossible is impossible“ 

If there are new requirements in the project, there are always hurdles. Blockers that seem impossible at first glance make us particularly curious. Especially if we can create added value for our customer base by solving the problem. It is precisely then that it is important to be creative; with the mindset “Impossible is impossible”.

The following code is a good example for this. In a Jira issue, we suggest involved users that you can contact via email or Microsoft Teams – this seems simple from the outside for the user, but internally we cross-reference all issue fields for involved users, which is less trivial than it sounds:

#2 “You’re not alone” or ”Memento mori“ 

“Memento mori” translates as “Think of your mortality” – ok, that’s a bit drastic and philosophical. But what it means is: remember that your team may sometimes have to work on the code without you, for example in the event of illness. Do your team members understand what you have written? How complex is your code? At yasoon, it is important that our code is understandable, clearly commented, easy to work on and maintainable.

This is an example of code that is unnecessarily difficult to understand – it is deeply nested and changes a lot of boolean variables, with very little guidance for other developers, to what is actually being achieved here.

And for comparison, a commented and self-explanatory example:

#3 “Not beautiful, but much better” 

In line with “Impossible is impossible”, we also work according to the credo “Not beautiful, but much better”. Some solutions may not seem “beautiful” at first glance, but have a high added value in terms of usability / UX. It is therefore important to weigh up when this trade-off is worth leaving the straight path and taking a detour that is simply much better.

Here is an example of a Microsoft Teams dropdown component that behaved weirdly. Out of the box, clicking anywhere on the dropdown does open it. While this is a Microsoft provided, default component, we were not satisfied with the UX and spent a bit of extra time working around the default implementation:

Of course, this list of principles is not complete; after all, company culture is always evolving. How do you like our approach to development culture and engineering principles?