1. learn a good editor. 2. write a script to concatenate all the code files in a folder, separated by filenames. 3. pipe that result to your editor. 4. use your editor's "find" functionality. By reading the entire source code in a single file, you have global knowledge of the entire codebase. All the information is available to you. I suggest you try it before dismissing the idea, as I once did. https://github.com/sh…
Ask HN: How do you learn new libraries without much documentation?
51–56 of 56 posts
Re: Ask HN: How do you learn new libraries without much documentation?
#52Look at the library's tests. It's quicker and better for learning functionality than "just read the source code". If it's proprietary and closed and obfuscated then you need to familiarise yourself with reverse engineering toolsets.
Re: Ask HN: How do you learn new libraries without much documentation?
#53Earlier quoted context omitted.
Sure, that's fine. Personally, I hate dealing with vim plugin nonsense, and especially with getting vim environments working on a remote server inside tmux. But whatever works.
The other reason I don't favor this approach is that it totally ignores the fact that the organization of files and filenames also give you valuable semantic information. If I had a library, that, for some insane reason, decided to scramble its source across a gigabyte of filenames generated by a hash function, then I would definitely choose your approach. But most libraries (even horrible internal libraries) aren't…
Re: Ask HN: How do you learn new libraries without much documentation?
#54There is lots of good advice about how to figure out how it works in this thread. One piece of advice I have is write formal documentation of some form as you figure it out. Share it as widely as possible. If nothing else, it will be very useful for you and your co-workers in the future. It sounds like there is some sort of community you can share it with. Ideally there would be some way to contribute it back the to…
If you think that this knowledge will be important to your employer then try not to share it too much in an organised and documented way but rather help others on specific issues. This is more effective to establish yourself as the expert and go to person. If you write a comprehensive documentation they others need you less.