[iforgotpassword]

Agree. Interns or grads always want to throw whatever the most hyped tool in some domain currently is at every remotely fitting problem. Ansible all the things!

That's not to say you should always roll your own. This is one of those things that's really hard to become good at: Decide early on whether to go with an existing solution or create something from scratch. (and if you go for an existing solution, which one?)

There's many arguments for both sides, one thing often mentioned is that settling for some popular solution or framework will make it easier for others to get into your project, but if you bend over backwards to get three different tools to do what you want instead of writing a hundred lines of bash, you might be doing something wrong.

[cheez]

What I do is decide that I am in charge of defining the machine, and the tools implement the machine. The tools are a means to an end. If the tools don't exist to implement the machine, I write them. If they do exist, great.

[mcny]

> That's funny. I was the opposite. When I was younger, I would just say "lets default to other people's solution to similar problems and move on" but as time went by, I've become more "let's define our problems well and find surgical solutions by others". It's a slight difference but makes a huge difference in productivity.

I thought the same way except I was even more insane. I thought lets just teach everyone English and we won't have to do any internationalization/localization.

[908B64B197]

But then you lose the advantage of being the first to localize for a given market!

But seriously, in a lot of cases, translating and localizing is actually the easy part of internationalizing a business.

[mcny]

> But seriously, in a lot of cases, translating and localizing is actually the easy part of internationalizing a business.

In my defence, I was not a very travelled child. I didn't even know about all the different kinds of power socket standards around the world.