Learning and being informed about new technologies is a habit of mine. I regularly visit webpages and follow RSS feeds to see what is happening and what are the new tools being developed.
While I learn and be aware about these new tools, I rarely switch what I use with shinier and newer incarnations of the ones with the same role or functionality. Moreover, I defend using the same tools for a long time despite their shortcomings. More importantly, I defend using stable workflows (or stacks if you prefer the term) for a long time, despite the disagreements with my peers.
Solving problems once
The biggest reason I'm using same tools and workflows for a long time is solving every problem once. When starting to build a workflow, selection of tools and making them work together takes a great deal of time, which is gone unnoticed due to excitement of starting a new project.
After setting the workflow for the first time, there will be inevitable problems and paper cuts which hamper both the development and mental flow. Interruption of this flow makes the developer lose a lot of time, since human brain works best when it's warmed up and focused on a deep subject for a while.
When these problems are solved, and documented if possible, the workflow starts to settle down. This settling is similar to annealing. It's a slow and delicate process, but when it's complete; the result is robust, high quality and pretty indestructible under normal usage conditions.
After this workflow and tools around it is settled, it can be lifted and applied to new projects with ease. The time required is minuscule when compared to doing everything all over again, every time, and this saved time allows for nifty things, namely iteration and mastery.
Reproducibility
Another benefit of having a well defined and well polished workflow is reproducibility. This affects not only the developer, but potential contributors of the project. When one has a reproducible workflow built around well-defined tools, it can be reproduced with much less effort.
This is crucial for making collaboration on a project easy and effortless. When somebody new to a project can setup the workflow in an hour and start hacking away, the contributor is more likely to be happy and motivated. This initial momentum will greatly improve both developer and user ergonomics, because if a user who knows how to program starts to use the tool, and setup its development environment in a coffee break, they can both use and improve the tool at the same time. As a result, the chance of getting patches from the same user will go up.
Mastery
As I noted in a previous post, I love the concept of craftsmanship and mastery. The results created by this dedication and discipline is always high quality, even exceptional.
I personally love to create tools for myself, and want these tools be in the same league with the more established tools, regardless of the category. Writing high quality code and robust tools which are production ready and complete in every sense is a great source of pride and satisfaction for me.
On the other hand, trying to reach that level of quality is a great learning experience. Because, finishing the second 90% of the work needs discipline, dedication and elaborate work.
Reaching that level of finesse is possible when one knows the tools at hand down to its smallest details and edge cases. Similarly, to be able to focus on the product to maximize its quality, one needs to trust the tools to the point they become invisible or extension of oneself. This again requires using the tool for an extensive time and being familiar with it. As a result, a stable and well worn workflow with established tools is essential in this process.
Licenses
While tangential, the licenses of the tools used in the workflow has a great impact on the workflow itself, because it affects the portability of the workflow and the possibilities to share it greatly.
I personally prefer free software over open source, because when combined with a free software project and proper documentation, all moats are removed between the project and possible collaborators.
Using workflows consisting free software tools as much as possible guarantees that the workflow will be stable in the long term, because the probability of tools going proprietary or being developed as closed source forks is way lower.
Lastly, the four freedoms about software is essential and non-negotiable from my perspective. As a result, everything I put out and the tooling required to build and modify is free software, and I have no plans or intentions to change that to more permissive models.
Building workflows is fun and exciting, but building them over and over limits the time which can be used for creating even more exciting things.
Until next time,
Be kind.