Hacker News Reader

Comment by lpapez | Hacker News Reader

Unless you are truly pushing the envelope of tooling development, I consider learning to use an existing tool well far more important than inventing a new one. The developer tooling has become so complex that it takes a truly exceptional individual to build a tool on their own, and the vast majority of tools are built by teams of people.

That is why you rarely meet developers who build their own tools, it's a often futile effort usually better spent elsewhere.

In fact I would go on to say that in my personal view people who do roll their own tooling usually do so due either to ignorance of existing tools or as a fun little side-project.

Woe be to those who push their opinionated tools onto their teammates...

View on HN

You define tooling too narrowly. That custom script that the team uses to cut a release branch and notify people with contributions on the branch that it's being deployed? That's a tool, that itself uses off the shelf tools/products (eg. perhaps Python, GitHub, Slack). And it could possibly be a very helpful tool that saves manual effort and improves results, for a fairly low cost.

Sure you can spend too much time and effort building tools, rather than focus on meeting the most important business objectives, and we've all met developers that do that. But you can certainly build too few tools, as well.

Somewhere there's probably something that already does that though, and it probably also does 5 other things currently done by a custom script.

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.

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

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.

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?

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.

Yeah, but that's "somewhere" and "something" - it's likely that the time spent finding the particular thing you need is greater than it takes to write your own script, and that doesn't even include time to understand how the thing you found, and a host of unfortunate consequences of adding a new third-party dependency to your project...

The time to understand that thing is a time investment that can be used on any similar project, and makes me a more effective developer. Plus it exposes me to the current popular ideas of what best practices look like.

Presumably any well run place wants their developers to have some level of continuing education stuff, right?

If someone shows you how to take a stick and a stone and make a hammer, and you imitate, you're certainly not 'pushing the envelope of tooling development', but you're still making a tool.

As the most prevalent & familiar here modern example, I'd suggest writing to .bashrc & using ssh-keygen are 'making tools' in the relevant sense.

Attaching a the stone to a stick makes a very advanced hammer. While we've been using hammers without sticks for over 2 million years, hammers with sticks only came around 30k years ago.

And none of the improvements on hammers for specific actions count. The orientation or prongs on a modern hammer isn't going to stymie a neanderthal unless they are destudding drywall.

Every abstraction is a tool that we build for ourselves. If you’re not building those, wtf are you even doing?

Please assume the lowest possible bar for “abstraction” in my argument. A function that calls 2 other functions is an abstraction.

True. But the quality of an abstraction is also significant.

A poor abstraction is costly in complexity. In a chain of tools, even modest complexity multiplies, and quickly becomes unmanagable. Whereas a clean abstraction (ideally) resets complexity to zero.

Reply on news.ycombinator.com