
Diving into Other People's Code - lihaoyi
http://www.lihaoyi.com/post/DivingIntoOtherPeoplesCode.html
======
SanderMak
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.

~~~
jessegreathouse
Yea that's true. Often it's not the code that's as difficult as the build
specifications of the project.

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

[http://davidvgalbraith.com/how-i-fixed-atom/](http://davidvgalbraith.com/how-
i-fixed-atom/)

HN discussion:

[https://news.ycombinator.com/item?id=10993470](https://news.ycombinator.com/item?id=10993470)

------
mikekchar
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.

------
mooreds
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.)

~~~
civilian
> (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.

~~~
mooreds
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".

~~~
throweway
Thats has how i took it

------
egraether
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/](https://www.coati.io/)

------
speedkills
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.

------
jessegreathouse
> 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.

~~~
speedkills
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.

------
throwaway3301
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!

------
chris_wot
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.

~~~
chris_wot
OK, this has inspired me to write my own blog post for LibreOffice newbies:

[http://randomtechnicalstuff.blogspot.com.au/2016/03/tips-
for...](http://randomtechnicalstuff.blogspot.com.au/2016/03/tips-for-
libreoffice-newbies.html)

------
nevster
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

------
z3t4
You should try this as a learning exercise.

