C asked me why I had a commentary page yesterday and I struggled to give an answer. I eventually gave one, but it felt so underwhelming I don’t even remember what it was I said at that time. I’ve called it underwhelming because the decision to put commentary pieces up was very intentional, but for some reason, I got cold feet when it was time to articulate that reason to someone else. I want to briefly do that here.
I have not been writing code for a remarkably long time (it’s only been 6 years), but I can identify the integration of Git into my workflow as a true inflexion point. Nowadays, it’s an indispensable part of how I develop things: if I’m working on a website and at some point decide to add, say a media query to a CSS script, I can simply add the changed file(s) to the staging area and then make a commit describing what the change is. Across the project lifecycle, these commits become an incredible log of how the repository may have morphed and changed. It’s like having a time machine that allows me to reference different points throughout development to get an overall sense/idea of what the source code looked like then. This simplified explanation of how I use git in a project setting is something I wanted my commentary page to replicate. What I mean is that I’m viewing myself (or my consciousness) as a repository or project being worked on. The files and the source code are fleeting thoughts that swarm around within me from time to time. Whenever these feelings present themselves strongly, putting them in the commentary segment is my way of making a "commit" to the repository (that is me).
I am a work in progress, and there are so many more levels I have to go. I expect my thoughts, feelings, psyche and understanding of things to morph and change over time. These entries that I try to churn out whenever I can help me create a log of my development across space and time (just like how commits in a GitHub repo can give you a really nice description of how a project has developed up until a certain point). Now why is this log useful to me? I’ve come to understand how human it is to err. I don’t expect a lot of the things I’ve written here so far to be entirely correct, truthful or precise. In fact, I’m sure that if I revisit some entries, I will be able to identify things I no longer think are correct/true. This is because time has passed (albeit a few months) since writing some of these entries and being able to construct (new) distinct thoughts about things is a natural by-product of a person’s mental changing over time. Having this log can help me sniff out sub-optimal heuristics that I once leaned into. It's a place to challenge, revisit, rework and re-evaluate things on a consistent basis (like I would on a code repository).
And so, in a large way, this is not a blog. I am not really doing this for an audience. I’m logging a lot of this for my future self to re-explore and re-evaluate, whilst drawing from residue that would be my mental state at a certain point in time. I think future me would be grateful that I’m logging data on things I find exciting. Revisiting old(er) archives might also lead to epiphanies like this one. Concerning writing quality, Joel makes me understand that being able to sit and cringe at sentences constructed months ago is a helpful indicator of growth.
I think it’s also good value to leave a good deal of this writing here because I think it gives my space heaps of personality and realness. Another positive is that writing and deploying entries on a site largely accessible to people allows me to subtly practise how to take up space.
I also don’t think that I’ve ever really finished writing an entry. Whenever I think I’m done with a markdown file, there’s a consistent niggling feeling at the back of my head that I could have done more or constructed some paragraphs in a better way. Publishing these things online is my way of beating the critic in my head and accepting that nothing can ever really be perfect. I want this acceptance to seep into other areas of my life too, especially when it comes to shipping software. I want to become comfortable with shipping something quickly and continuously improving it over time.
The experience of going from development to deployment is also a good one. It’s satisfying when I’m able to beat the initial ambiguity that comes from starting to arrive at the finish line. I experience this a lot when I’m writing code: the problem often feels vague, ill-defined and confusing. Still, more often than not, keeping at it leads to fruition. Writing these entries mimics that: I usually have a vague idea of what it is I want to say, but the concreteness only comes after reworking several sentences and paragraphs recursively.
So, I want to puncture space and time with these commits for as long as I can. And for my future self, for the habits I want to form, for my ability to think and create, and for the transformative process that I envision consistent writing can bring with it.
C asked me why I had a commentary page yesterday and I struggled to give an answer. I eventually gave one, but it felt so underwhelming I don’t even remember what it was I said at that time. I’ve called it underwhelming because the decision to put commentary pieces up was very intentional, but for some reason, I got cold feet when it was time to articulate that reason to someone else. I want to briefly do that here.
I have not been writing code for a remarkably long time (it’s only been 6 years), but I can identify the integration of Git into my workflow as a true inflexion point. Nowadays, it’s an indispensable part of how I develop things: if I’m working on a website and at some point decide to add, say a media query to a CSS script, I can simply add the changed file(s) to the staging area and then make a commit describing what the change is. Across the project lifecycle, these commits become an incredible log of how the repository may have morphed and changed. It’s like having a time machine that allows me to reference different points throughout development to get an overall sense/idea of what the source code looked like then. This simplified explanation of how I use git in a project setting is something I wanted my commentary page to replicate. What I mean is that I’m viewing myself (or my consciousness) as a repository or project being worked on. The files and the source code are fleeting thoughts that swarm around within me from time to time. Whenever these feelings present themselves strongly, putting them in the commentary segment is my way of making a "commit" to the repository (that is me).
I am a work in progress, and there are so many more levels I have to go. I expect my thoughts, feelings, psyche and understanding of things to morph and change over time. These entries that I try to churn out whenever I can help me create a log of my development across space and time (just like how commits in a GitHub repo can give you a really nice description of how a project has developed up until a certain point). Now why is this log useful to me? I’ve come to understand how human it is to err. I don’t expect a lot of the things I’ve written here so far to be entirely correct, truthful or precise. In fact, I’m sure that if I revisit some entries, I will be able to identify things I no longer think are correct/true. This is because time has passed (albeit a few months) since writing some of these entries and being able to construct (new) distinct thoughts about things is a natural by-product of a person’s mental changing over time. Having this log can help me sniff out sub-optimal heuristics that I once leaned into. It's a place to challenge, revisit, rework and re-evaluate things on a consistent basis (like I would on a code repository).
And so, in a large way, this is not a blog. I am not really doing this for an audience. I’m logging a lot of this for my future self to re-explore and re-evaluate, whilst drawing from residue that would be my mental state at a certain point in time. I think future me would be grateful that I’m logging data on things I find exciting. Revisiting old(er) archives might also lead to epiphanies like this one. Concerning writing quality, Joel makes me understand that being able to sit and cringe at sentences constructed months ago is a helpful indicator of growth.
I think it’s also good value to leave a good deal of this writing here because I think it gives my space heaps of personality and realness. Another positive is that writing and deploying entries on a site largely accessible to people allows me to subtly practise how to take up space.
I also don’t think that I’ve ever really finished writing an entry. Whenever I think I’m done with a markdown file, there’s a consistent niggling feeling at the back of my head that I could have done more or constructed some paragraphs in a better way. Publishing these things online is my way of beating the critic in my head and accepting that nothing can ever really be perfect. I want this acceptance to seep into other areas of my life too, especially when it comes to shipping software. I want to become comfortable with shipping something quickly and continuously improving it over time.
The experience of going from development to deployment is also a good one. It’s satisfying when I’m able to beat the initial ambiguity that comes from starting to arrive at the finish line. I experience this a lot when I’m writing code: the problem often feels vague, ill-defined and confusing. Still, more often than not, keeping at it leads to fruition. Writing these entries mimics that: I usually have a vague idea of what it is I want to say, but the concreteness only comes after reworking several sentences and paragraphs recursively.
So, I want to puncture space and time with these commits for as long as I can. And for my future self, for the habits I want to form, for my ability to think and create, and for the transformative process that I envision consistent writing can bring with it.