Comment by soiltype
1 year ago
This is exactly the kind of stuff I'm most interested in finding on HN. How do other developers work, and how can I get better at my work from it?
What's always interesting to me is how many of these I'll see and initially think, "I don't really need that." Because I'm well aware of the effect (which I'm sure has a name - I suppose it's similar to induced demand) of "make $uncommon_task much cheaper" -> "$uncommon_task becomes the basis of an entirely new workflow/skill". So I'm going to try out most of them and see what sticks!
Also: really love the style of the post. It's very clear but also includes super valuable information about how often the author actually uses each script, to get a sense ahead of time for which ones are more likely to trigger the effect described above.
A final aside about my own workflows which betrays my origins... for some of these operations and for others i occasionally need, I'll just open a browser dev tools window and use JS to do it, for example lowercasing a string :)
https://raw.githubusercontent.com/fliptheweb/bash-shortcuts-... has served me very well.
One of the very few things I like about macOS is that it rebinds the CUA key from Ctrl to Cmd, freeing up Ctrl for these Emacs-style text navigation keybinds. It's odd to me that seemingly zero Linux distros/DEs do this by default.
Wow thanks, I'm tattooing this on my right hand now. :)
No one tell him about `set editing-mode vi` or `info readline`
1 reply →
This is one of the things I miss the most about hacker conferences. The sharing of tools, scripts, tips and tricks. It was, and still is, just as fun as trading cards.
What's a hacker conference?
A conference in which hackers congregate.
My favorite recent one was Handmade Seattle, but that one's kaput as of this year, and it seems everything else along similar lines is overseas and/or invite-only.
I'd love to see a cost benefit analysis of the author's approach vs yours, which includes the time it took the author to create the scripts, remember/learn to use them/reference them when forgetting syntax, plus time spent migrating whenever changing systems.
Not all time is created equal. I’ll happily invest more time than I’ll ever get back in refining a script or vim config or whatever, so that later, when I’m busy and don’t have time to muck around, I can stay in the flow and not be annoyed by distractions.
Sometimes it's rather matter of sanity than time management. I once created systemd service which goes to company web page and downloads some files which I sometimes need. This script was pretty hacky, and writing it took me a lot of time - probably more than clicking manually on this page in the long run. But clicking it so annoying, that I feel it was totally worth.
why is this interesting to you? the whole point of doing all of this is to be more efficient in the long run. of course there is an initial setup cost and learning curve after which you will hopefully feel quite efficient with your development environment. you are making it sound like it is not worth the effort because you have to potentially spend time learning "it"? i do not believe that it takes long to "learning" it, but of course it can differ a lot from person to person. your remarks seem like non-issues to me.
It's interesting because there's a significant chance one wastes more time tinkering around with custom scripts than saving in the long run. See https://xkcd.com/1205/
For example. The "saves 5 seconds task that I do once a month" from the blog post. Hopefully the author did not spend more than 5 minutes writing said script and maintaining it, or they're losing time in the long run.
12 replies →
Because some of them OP said they use a few times a year. This means they'll probably use it like 150 times in their life. If it saves a minute each time, but it takes 5 hours to create it and 5 hours to maintain it over the years, then it's not really a win.
> reference them when forgetting syntax
If you have to do that, the script needs improvement. Always add a `--help` which explains what it does and what arguments it takes.
If you write these sorts of things in Python, argparse is worth investigating: https://docs.python.org/3/library/argparse.html - it's pretty easy to use, makes it easy to separate the command line handling from the rest of the code, and, importantly, will generate a --help page for you. And if you want something it can't do, you can still always write the code yourself!
3 replies →
I love this kind of stuff too, but too many times over the years I've found myself in environments without some of these higher level and more niche tools (including my own dot files), or the tool ends up abandoned, and I struggle to remember how to use the basics/builtins. I've gotten a lot more conservative about adopting them because of that.
Pretty much my take as well. I imagine spending a few hours a month customizing your shell and text editor (hello vim/Emacs folks) to be more efficient and powerful is _great_ for developers who rarely leave their own workstation. But I spend much of my day logging into random hosts that don't have my custom shell scripts and aliases, so I'm actively careful not to fill my muscle memory with custom shortcuts and the like.
Of course, I _do_ have some custom shell scripts and aliases, but these are only for things I will ever do locally.
Loved it too. Made me want to write a schema for other developers to add (tool, frequency_of_use, category, description) tuples.