Live data from Hacker News

Ask HN: How do you learn new libraries without much documentation?

news.ycombinator.com

51–56 of 56 posts

Re: Ask HN: How do you learn new libraries without much documentation?

#51

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…

[deleted]

Re: Ask HN: How do you learn new libraries without much documentation?

#52

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

Boggles my mind that somebody would buy a tool that would require familiarising themselves with reverse engineering tools. I mean how ridiculous a product is that ?

Re: Ask HN: How do you learn new libraries without much documentation?

#53

Earlier 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…

Plus, if you want to just jump based on keywords ctags is more than enough and support is built into most decent editors.

Re: Ask HN: How do you learn new libraries without much documentation?

#54

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

Well yeah I guess this is what some people actually do. Personally I would never want to work this way though. And besides, there is probably no-one that would document all they know any way. Simply because no-one has time to write everything down and no-one has the time to read all that text. But aiming for good documentation is still a good thing IMO.
Post reply on HN