| I'm a pretty big division of labor fan. If the tool works, and I don't have any better ideas myself, and it's not going to lock us into piles of hacky scripts forever, I'm all for it. They solved the problem, they're a professional with the same rank as me, they can do whatever they want. I'm interested in products and features, not endless code polishing. But I would still be far more excited to hear "Hey check out this declarative framework I found" than "I wrote a bash script that does stuff". A lot of the time the in house solution doesn't have many advantages besides hackers love of elegance and minimalism. Some of these internal tools.get pretty extreme, like full DSLs that could have been python libraries. It's like when people use dd over Etcher. The load time and disk space of Etcher has no real practical significance, and people do in fact make mistakes with dd all the time. I don't care if it's 80MB, it's a solved problem, and a repeatable process that you can teach in seconds(By saying "just use Etcher to flash it"). I could build something better than Etcher in a week, I'm sure. But that would be another thing to maintain, another internal repo to tell people about, documentation to write, cross platform issues that could pop up, etc. Maybe they even integrate workarounds for OS or hardware bugs that I have no clue about. I have been that coworker wanting to try something new. I've built systems at home for personal use. And nearly every. single. time. I wind up ripping them out and replacing them with something off the shelf. Still, I am not the police. If you're making custom tools, you're probably one of those hacker types with a really active mind who has a need to do things they can deeply understand, and I sure don't want to be the reason the smart people all get bored and quit! Unless it's really extreme you're making the whole codebase into an unprofessional tinkering project. Then you're probably not helping the product... |
At the end of the day I guess my experience has shown me that if given a nudge, people are capable of solving problems with automation, that can yield order of magnitude improvements in this or that process. I don't care if the automation is a custom script or an off the shelf tool, but let's do it. I want to share that inspiration with the field - we can automate that and we may be rewarded for it, let's give it a try and earn the nice things that we want!
In my experience quick scripts that leverage existing tools, that abide by some conventions, and that show some consideration for others using them - are great! Every software team has a bucket of routine tasks that developers need to do - are they one liners in the veterans' command line histories that are passed around in chat, or are they organized and documented in source control as "tools"? The later, please. (thank you framework designers that allocate a place for these as do Rails, Elixir, and npm (even if I hate the way npm does it ;) ).
It sounds like you've been burned by too much reinventing the wheel and not invented here. Like I said, it's possible to overdo it. What you've experienced sounds shitty, and I'm sure you're just trying to steer people away from the pitfalls you've observed, which is noble.
I just come down the other way: people declining to try to invent better solutions has been more of an impediment to my team's success, than their over-eagerness.