How do you think this correlates with the strategy of some companies to standardize tooling? By standardizing tooling it makes it easier to handle personnel migrations (switching teams) and to get additional eyes on a problem. If everyone speaks the same languages per se then it's easier to get additional support from more people. Solutions are also easier to maintain because in theory all people know fewer solutions that fulfill more problems.
I'm interested in hearing both support for and against such a strategy.
Trouble maker and Problem solver ⚙️🔧
Loves simplicity, hates bullshit 💩.
Productivity obsessed, avid learner 🖥🚀
Sport and outdoor freak 🧗⛰
Metalhead 🎸🤘 Father of 2 👨👩👦👦
Opinions are my own
This is a very interesting question. And I will throw my Senior Engineer / Solutions Architect wild card here: It depends. 😅
I am not a fan of Tech Zoos, having worked in many company, and in many different teams within the same company, it is never so nice, having to understand and learn new tools and frameworks everytime you switch team or project. Here Trello, there Jira, here React, there Vue, here Laravel there Symphony, here Jenkins, there GitlabCI, here Jest there AVA. The list can go on with whatever IDE, Test Framework, CI solution, MVC framework, and of course language, here node, there python, or java or php.
Of course it can be more efficient, productive and practical for a company to enforce some specific tools or frameworks, on the other end, it is also this diversity which make our job intersting and challenging. and that does not constraint our creativity and I would not like a workplace where everything is set in stone.
What i mean in the post is not constantly hopping from one solution/tool to another, rather, constantly evaluating if our choice are "automatic" and lazy or really make sense. (often it is not about choosing Svelte or React, but maybe not using any of them, about avoiding a complex setup for ECS when a tiny apigatewy would do the job.)
Of course general guidelines from CTO are important - why evaluating for every project if using AWS or Google as cloud providers, or why considering GO if there are no resources in the company knowing that language - but some flexibility is important.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
How do you think this correlates with the strategy of some companies to standardize tooling? By standardizing tooling it makes it easier to handle personnel migrations (switching teams) and to get additional eyes on a problem. If everyone speaks the same languages per se then it's easier to get additional support from more people. Solutions are also easier to maintain because in theory all people know fewer solutions that fulfill more problems.
I'm interested in hearing both support for and against such a strategy.
This is a very interesting question. And I will throw my Senior Engineer / Solutions Architect wild card here: It depends. 😅
I am not a fan of Tech Zoos, having worked in many company, and in many different teams within the same company, it is never so nice, having to understand and learn new tools and frameworks everytime you switch team or project. Here Trello, there Jira, here React, there Vue, here Laravel there Symphony, here Jenkins, there GitlabCI, here Jest there AVA. The list can go on with whatever IDE, Test Framework, CI solution, MVC framework, and of course language, here node, there python, or java or php.
Of course it can be more efficient, productive and practical for a company to enforce some specific tools or frameworks, on the other end, it is also this diversity which make our job intersting and challenging. and that does not constraint our creativity and I would not like a workplace where everything is set in stone.
What i mean in the post is not constantly hopping from one solution/tool to another, rather, constantly evaluating if our choice are "automatic" and lazy or really make sense. (often it is not about choosing Svelte or React, but maybe not using any of them, about avoiding a complex setup for ECS when a tiny apigatewy would do the job.)
Of course general guidelines from CTO are important - why evaluating for every project if using AWS or Google as cloud providers, or why considering GO if there are no resources in the company knowing that language - but some flexibility is important.