4 ms·

Possibly my all-time favourite XKCD, Is it worth the time?¹, demonstrates two important points. If you only do something very rarely anyway, spending time to au

Possibly my all-time favourite XKCD, Is it worth the time?¹, demonstrates two important points. If you only do something very rarely anyway, spending time to automate it won’t have a great ROI. But for things you do moderately often that take a minute or even just a few seconds, you can afford to spend a surprisingly large amount of time optimising them and still get a big pay-off over a time frame measured in years. I view time spent learning to use my tools efficiently and automating common tasks as a sound investment. Editors are a great example. Sure, I could fire up any of the usual suspects and write code somewhat productively. But in my fully customised editor of choice, I can insert and adapt common code patterns that would take me 10–30 seconds to type out fully in mere moments using templates and macros. I can jump to any position visible on-screen with around three keystrokes. I can see syntax highlighting for various file types that I use all the time, including some unusual ones that don’t have definitions readily available, and warnings for several different programming languages in real time as I work. These save me a few seconds every time I use them, but how many times is that every day? The effort to set them up has probably repaid itself 100x over by now! And the lack of latency is also a qualitative improvement since it means once I’m ready to start writing, I can do so roughly as fast as I can think, instead of constantly being held back and interrupted for a moment. ¹ https://xkcd.com/1205/ https://xkcd.com/1205/

tdumitrescu 2y ago
> If you only do something very rarely anyway, spending time to automate it won’t have a great ROI For code-editing, maybe. But in general software engineering, there are tasks that I have to do maybe once a year or less that are always way more painful than they need to be because I don't remember the details, and anytime I automate even part of them (or yes, just document a little better), it turns out to be well worth it. Stuff like bootstrapping new environments, some database-related work, etc.
- cratermoon 2y ago
  Do hard things more often. https://martinfowler.com/bliki/FrequencyReducesDifficulty.html https://martinfowler.com/bliki/FrequencyReducesDifficulty.ht...
- wrycoder 2y ago
  It may not be worth the time to automate those, but I always take the time to document them, usually in Obsidian, where I can easily find them later.
- hereonout2 2y ago
  Absolutely, I try to "automate" or at least have scripted almost everything I do. I do this almost always for reproducibility and documentation purposes first.
- nottorp 2y ago
  Pasting all the commands in a doc that you keep around seems to give 90% of the benefit of automating it for 1-4 times per year tasks. It's not typing the commands that takes time, it's remembering what commands to type.
- Chris_Newton 2y ago
  I’m a big fan of writing things down for future reference. Keeping a journal with things like exactly which commands I used, or transferring that knowledge to something like a README or a wiki page for others to see, is a low effort but sometimes high reward habit. Even for something done only rarely, saving a lot of time next time can justify the documentation effort. Similarly, if the automation effort is literally only copying those commands verbatim into a shell script or similar, that’s often time well spent. The trap, as the XKCD helpfully demonstrates, is when you then start spending significantly longer on making that script more “flexible”. Turning hard coded values into parameters. Looking context up from the environment. On multiple development platforms. In staging, UAT and production deployments too. With detailed help text to explain it all and say what the defaults for everything are if you don’t specify them explicitly. And then it turns out that you only actually run that script once every six months anyway and never use 95% of that extra flexibility anyway…
throwaway0sa09 2y ago
I have that XKCD printed out and posted on my cubicle wall. I refer to it quite frequently as justification as to why some requested feature/etc. should NOT be implemented. I use it so much that many non-technical people at my company have started adopting it as well.

tdumitrescu 2y ago

> If you only do something very rarely anyway, spending time to automate it won’t have a great ROI For code-editing, maybe. But in general software engineering, there are tasks that I have to do maybe once a year or less that are always way more painful than they need to be because I don't remember the details, and anytime I automate even part of them (or yes, just document a little better), it turns out to be well worth it. Stuff like bootstrapping new environments, some database-related work, etc.

cratermoon 2y ago
Do hard things more often. https://martinfowler.com/bliki/FrequencyReducesDifficulty.html https://martinfowler.com/bliki/FrequencyReducesDifficulty.ht...
wrycoder 2y ago
It may not be worth the time to automate those, but I always take the time to document them, usually in Obsidian, where I can easily find them later.
hereonout2 2y ago
Absolutely, I try to "automate" or at least have scripted almost everything I do. I do this almost always for reproducibility and documentation purposes first.
nottorp 2y ago
Pasting all the commands in a doc that you keep around seems to give 90% of the benefit of automating it for 1-4 times per year tasks. It's not typing the commands that takes time, it's remembering what commands to type.
Chris_Newton 2y ago
I’m a big fan of writing things down for future reference. Keeping a journal with things like exactly which commands I used, or transferring that knowledge to something like a README or a wiki page for others to see, is a low effort but sometimes high reward habit. Even for something done only rarely, saving a lot of time next time can justify the documentation effort. Similarly, if the automation effort is literally only copying those commands verbatim into a shell script or similar, that’s often time well spent. The trap, as the XKCD helpfully demonstrates, is when you then start spending significantly longer on making that script more “flexible”. Turning hard coded values into parameters. Looking context up from the environment. On multiple development platforms. In staging, UAT and production deployments too. With detailed help text to explain it all and say what the defaults for everything are if you don’t specify them explicitly. And then it turns out that you only actually run that script once every six months anyway and never use 95% of that extra flexibility anyway…

throwaway0sa09 2y ago

I have that XKCD printed out and posted on my cubicle wall. I refer to it quite frequently as justification as to why some requested feature/etc. should NOT be implemented. I use it so much that many non-technical people at my company have started adopting it as well.