I learned a valuable lesson that day: Build it when you really need it. It's highly likely that you will never need it.
Bonus points if it is something complicated that needs to be repeated occasionally.
If it is something that needs half an hour reasearch and careful treading before getting the desired result and it costs you basically zero to save it in a script, just do it.
Then wrapping my head around monster script is additional work I need to do on top of understanding system that is changed.
I argue that it might be quicker to understand system on its own and make changes manually than rely on someone else script.
In the end if script works it works time money saved - when it breaks it is more work and now there are 2 things one has to figure out.
That is why I'd rather have smaller scripts that do parts of bigger job instead of someone dropping "just run this and it will do everything for you" type of scripts.
No, your in house scripts are not documentation, because they provide little context or rationale. In many cases they make the system more opaque by masking fundamental admin actions inside poorly commented wrappers.
There is no substitute for well written documentation
Also the time spent building the first tool probably includes a quantity of "overhead" (auth, logging, etc.) which gets quickly amortised on subsequent tools.
Not writing the admin tool might save time in the short term. But as I'm serving you with reports from the database and changes directly in it, I'm not doing other productive work. So you get the reports sooner and the time it takes to give you one is pretty quick.
But that task could have been done by you if you knew SQL. Or a junior programmer. Or by the admin tool.
And I could have spent that time developing customer features (or the admin tool.)
If manually providing reports uses up a lot of your time, you can always build the admin tool. But if you build a tool that no one ends up needing, or if building it takes more time than you save, you can’t exactly un-build it and get your time back.
I think the point at which we differ is that I actually prefer the "Oh #&@$ Solution". Part of it is to avoid building tools that I never end up using. But even if I do use a tool a lot, I would still rather slow development later rather than sooner.
For example, I'm the only engineer, building an admin tool means product development stops, whereas if I wait until we've hired another engineer it means it only slows down by 50%. Or, if we only have a few months of runway, it's much more valuable for me to work on things that increase revenue or decrease costs in terms of actual dollars than things that make the company more efficient.
Obviously these are contrived examples, but the general theme here is that time now is more valuable than time later. So the further into the future something is expected to pay off, the more suspicious of it you should be.
Source: I am writing three services at this point that are mostly Middleware to deal with the lack of native federation for certain services we use.
Building an authenticated admin UI for something is a lot of work.
Adding a "see most recent orders" page to an existing admin UI can take just a few minutes, once that framework is in place.
That said — if I’m just looking at data, it usually takes me a pretty long time to outgrow poking around the database with a read-only user.
This take is correct IMO - it's only worth building a tool if it saves you more time than it takes to develop. This is why Retool exists - if building/changing an admin tool takes about as much time as assembling a Keynote presentation, then the economics of using custom software to solve small problems start to work out in your favor.
I loved building tools and did it to get better/ faster at writing scripts and/or for fun eg trying to solve puzzles.
I would try and write tools/ scripts for anything
This helped me to get faster at writing tools - to the point where I automated a large porportion of my job - allowing me to spend more time on working on the stuff I liked - leading to me moving away from Admin
my own name for this rule of thumb. based on the story about the MIT campus where they put in grass but no sidewalks, and then waited to see what kind of natural trails formed from natural walking and biking. then put sidewalks there
some of these tasks when caused by human error the better idea is to make it more difficult to break the system than just easier to fix it and allowing the user or admin to fix it on their own hides the issues away
Let's say there is some weird service that you sometimes need to manually restart in a very specific order for maintenance. The hard (time intensive) task is figuring out the right incantations and the order to do it. It is however not time intesive at all to store those incantations in a shell script.
So not saving that in a script risks you (or a co-worker) having to go through this again, potentially missing some important aspect and wasting time and energy.
Sometimes the work is "making the script beautiful and universal" and then you should indeed consult that xkcd.
Sometimes the work is spitting the commands you had to figure out anyways into a shell script in 5 seconds. Then it is a no brainer to do it, because it will safe you time even if you use it only once.
One thing the time-based framework doesn’t account for is the mental energy you could save.
A small example: I sell a software product, and every now and then someone would ask for an invoice. So I’d have to look up the order, copy an ID and an email, make a PDF, and email it over. Was it hard? No, it took 2 minutes. But I loathed doing it.
So I wrote a little invoice page that looks up their order and let’s them put in whatever info they need, and generates a PDF. It took a day or two. I’m 99% sure this will never ever pay off in terms of time savings, but it gives me great joy to know that I will never have to do that energy-sapping task again.