Have we failed? 

…That’s a thought that might go through one’s head when following a list of routines with a team where all it’s members are holding a guidebook in front of their faces - dedicated, trying to follow it through with utmost precision whilst not really seeing what’s happening around them.

It’s similar to trying to walk, for example, while putting all your mental energy into moving your legs. Thinking about the way your muscles should move to raise it. Now the other one. And the other one. 


And you will fall.

Enough has been said about the different ways one can write software. Talking about the craft of it all and the focus on maintainability. Talking about the ways we should start our days, follow through them. Sitting alone. Sitting together. Reviewing, commenting, deploying. 



Quite often it feels that rather than adopting an essence of a discipline, we often decide to act out some kind of role defined by a predetermined set of bullet-points. Meetings becoming more like an act of filling out a checklist rather than being something natural.

I'm not saying that you're NOT supposed to follow what has proven to work by far more experienced developers than I am, but I do want to make a case about it having to come naturally. Through failures. Through personal growth.

In a way, this makes me look at the idea of shu-ha-ri (Shuhari roughly translates to "first learn, then detach, and finally transcend.”), where you are indeed supposed to start by following the traditions, the rules. But quite often it feels that the lack of sincerity, believability and passion while creating software makes the "great adventure of finding your true way" into an unreachable dream.

I think the main reason for this standstill comes from the fact that we forget about the person behind the rules and routines - ourselves.  Ultimately you are the one imposing the rules and you can also choose to not follow them - instead find your own way that brings out the best in you and your ability to create. 


How do I see the Product & Tools team?  

We are bunch of people who are passionate about who they are with certain self-inflicted limitations that are usually based on something that has proven to work. People, who accept that rules have to be followed, but who also believe that there's a lot of whitespace around a "do this” that a rule imposes. In a way, a list of rules can be rewritten as a list of things to avoid.

This has resulted in a kind of inverted way of describing how we work by declaring what we will not do and leaving creative room for the person behind the steering-wheel (or in our case: the keyboard). It leaves room NOT to be a developer. 

Unfortunately, there are certain gambles one takes while working this way.

Sometimes you just have to admit that although you're after diamonds, the actual end-result is closer to cubic zirconia, which is quite a painful realisation, but there is no better teacher than a successful failure.


And that’s just all right.

You just have to get the bad things out of the way to get to the good stuff. To get to the place where one can deliver the expected and the unexpected.

I believe that "the product" in the Product & Tools Department has nothing to do with  modules that get created, it’s the team, the people. In the same tune, "the tools" are not really the development tools we produce for others. It’s the collaboration and experimenting on what works and what doesn't when it comes to software development. And in all honesty - I think that is something that extends to the whole company and makes it what it is.


Interested in learning more? Contact us