Automation is not about completing tasks faster, it's about correctness, predictability, consistency, reproducibility, developer workflow, processes as code, code reviews, audit trails, knowledge sharing etc.
It's about being paged for an issue in production and not having to wonder if John entered a typo in his laptop and deployed by mistake in the wrong environment.
There's also the ikea effect of building something for just yourself but that's just a bonus if you aren't on a team.
It works, it produces the right number and probably only takes a few minutes of one person's time each month.
I'm still for automating this end to end, because it makes it auditable and tamper proof.
If the data is produced by some ETL job then any problems are bugs in the job, not because someone made a typo (or in the worst case falsified figures, etc - basically it's good to remove humans from the process)
This, 100x. The internal tools function is often forgotten by other teams when dealing with things like ongoing education, professional development, code quality initiatives and even hiring practices. (Ironically, because a lot of those things end up leveraging tools that the tools teams own!) The tools team should be a rotation or an area for open contribution, not a permanent destination or specialty.
> There are downsides, of course. Toolsmiths are at least one step removed from the actual work that's going on – it can be hard to explain what we built to anyone without context (or violating NDAs). Depending on how enlightened your management is, your team might also be severely underfunded for what it needs to accomplish, mainly because the effect of good tools isn't generally easy to measure.
The other downside to tool building is that when you build something, you're competing against "there's no tool for this that fits our need", but when you're maintaining and evangelizing the tool your competition is often "open source software on the internet", which can outdevelop you by sheer weight. So you should always bias heavily for buy/download over build, and you should always minimize how much you fork and customize those tools let you get left behind by the broader community.
I think I might still push for build (or maintain the ability to heavily customize) for things that are particularly important for areas the company aims to have a strong advantage in/are business critical.
We’ve been building something with this in mind; to try to make it way easier to focus on the important parts of tooling, and abstract away all the annoying boilerplate. You might be interested in checking it out at https://ab.bot. We’re in the current YC batch and had a Launch HN a few weeks ago.
I wrote about our love of toolmaking here: https://blog.ab.bot/archive/2021/07/15/tools-for-inside-the-... :)