Diving into Other People's Code

Love this write-up! It reflects my experience in similar situations: getting things up and running from source often too painful.

Problem is, every (build/config/packaging) tool brought in to 'solve' this problem only adds another point of failure and confusion.

Similar: "How I fixed a bug in Atom".

http://davidvgalbraith.com/how-i-fixed-atom/

HN discussion:

https://news.ycombinator.com/item?id=10993470

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.

I think that understanding and building a mental model of the workings of an existing program is the second most important developer skill.

This seems like a great example of how to build that mental model, from strategy to 'in the weeds' step by step instructions.

(The most important skill is building a mental model of the workings of reality.)

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.

https://www.coati.io/

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.

I have experienced similar things trying to work on open-source software (or other software projects).

This must have been a ton of work to put together. Thank you for this!

Oh, this is perfect! Wish I'd read this before starting with LibreOffice.

Actually, I guess I can still use this. Perhaps I might tell our GSoC students about it.

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

You should try this as a learning exercise.