Use the right tool for the job.
I had been guilty for so many years failing to apply that simple old saying. Until I realised that if your job is not well designed you cannot find the right tool. Until I realised that you cannot know every existing tools. Until I realised that knowing your tools is sometimes more effective than picking the perfect one. Until I learnt the hard way that in an evolving context you have to adapt your tool across time. Today I’m more inclined to say: “Use the right toolset for the team at a given moment.”
It might be counter-intuitive at first but after all our job is to solve pretty basic technical problems: display that data, allow interactions with this one, make sure everything is smooth for everybody, secure as much as you can. Nothing more.
We’re not paid to write code, we’re paid to add value (or reduce cost) to the business. Yet I often see people measuring their worth in code, in systems, in tools—all of the output that’s easy to measure. I see it come at the expense of attending meetings. I see it at the expense of supporting other teams. I see it at the expense of cross-training and personal/professional development. It’s like full-bore coding has become the norm and we’ve given up everything else.
The problem arises when we introduce layers to solve these basic needs, even worse when they are not resilient enough to guarantee their accessibility toward as much people as we can. Frameworks are popular today — bashing them too. We are often forgetting that framework starts with frame. This is the frame within which the author of the framework have (or worse, has?) its own job. When you choose a framework you are betting that your job will stay within its frame. Otherwise it’s a nightmare because breaking the frame will dismantle the consistency you were looking for at first with that solution. When all you have is a framework, everything you achieve looks like a patchwork.
A micro-framework tends to extend that frame and to turn it into something more loose that you will strengthen yourself for a given domain in order to accomplish the initial job. The result is still a frame but your current job hopefully is at the center with more room to evolve and find its audience. The trade-off is that you will have to write more code and your team must be concept-competent, not framework-competent.
When your team acquires experience about a given tool it is a short-term advantage over your competitors, you will be able to iterate quickly. When your team acquires knowledge on a given concept it is a long-term goal for your product, you will be able to pivot faster. The balance on the business side is to still be alive when it happens. The goal on the developers side is to still be competent when the framework and/or the product fades.
