Document the steps to setup dev environment in your own words and highlight the issues that you run into
Lots of people are commenting saying they have problems with this.
The first thing I do when working on an unfamiliar project is to write a SHELL SCRIPT that records everything I did. I keep that at the root of the git repo, usually as "run.sh".
For example here is what I did when hacking on Kernighan's awk 5 years ago:
So now 5 years later I can see exactly where I downloaded the source from. I count how much source code there is in a repo to get a feel for it, and I have that exact command recorded.
And I was trying to figure out how much test coverage there is, so I ran a bunch of gcov stuff, which involve Python.
The shell script may have some problems now, but the point is that I can tell within 10 seconds what I did 5 years ago. And I can fix it in a few minutes.
It costs so little to write down these commands that it's worth it. If you try to make it really rigorous then you're not going to do it. Th
In summary, I suggest becoming SHELL LITERATE and checking in shell script with comments. The point is that shell is ALREADY what you're typing, so you can save it exactly like it is in a file, and run it later. (You can also use a Makefile, but then you lose that property, and that matters. Make has all the gotchas of shell plus some more.)
Another meme I use is "never remember a port number".
I have had the experience of pair programming with people and they are trying to remember port numbers. Sometimes the server doesn't print it out to the console.
Sometimes they go digging through their notes, or they go digging through Python source code to find the port number.
I always know the port number because I put it in a shell script at the root of the repo.
If you automate stuff like this you can get to the meat of the problem a lot faster.
Lots of people are commenting saying they have problems with this.
The first thing I do when working on an unfamiliar project is to write a SHELL SCRIPT that records everything I did. I keep that at the root of the git repo, usually as "run.sh".
For example here is what I did when hacking on Kernighan's awk 5 years ago:
https://github.com/andychu/bwk/blob/master/run.sh
So now 5 years later I can see exactly where I downloaded the source from. I count how much source code there is in a repo to get a feel for it, and I have that exact command recorded.
And I was trying to figure out how much test coverage there is, so I ran a bunch of gcov stuff, which involve Python.
The shell script may have some problems now, but the point is that I can tell within 10 seconds what I did 5 years ago. And I can fix it in a few minutes.
It costs so little to write down these commands that it's worth it. If you try to make it really rigorous then you're not going to do it. Th
In summary, I suggest becoming SHELL LITERATE and checking in shell script with comments. The point is that shell is ALREADY what you're typing, so you can save it exactly like it is in a file, and run it later. (You can also use a Makefile, but then you lose that property, and that matters. Make has all the gotchas of shell plus some more.)
https://news.ycombinator.com/item?id=25400278
(I have a couple upcoming blog posts that mention this. Another view on this, regarding releases: http://www.oilshell.org/blog/2020/02/good-parts-sketch.html#...)
----
Another meme I use is "never remember a port number".
I have had the experience of pair programming with people and they are trying to remember port numbers. Sometimes the server doesn't print it out to the console.
Sometimes they go digging through their notes, or they go digging through Python source code to find the port number.
I always know the port number because I put it in a shell script at the root of the repo.
If you automate stuff like this you can get to the meat of the problem a lot faster.