[CoffeeOnWrite]

If your coworker wrote such a script, would you respond positively or gloomily?

Maybe they researched and found actually all the options out there have whatever drawbacks that they don't fit the bill. Maybe they didn't bother to research because it only took them 10 minutes to script that manual process we perform multiple times a week, and they were curious to see if they could improve that. Maybe some of the 5 were pretty good actually, but the coworker has some specific ideas how their "6th" new tool could be better in certain important ways.

The good off the shelf tools make it easy to build on them with custom tools to fit your purpose.

I really don't mind if people lean a bit one way or the other in their inclination toward custom tools. But I do expect people to be supportive of attempts to build nice tooling, and show a curiosity toward the trade offs, and willingness to try an experiment.

Don't be afraid of building a tool, hacker friends. If nobody else displays an interest in what you build, or it doesn't turn out to really save time, or it costs too much to maintain.. you can ditch it! You are a professional with good critical judgment whose ability to improve the productivity of your group and provide repeatable "executable documentation" will carry you far in your career. Let your creativity shine, and have fun.

[eternityforest]

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...

[CoffeeOnWrite]

Thanks for your openness (sincerely).

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.

[asveikau]

Never heard of etcher, used dd for more than 20 years. Your comment is strange to me. You have some kind of problem with "people who use dd" instead of the thing I haven't heard of?

[eternityforest]

I don't have a problem with people who use dd, people can use whatever they want, disk flashing doesn't really need to be organization-wide standardized.

But if someone asks me how to flash a disk, I'll probably tell them I use Etcher.

It's a FOSS Electron-based GUI tool for flashing disks, which has a few extra features like verification, hiding things that aren't removable disks so you don't accidentally overwrite /, a progress bar.... and that's about it, aside from ads for Balena's other products.

But it works, it's what pretty much every beginner tutorial says to use, I've never overwritten the wrong thing(Like I did one time with dd a long time ago), and I don't really have much reason to go looking for alternatives.

It's also what I consider the canonical example of something GUI fans love, but CLI enjoyers hate.