Be careful with the right tool for the right job
Published on
When I started my career I quite never understood the idea of settling down with some language/technology. It always sounded wrong to do it because you have to “use the right tool for the right job” and “if it doesn’t look like a nail, don’t use a hammer”, but today I think that, as always, the reality is a bit more complex.
I still think that, as a developer, I am more capable and productive learning more and more languages/platforms/tools/frameworks/etc. With this mindset I have the know-how to suggest new solutions, avoid bad ways and keep my mind sharp, thus, being a better professional.
However, when it comes to the enterprise world, especially bigger companies, it makes sense to focus on some specific technologies (specially if you didn’t enter the microservices team… more about it in another post). And the reasons for this are many:
Easier to hire
Hiring is a time and money consuming activity. You can’t expect to hire the first interviewee, and you can’t expect people to enter in your team ready to tackle the hardest problems. Having a smaller stack helps getting people aboard. Instead of listing a lot of technologies and practices in an opening, you can search for someone who has a specific knowledge and various areas of interest.
It’s like “We need you to know this, and a little bit of this and that” instead of “We need you to know everything”.
Easier to maintain
As we know, maintenance is where we spend the biggest amount of time in software development. Having your systems running in similar technology makes it easier to build skills useful to maintain the whole park.
The idea is “If you learn this technology in system X, you will have a better time understanding system Y also”.
Padronization
Some tools have an entire ecosystem dedicated to them (like sonar -> java, or code climate -> ruby). By standardizing your park you can use the full benefits of metrics for better planning and, also, team member rotation become a reality less painful.
Think about “We can standardize our pipelines if we use technology X for backends and technology Y for frontends”.
Mitigate even more the knowledge silos
Streching a little bit, I know, but it potencially avoid the “Carl’s the only one that knows how this works”.
Ideally it would be “everybody can work on any system in the company”.
The list of benefits go on, but you got the idea.
Again, I still think that developers should be hungry for knowledge but we must be careful to not build an environment which we don’t even know what is written on what and people keep entering and leaving your organization. Sometimes it’s important to think in the long run, focusing on the “if I were to leave the company tomorrow, would it be easy for them to maintain what I’ve done?”.
Big hugs
Comments
I feel that comments on specific blogs have been dying down as the times goes. If you have any questions or want to talk about the post, contact me through the below links.