How to join a team and learn a codebase (2020)

Also, it's probably worth taking note of 'fresh eyes' because they have the advantage of hindsight which is often good. That said, there usually complex elements of incumbencies so I do think it should be some time before people have too much lean in.

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.

Recently I decided to go through `Growing Object-Oriented Software - Freeman, Pryce` (and actually finish working through it this time) with the goal of understanding what "proper TDD" is supposed to look like. Something interesting I noticed is almost all the complaints I've seen as reasons against TDD/certain testing methods all seem to be examples the authors use as how not to use TDD/testing. It seems to me that a lot of developers have just learned _of_ these techniques by name, and haven't really put a lot of time/effort into practicing their application and instead just seem to write them off on face value or by the literal interpretation of their names.

One example, a lot of people I speak with seem to think TDD is very literal "write a _unit-test_* for everything before you write the implementation OR ELSE...", but of course there's a lot more nuance than that depending on the situation. The book actually puts a huge emphasis on having your initial test(s) be end-to-end tests that slice through the system as a whole, with the idea being to create nested feedback loops of varying granularity/abstraction to allow you to iterate without fear. This was something I never heard emphasized at all when I started learning about TDD, or hell even in a paid course my employer put us through by a "TDD expert".

I should also clarify, I only consider these claims from developers that have a proven track record of working on large/complex systems since, well, those who don't probably haven't cultivated their ideal workflows/approaches yet (or just haven't been given the opportunity to showcase them, as is common in large companies).

* I emphasize unit-test because a lot of code bases I've worked in rarely have anything other than just unit-tests...

The insights that you get from coming at the problem with fresh eyes are invaluable and you really don’t want to waste those. But many things on that list will evaporate once you have a bit more understanding of the project.

(I still like to make “check in a fix / improvement to the dev environment documentation” the first task for a new starter though, as there’s usually a typo or update required somewhere).