Introduction

In our project workflow, we break down features to implement into tickets and developers pick them off one by one; Pretty standard & typical Agile/Kanban workflow. However while working on a feature recently, we came across on an interesting problem where our standard workflow didn't work out. Rather than trying to explain it in vague terms, I am going to start with a story.

TLDR

In case you don't want to dive in just yet, here is the idea we will cover in this post.

Think about the behaviour of your program in terms of data types & functions signatures. Next step is to prove or derive a function that composes all of the types & signatures to implement the feature. Then carry on to implement each of the individual functions with the guarantee that all functions will compose together.

Read more…

Cats Effect's Fibers/IOs run on a thread pool created over VM. They are essentially Green Threads that are created over the thread pool. Unlike async frameworks, IO.flatmaps does not include _asynchronous boundary. This means that essentially all of nested flatmaps are run within a single fiber. IO has mechanism to introduce asynchronous boundary but this has to be done manually by the developer via IO.shift. Operations such as race, parMapN or parTraverse inherently introduce asynchronous boundary.

~ 14th May, 22:11

Companies are interested in keeping the risk of their operations to a minimum. Software Developers want to learn and hone their craft. (This is not true for all developers and I don't speak for them.)

These two motivations don't align well with each other. Learning requies failure and unpredicability; Neither of which is good for company. Also, if you have employees who like to learn and experiment, they are more likely to innovate. The knee jerk reaction to this might be, "Yes! We WANT our employees to innovate!" But the reality is that not all innovation is good. More often than not, innovation can lead to creating silos and requiring special skills for developers to operate the tools. Tools that are unique and idosyncratic. This is not in company's best interest, because they want the cogs (Developers) in their machine to be replaceable. This is not malicious intent on the company's part, it just means that in case you want to leave the job for greener pastures then the company shouldn't get crippled and be able to move on and work efficently.

~ 5th May, 2AM & 11:30 AM

In general people like to say that one should not be bound to any particular language and instead should be able to switch languages as and when required. However it is also common to see that programmers, especially those with many years of experience, loathe this concept.

We tend to dismiss this by saying that they are set in their ways and that they are being stubborn & don't want to make the effort. However that might not be true in all cases, what a younger developer tends to not understand is that a veteran developer has spent an insurmountable amount of time understanding and mastering their craft. They have gained command over their tools of trade that allows them to bend the world to their will. Indeed it is a frightening thought to ask someone to abandon their previous knowledge and start from the beginning because they will always be conscious of the vast disparity between their skills of the old and the skill level they have now.

To a developer who still hasn't learned more than a few techniques, this is of little consequence. However, this becomes a very painful handicap for those who lose a lot by making such a transition.

~ 5th May, 1:25AM