Fast-paced vs Right-paced

Sometimes it is hard to tell how fast the current's moving, until you're headed over a waterfall.

- Kimberly McCreight

Not always is it the best way to work on something so restless to increase productivity. For something that can be done in a week, if it took a couple of weeks, instead of scrutinising on the extra hours spent, start analysing the output of the work.

We often end up not appreciating doing documentation around something that we write. "Oh, we need to get the MVP to production, no free-time for documentation!", is something that I hear so common. The catch over here is documentation is not something to be done on your free-time. It is something non-negotiable, which we at times forget to understand. The question here is, "What is this piece of work, if there is no manual for the users to understand how to make this work? If there is no operating procedures, for the people who maintain or support this can understand the internals, what is the point of even releasing it?".

Doing maintainable work is something I've started valuing more these days when comparing it to doing it the right way! When it comes to coding, any code with no unit-tests associated into the deployment pipeline is not maintainable or production ready yet. Sadly, do we all unit-test our code? Again, "MVP to production is in a month, no free-time for playing around with unit-tests which the consumers aren't bothered about!".

I recently had a chance to work with a very fun colleague/mentor who happened to be so enthusiastic and artistic about their work, and yes, I am talking about code being an art. It is not so easy to inspire someone on something, and that too, to leave that inspirational quality in them, inscribed into the soul, is just exceptional mentorship.

Working with artistic colleagues has not been new to me. I still remember the days, we had conversations comparing water to data and water-pipelines/lakes to data-pipelines. Naming processes is the fun part of enjoying the art. When it is a small bunch of people working passionately on a problem, it often is easy to socialise the idea, the art of the solution between the small group.

And ultimately the solution ends up getting deployed in the fastest pace possible and there would be validations being done and as everyone stays on the same page, it becomes easy and looks like the ideal way to put something up as an MVP. But the issue arises the moment MVP is up, and changes happens, without customers knowing how to use it, support not knowing what to do with it and the enhancement squads going clueless on the architecture and misinterpreting the art and reading it in a totally different perspective than the group of artists who built it. Also after the analysis-paralysis period of understanding the art is done, most of the use-cases get missed after the enhancements and end up screwing the next release, making it a worst experience for the customers.

Realistic timelines, the worker group calls out. Balanced work-life, paralysed business teams, inefficient validation squads and unhealthy working environments, the excuses, we as a worker group puts forward. Who sets these milestones in such a way that the worker nodes needs to run on max compute for the whole estimated hours? When it ends up into a blame game, it ends up being the issue among worker nodes! But, the actual issue must be with the process! It shouldn't have been a fast-paced development, instead should have been the right-paced one.

A right-paced development is not slower than the fast-paced ones. At times, the right-paced work plan ends up getting work done faster. You just can't push an artist to his limits and expect the quality.

Now the issue comes with people not wanting to get the work done, instead wanting to spend time around something else. This scenario is quite common too, working with not so passionate beings, is again not so uncommon for us all. The only way to solve this puzzle is to change the formation of the squad. Not all players are strikers or defenders in the game. So identifying the right spot for a player and putting him there is another art, mostly which the player himself might not be so good at.

Artistically corporate environments is what we call our work environments these days. Just that it is fast-paced doesn't mean it can never get into a right-paced heaven to work in.