←back to thread

1212 points speckx | 1 comments | | HN request time: 0.207s | source
Show context
oceanplexian ◴[] No.45672984[source]
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 native UNIX implementations. If it's more complicated than that, I'll code it in Python or Go.

replies(22): >>45673276 #>>45673397 #>>45673416 #>>45673493 #>>45673595 #>>45673606 #>>45673685 #>>45673787 #>>45673894 #>>45674022 #>>45674094 #>>45674098 #>>45674837 #>>45675554 #>>45675916 #>>45675962 #>>45676837 #>>45676947 #>>45677013 #>>45678082 #>>45679080 #>>45680781 #
chis ◴[] No.45674098[source]
I think it's more likely to say that this comes from a place of laziness than some enlightened peak. (I say this as someone who does the same, and is lazy).

When I watch the work of coworkers or friends who have gone these rabbit holes of customization I always learn some interesting new tools to use - lately I've added atuin, fzf, and a few others to my linux install

replies(2): >>45674487 #>>45675898 #
heyitsguay ◴[] No.45674487[source]
I went through a similar cycle. Going back to simplicity wasn't about laziness for me, it was because i started working across a bunch more systems and didn't want to do my whole custom setup on all of them, especially ephemeral stuff like containers allocated on a cluster for a single job. So rather than using my fancy setup sometimes and fumbling through the defaults at other times, i just got used to operating more efficiently with the defaults.
replies(3): >>45674715 #>>45674779 #>>45676671 #
nijaru ◴[] No.45674779[source]
You can apply your dotfiles to servers you SSH into rather easily. I'm not sure what your workflow is like but frameworks like zsh4humans have this built in, and there are tools like sshrc that handle it as well. Just automate the sync on SSH connection. This also applies to containers if you ssh into them.
replies(1): >>45674909 #
theshrike79 ◴[] No.45674909[source]
I'm guessing you haven't worked in Someone Else's environment?

The amount of shit you'll get for "applying your dotfiles" on a client machine or a production server is going to be legendary.

Same with containers, please don't install random dotfiles inside them. The whole point of a container is to be predictable.

replies(4): >>45675131 #>>45675655 #>>45675868 #>>45680273 #
YouAreWRONGtoo ◴[] No.45675868[source]
Someone else's environment? That should never happen. You should get your own user account and that's it.
replies(2): >>45678328 #>>45680811 #
theshrike79 ◴[] No.45678328[source]
I don’t even get an account on someone else’s server. There’s no need for me to log in anywhere unless it’s an exceptional situation.
replies(1): >>45680066 #
YouAreWRONGtoo ◴[] No.45680066[source]
This doesn't make sense.

You said you were already using someone else's environment.

You can't later say that you don't.

Whether or not shell access makes sense depends on what you are doing, but a well written application server running in a cloud environment doesn't need any remote shell account.

It's just that approximately zero typical monolithic web applications meet that level of quality and given that 90% of "developers" are clueless, often they can convince management that being stupid is OK.

replies(1): >>45680523 #
1718627440 ◴[] No.45680523[source]
They do get to work on someone else's server, they do not get a separate account on that server. There client would be not happy to have them mess around with the environment.
replies(1): >>45682361 #
YouAreWRONGtoo ◴[] No.45682361[source]
By definition, it the client Alice gives contractor Mallory access to user account alice, that's worse than giving them an account called mallory.

Accounts are basically free. Not having accounts; that's expensive.

replies(1): >>45684333 #
1. nomel ◴[] No.45684333[source]
They specifically mentioned service accounts. If they’re given an user account to login as, they still might have to get into and use the service account, and its environment, from there. If the whole purpose was to get into the service account, and the service account is already setup for remote debug, then the client might prefer to skip the creation of the practically useless user account.