5 ms·
I'm not convinced that those are good reasons to use it locally. All of them seem like crutches that allow you to rely on magic that someone else got to work so
by ohazi 7y ago
I'm not convinced that those are good reasons to use it locally. All of them seem like crutches that allow you to rely on magic that someone else got to work so that you can delay or avoid taking the time to understand what your software actually relies on.
In my experience, that kind of understanding is critically important, especially if you want to be the kind of engineer who can find the root cause a problem and fix it permanently, rather than the kind who just shrugs and blames a configuration error that they don't actually understand, and that might happen again tomorrow or next week.
If you actually need to deploy things to dozens of servers at once, then you might have a good reason for looking at these tools. But this should come after you understand what your software is doing, what it needs, how it works, what the dependencies need, etc.
- MuffinFlavored 7y ago> especially if you want to be the kind of engineer who can find the root cause a problem and fix it permanently In my experience, when it comes to team building, managers usually want to spend just enough resources to have 1-2 members of the caliber you are describing on a team. Once 1-2 are in place, you can add 6-8 mid/junior people who go to those 1-2 when there are the deep/hard problems you are describing.
- indigodaddy 7y agoConcur. Jibes with my experience (with myself not being one of those 1 or 2).
- s_m_t 7y agoIn my experience it usually is some sort of stupid config error from which I glean no deeper understanding. I'd much rather rely on magic than go around chasing bugs that I might not ever be able to convince the owner of a repository to fix, assuming the thing is even open source to begin with.