Live data from Hacker News

Scripts I wrote that I use all the time

evanhahn.com

21–30 of 408 posts

Re: Scripts I wrote that I use all the time

#21
post #7

Earlier quoted context omitted.

The nato phonetic alphabet one cracked me up. My dude you don't need that, call center employees don't know it, just say S as in Sugar like ur grandma used to.

The nato phonetic alphabet is still useful even if the other party doesn't know it, I've used it a bunch of times on the phone to spell out my 10- letter last name. Saves quite a lot of time and energy for me vs saying "letter as in word" for each letter.

Right but it's not much more useful than any other phonetic alphabet the other party doesn't know, including the one you make up on the spot.

Re: Scripts I wrote that I use all the time

#22
Historical note: getting hold of these scripts by chatting to various developers was the motivation for the original 2004 "lifehacks" talk[1][2]. If you ever get into an online argument over what is a "life hack" and what isn't, feel free to use short scripts like these as the canonical example.

Otherwise, I am happy to be pulled into your discussion, Marshall McLuhan style[3] to adjudicate, for a very reasonable fee.

[1] https://craphound.com/lifehacksetcon04.txt

[2] https://archive.org/details/Notcon2004DannyOBrienLifehacks

[3] https://www.openculture.com/2017/05/woody-allen-gets-marshal...

Re: Scripts I wrote that I use all the time

#23

It's weird how the circle of life progresses for a developer or whatever. - When I was a fresh engineer I used a pretty vanilla shell environment - When I got a year or two of experience, I wrote tons of scripts and bash aliases and had a 1k+ line .bashrc the same as OP - Now, as a more tenured engineer (15 years of experience), I basically just want a vanilla shell with zero distractions, aliases or scripts and use…

I am going through a phase of working with younger engineers who have many dotfiles, and I just think "Oh, yeh, I remember having lots of dotfiles. What a hassle that was."

Nowadays I just try to be quite selective with my tooling and learn to change with it - "like water", so to speak.

(I say this with no shade to those who like maintaining their dotfiles - it takes all sorts :))

Re: Scripts I wrote that I use all the time

#25

It's weird how the circle of life progresses for a developer or whatever. - When I was a fresh engineer I used a pretty vanilla shell environment - When I got a year or two of experience, I wrote tons of scripts and bash aliases and had a 1k+ line .bashrc the same as OP - Now, as a more tenured engineer (15 years of experience), I basically just want a vanilla shell with zero distractions, aliases or scripts and use…

I prefer using kubectl than any other method so i have plenty of functions to help with that. I'd never consider using python or go for this although I do have plenty of python and go "scripts" on my path too.

Re: Scripts I wrote that I use all the time

#27

It's weird how the circle of life progresses for a developer or whatever. - When I was a fresh engineer I used a pretty vanilla shell environment - When I got a year or two of experience, I wrote tons of scripts and bash aliases and had a 1k+ line .bashrc the same as OP - Now, as a more tenured engineer (15 years of experience), I basically just want a vanilla shell with zero distractions, aliases or scripts and use…

Yeah - been there, done that, too. I feel like the time I gain from having a shortcut is often less that what I wound need to maintain it or to remember the real syntax when I'm on a machine where it's not available (which happens quite often in my case). I try to go with system defaults as much as possible nowadays.

Re: Scripts I wrote that I use all the time

#28
post #6

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_ta…

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.

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.

Re: Scripts I wrote that I use all the time

#30
post #28

Earlier quoted context omitted.

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.

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

Post reply on HN