self-collaboration
Table of Contents
self-collaboration refers to anything you do that builds off your own work.1
1. Key component
For self-collaboration to happen, in what you produced in each work session, there has to be all 3 of the following components:
- Documentation
Description of the whole project.
For a program project, how to install, what are modules are designed to be there, how they work…
This will be how you imagine the project, and you need that picture intact and consistent across sessions.
- Log
What happened in the session, what have you done.
Did you wrote a bunch of function for a feature? you may forgot about them if you don’t log you have written them and read those logs. I would.
In a single session this will conveniently be in your working memory and something you look back a lot on, as you localize yourself on your process.2 This is part of your perception of your progress and part of the whole schedule.
- Agenda
What you planned to do.
An example would be, you wrote a converter, your wote a predicate, and you plan to write a filter using the predicate, then use the filter in another function to collect eligible items.
In a single session this will also naturally be in your working memory, not only with the big stages “this feature then that feature, this module then that module”, but also with the details in implementation where you do the universal subgoaling on the job3
2. Key actions
- Read Documentation and Log of previous sessions
- It is important that you always read them before jumping right in. It is to make sure that the important thing you discovered last session and over the month is still important to you today.
- Log whatever you do
- Because it is impossible(or there’s no guarantee) that you will still remember them tomorrow. And you’ll forgot there’s something you have done that would make development a lot easier, or mess up the system big time. It’s usually something the will mess up the system big time.
- Log the agenda you have in mind whereever you had one
whether it is a simple checklist of helper functions which leads to a powerful robust function or big feature you want to do next. This will enable you of next session to start where you left off this session, like there’s no gap between.
When you have a todo list or an agenda for the project, it usually goes with a big agenda area with one main line of big tasks and there’s small agenda of how you’re gonna do each one of them. It’s ok to have multiple big lines in the big agenda area, or just mention a vision you had of them in a log; it’s ok to have lots of small agenda in the logs with checked and unchecked items. Whatever feels right at the moment with your own ideas will work.
- spend time review and edit all 3 parts of them
- so you get familiar with them. It will make them better, more detailed/actionable and practical4.
Backlinks
50 first dates note
- why
- . So waking up I’m just as clueless to the situation as Luce, and similar to Luce, I have to do some self-collaboration every morning so I can push things forward
- what this note do
Footnotes:
Say you write a program on your own in 10 different sessions, then in the 9th session, you are collaborating of virtually 8 other person who did the previous 8 sessions of works.
“I have written the converter of time object and second, and next up I’m gonna use it to write a predicate testing if a time object falls in a time period.”
“I want to write a function to collect all my notes from in between 2 days; so I need a filter to filter out those note” , and then when writing the filter - “in the filter I’ll need a predicate to test if the create time of the note is in between those 2 days”, and when you go around your way to write the predicate - “so I need to convert the time object to seconds since 1970-01-01, and compare the seconds”.
here practical refers to how realistic the task is, how much information you have about real world you have there, like an excerpt of API document, of a blog post, reddit discussion thread etc.