3 ms·
This is such a major effort: getting up to speed on existing code bases to the point you can add to them. I feel for the author of this comment, you want to he
by samsquire 3y ago
This is such a major effort: getting up to speed on existing code bases to the point you can add to them.
I feel for the author of this comment, you want to help out and work on stuff you have energy at the beginning, I find it easier to write my own code than to get up to speed with someone else's code. Because you lose steam or the activation energy to get the project built and ran and then played with and customised/changed/"hacked on" is a major effort.
I have been thinking a lot on an idea inspired by compiler design: intermediate representations and term rewriting.
If software features were an arbitrary stack of crisscrossing intermediate representations that are rewritten and mutually recursive/referential or parsed or transpiled into actual code, then we could inspect the intermediate representations to work out how things work.
It would be nice to narrow down on a piece of behaviour and see how it works from end-to-end. But in practice, you have an opaque wholeness of a codebase to understand.
A modern system or codebase at a company or mature open source project: it's like those games of wooden sticks or wooden bricks jenga where they're arranged in a pile and you're piling things on-top of things and if you unsettle it slightly, it falls over or doesn't work.
I used a piece of software called OpenGrok which renders a large code base as clickable surfable wiki in the browser. So you can explore codebases.
I have a primitive python SQL database on my github that can execute simple graph cypher queries, simple joins of multiple tables, "dynamodb" style queries and document database queries.
- diggan 3y ago> This is such a major effort: getting up to speed on existing code bases to the point you can add to them. It's a great thing that different projects have different scopes! If you're just looking to contribute to some project to gain experience, it might be a good idea to start with some smaller scoped-project before jumping into larger ones. For example, if you're interested to contributing to the core of Kubernetes, maybe start by contributing to a plugin that interact with Kubernetes. Eventually, while trying to contribute to the plugin, you get indirectly exposed to some of the internals of the parent project, and eventually you'll be able to faster jump into contributing to Kubernetes itself.