3 ms·

I wrote an entire essay about this at https://tech.genericwhite.com/remembering-details-of-programs-and-environments https://tech.genericwhite.com/remembering-d

I wrote an entire essay about this at https://tech.genericwhite.com/remembering-details-of-programs-and-environments https://tech.genericwhite.com/remembering-details-of-program... but here is the gist... The main things I have figured out are, 1) use a script to contain all the stuff I know I will not remember, 2) structure projects so that there is a script for each environment I have to work on, 3) be rigorous in making all that structure the same because I know I will not remember where the script is if it's different, 4) use aliases (also, btw, listed in my .bash_profile) to execute them so I am not confused and 5) make sure to write all the fussy details in those scripts and keep them up to date and refactored frequently.

nicbou 5y ago
I echo a similar sentiment: https://nicolasbouliane.com/blog/no-script-is-too-simple https://nicolasbouliane.com/blog/no-script-is-too-simple If you can't run your project without pouring through documentation, you need to fix that. Projects should be easy to get back into after a long absence. In a business, it makes onboarding cheap and easy.
3pt14159 5y ago
lol, are you me? Only thing you didn't mention is the importance of .git/info/exclude so my custom scripts don't distract me on a git diff.
- tqwhite 5y ago
  Yes. I am you. I do that, too.
whacked_new 5y ago
We're generally in agreement, and at the risk of exposing my biases... nevermind, my biases are already exposed -- I discovered that wrapping the aliases inside a shell.nix expression to be activated by running `nix-shell` has the added benefit of locking down the execution environment down to the compiler version. The most illuminating experience for me was doing this for a Python 2.7 project, cloning the repo, running nix-shell, and it Just Worked. I was shocked (in a good way)
codethief 5y ago
I cannot agree enough. Items 1 and 5 especially are worth reiterating: How to run/test/build things should be entirely documented in terms of code, not README files, unless there is no other way. README instructions become outdated quickly and are hard to test in a reproducible manner. IMO, every project should have one single CLI presenting the developer with everything she or he can do (pull or update dependencies, build, run, test, …). Just like applications come with a UI for the user (whether the user is a real person or just some other application), every project should have a proper user interface for the developer.

nicbou 5y ago

I echo a similar sentiment: https://nicolasbouliane.com/blog/no-script-is-too-simple https://nicolasbouliane.com/blog/no-script-is-too-simple If you can't run your project without pouring through documentation, you need to fix that. Projects should be easy to get back into after a long absence. In a business, it makes onboarding cheap and easy.

3pt14159 5y ago

lol, are you me? Only thing you didn't mention is the importance of .git/info/exclude so my custom scripts don't distract me on a git diff.

tqwhite 5y ago
Yes. I am you. I do that, too.

whacked_new 5y ago

We're generally in agreement, and at the risk of exposing my biases... nevermind, my biases are already exposed -- I discovered that wrapping the aliases inside a shell.nix expression to be activated by running `nix-shell` has the added benefit of locking down the execution environment down to the compiler version. The most illuminating experience for me was doing this for a Python 2.7 project, cloning the repo, running nix-shell, and it Just Worked. I was shocked (in a good way)

codethief 5y ago

I cannot agree enough. Items 1 and 5 especially are worth reiterating: How to run/test/build things should be entirely documented in terms of code, not README files, unless there is no other way. README instructions become outdated quickly and are hard to test in a reproducible manner. IMO, every project should have one single CLI presenting the developer with everything she or he can do (pull or update dependencies, build, run, test, …). Just like applications come with a UI for the user (whether the user is a real person or just some other application), every project should have a proper user interface for the developer.