A project is a repository §

This is the realization I arrived after much exploration in the Epistemology of work itself. I can’t brute force a structure for all projects; each project come with unique requirements and demands, therefore, unique solutions. But one statement remained true and gained traction on all my enterprises: a project is a repository.

Not only a repository, but my personal repository. It is my view of the project, my personal interpretation of all the chaos around it. Notes are my personal breadcrumbs and help me remind a future self where I left. And with which difficulties I left - generally the reason I did in the first place.

A project from the company I am working in, a project with a team, artifacts, Kanban, sprint, processes. A complex array of stuff. The only way I can sanely manage this is by having my own view of all. My own project. It represents my interests and is in the business of helping me understand the things I am working on. Also, in my repository, everything is a file.

A new issue becomes a file there. A new meeting is also one. An internal process gets also its own file. Borrowing from Unix, and its derivatives, this axiom is more relevant than I thought it would be. A file is manageable and should ideally have high cohesion within itself. Files help me store thoughts and understand the world around me. They loosely resemble the way I think. I’m not versed in neuroscience at all and thus would be dumb to induct anything about the way humans generally think. But for me it works.