Although it is only a bullet point at the end of a very long article, the "verify everything" is really important. Small misunderstandings can suck up huge amounts of time. If the code has a test suite, it can often be a huge benefit to write a couple of tests in the area of code you are working on just to see if you are correct. And as the author mentions, "printf debugging" is worth its weight in gold.
One of the mistakes I see more junior programmers make is underestimating how much time they need to understand a piece of code. They rush through it, neglecting to build a solid base for their understanding.
On the opposite side, RMS's timeless advice about debugging is very important: don't debug code that isn't broken. You need to narrow your scope or you will be reading code forever. One of the best points about this article is pointing out that you need to have a well defined goal when you are reading the code. You should then restrict yourself to understanding the code around that goal, ignoring the rest.
> (The most important skill is building a mental model of the workings of reality.)
Sorry, that's just too funny. It has a "in order to make an apple pie from scratch, you must first create the universe" kind of attitude. It kind of makes sense, computer science is just applied physics and logic.
Ha! I wasn't aiming for that. I was thinking more along the lines of "understanding the real world requirements, and having a mental model complete enough to see where the success and error cases would lead you".
Reading this really reminded me of my time as an intern. I think I spent about 90% of my time reading source code then and doing exactly what what's described in this article. A lot of developer time is wasted reading existing source code and I think one problem is the lack of the right tools.
That's why I started building Coati, an interactive source explorer for C/C++. Coati allows you to see the relationships of classes and functions and thereby makes it easier to get an overview of your codebase. This makes the familiarization step of the process much easier.
I really enjoyed this article, largely because I saw the author take 5 hours to do this and go through all of the same pains I do when I attempt to make a contribution to an open source project. There is always part of me that feels I am not learning a new code base fast enough and imagines other, better developers are starting out so much faster than me so knowing someone whose work I respect as much as his goes through the same troubles we all do just adds to my perseverance to keep struggling through until I get it figured out.
> Being a professional software engineer, on the other hand, very often does not involve "writing lots of code"! More often, you spend your time spelunking deep into other peoples code: code you do not understand, did not write, and have possibly never seen before in your life.
It's worth noting that this experience in a dynamically typed language like Python or Javascript can be a lot more pronounced than a strongly typed language.
Maybe, but to be clear Li Haoyi writes a ton of very well typed Scala code. It just happens he used Python for this particular blog post. I did not get the feeling that this was just the perspective of a programmer working in a dynamically typed language.
Makes me think of 1% inspiration, 99% perspiration - the effort just to get things running is enough to sap the enthusiasm - you just have to keep pushing through
Problem is, every (build/config/packaging) tool brought in to 'solve' this problem only adds another point of failure and confusion.