đ Want to read A Half-Built Garden by Ruthanna Emrys ISBN: 9781250210999
I'm very pleased with tonight's project of packaging up hot sauce and oat milk in custom branded packets for Lily's upcoming "Stop Requested" trip!
It was a good chance to learn about mylar pouches and heat sealing.
It was a good chance to learn about mylar pouches and heat sealing.
Multnomah County Courthouse
Jury duty day 2
Hot sauce recipe live blog!
Step 1: Sautee chopped onion and garlic with some oil and salt in the instant pot until the onions are translucent
Step 1: Sautee chopped onion and garlic with some oil and salt in the instant pot until the onions are translucent
Came up with and tried a three phase pomodoro technique yesterday for working thru tasks and projects.
This three phase pomodoro cycle repeats and resyncs hourly. The three phases I came up with:
* physical tidying/cleaning
* physical processing
* digital processing
This worked quite well and I got a lot of things done, tasks completed or significantly advanced in ~6 hours.
Many of these were âannoyingâ or âboringâ but often not immediately ânecessaryâ tasks that I had left undone (procrastinated) for many weeks, especially with all the travel I have had in the past two months nevermind first two-thirds of this year.
I took the basic idea of a pomodoro 20-minute timeboxš, figured three of those fit into an hour, and picked three things that were cognitively different enough that switching from one to the other would use different cognitive skills (perhaps different parts of my brain), thus allowing a form of cognitive rest (rather than fatigue, and giving one part of my brain a chance to rest, while using others).
This eliminated the need to take âpomodoro breaksâ, whether 5 minutes or 20-30 minutes and it felt nearly effortless (actually fun at times) to cycle through the three phases, repeatedly, for hours on end. Before I knew it six hours had gone by and many tasks had been completed.
The three 20 minute phases have the advantage of quickly determining at any time which phase you should be in by checking your watch/phone for :00-:20, :20-:40, :40-:00. If you happened to be âout of phaseâ, e.g. ârun overâ because you were finishing something up, rather than stressing about it, switch to the in-progress phase and pick-up a new task accordingly.
A 20 minute timebox also has the advantage that tasks are less annoying or boring when you know that in less than 20 minutes you will be able to set them down and switch to something else.
There was an iterative sense of expectation of novelty. The expectation of even only a little novelty was enough to make things go more quickly in the present, and even provide a game-like encouragement of see how far I can get with this boring or annoying task in the little time remaining. Could I even complete this one task in less than 20 minutes?
I think repeating three phase pomodoro cycles worked particularly well on a Saturday afternoon when I had very few external interrupts. I think that was key. It gave a sense of momentum, if actual flow², that itself felt like it gave me a source of energy to keep going. Iâm not sure it would work during normal work hours in any highly or even partially collaborative environment.
Interruptions for physical needs, moving around, drinking, eating etc. were something that I allowed at any time, and that removed any stress about those too.
I rarely set any count-down timers. A few times when I recognized I was starting or picking up a task that I might get absolutely lost in (such as many digital processing tasks like email), I set an explicit count-down timer for the end of the phase. These timer alarms certainly helped to give me permission to put down that task (for now) and switch, rather than feeling compelled to âcompleteâ it which I know from experience can often take much longer, and leave me feeling more tired, perhaps even too tired to do anything else.
There was also a sense of relief in knowing that even if I didnât finish a particular task by the end of a phase, I would have the opportunity to pick it right back up in 40 minutes. Or maybe by then I would have decided to work on a different task in that phase.
This three phase pomodoro technique worked well for tasks that are not very cognitively engaging (hence boring or annoying). Such tasks have low context, and thus low context-switching costs, but still benefit from taking mental breaks and resets.
In contrast, any deeply cognitively engaging, thinking, or creative tasks, like inventing, coding, writing, typically have a much higher context-switching costs, and in my experience work better when you can set aside a longer block of time to allow yourself build up all the context and then joyfully explore the depths of whatever it is youâre creating.
That being said, I think some creative tasks (depending on the person) could benefit from time-boxing. Like having a constraint to write a short blog post in the morning before a workout or breakfast. Worth trying such one-off timeboxes or even formal pomodoros and seeing if they help complete some creative tasks faster (or more often) over time.
#productivity #pomodoro #pomodoroTechnique #gtd #gettingThingsDone #Saturday
References:
š Apparently I misremembered 20 minutes instead of the typical pomodoro 25 minutes: https://en.wikipedia.org/wiki/Pomodoro_Technique
² https://en.wikipedia.org/wiki/Flow_(psychology)
This three phase pomodoro cycle repeats and resyncs hourly. The three phases I came up with:
* physical tidying/cleaning
* physical processing
* digital processing
This worked quite well and I got a lot of things done, tasks completed or significantly advanced in ~6 hours.
Many of these were âannoyingâ or âboringâ but often not immediately ânecessaryâ tasks that I had left undone (procrastinated) for many weeks, especially with all the travel I have had in the past two months nevermind first two-thirds of this year.
I took the basic idea of a pomodoro 20-minute timeboxš, figured three of those fit into an hour, and picked three things that were cognitively different enough that switching from one to the other would use different cognitive skills (perhaps different parts of my brain), thus allowing a form of cognitive rest (rather than fatigue, and giving one part of my brain a chance to rest, while using others).
This eliminated the need to take âpomodoro breaksâ, whether 5 minutes or 20-30 minutes and it felt nearly effortless (actually fun at times) to cycle through the three phases, repeatedly, for hours on end. Before I knew it six hours had gone by and many tasks had been completed.
The three 20 minute phases have the advantage of quickly determining at any time which phase you should be in by checking your watch/phone for :00-:20, :20-:40, :40-:00. If you happened to be âout of phaseâ, e.g. ârun overâ because you were finishing something up, rather than stressing about it, switch to the in-progress phase and pick-up a new task accordingly.
A 20 minute timebox also has the advantage that tasks are less annoying or boring when you know that in less than 20 minutes you will be able to set them down and switch to something else.
There was an iterative sense of expectation of novelty. The expectation of even only a little novelty was enough to make things go more quickly in the present, and even provide a game-like encouragement of see how far I can get with this boring or annoying task in the little time remaining. Could I even complete this one task in less than 20 minutes?
I think repeating three phase pomodoro cycles worked particularly well on a Saturday afternoon when I had very few external interrupts. I think that was key. It gave a sense of momentum, if actual flow², that itself felt like it gave me a source of energy to keep going. Iâm not sure it would work during normal work hours in any highly or even partially collaborative environment.
Interruptions for physical needs, moving around, drinking, eating etc. were something that I allowed at any time, and that removed any stress about those too.
I rarely set any count-down timers. A few times when I recognized I was starting or picking up a task that I might get absolutely lost in (such as many digital processing tasks like email), I set an explicit count-down timer for the end of the phase. These timer alarms certainly helped to give me permission to put down that task (for now) and switch, rather than feeling compelled to âcompleteâ it which I know from experience can often take much longer, and leave me feeling more tired, perhaps even too tired to do anything else.
There was also a sense of relief in knowing that even if I didnât finish a particular task by the end of a phase, I would have the opportunity to pick it right back up in 40 minutes. Or maybe by then I would have decided to work on a different task in that phase.
This three phase pomodoro technique worked well for tasks that are not very cognitively engaging (hence boring or annoying). Such tasks have low context, and thus low context-switching costs, but still benefit from taking mental breaks and resets.
In contrast, any deeply cognitively engaging, thinking, or creative tasks, like inventing, coding, writing, typically have a much higher context-switching costs, and in my experience work better when you can set aside a longer block of time to allow yourself build up all the context and then joyfully explore the depths of whatever it is youâre creating.
That being said, I think some creative tasks (depending on the person) could benefit from time-boxing. Like having a constraint to write a short blog post in the morning before a workout or breakfast. Worth trying such one-off timeboxes or even formal pomodoros and seeing if they help complete some creative tasks faster (or more often) over time.
#productivity #pomodoro #pomodoroTechnique #gtd #gettingThingsDone #Saturday
References:
š Apparently I misremembered 20 minutes instead of the typical pomodoro 25 minutes: https://en.wikipedia.org/wiki/Pomodoro_Technique
² https://en.wikipedia.org/wiki/Flow_(psychology)
Recently finished this (good, heavy, tip-of-an-iceberg) book on influence operations:
https://martymcgui.re/2024/09/05/222732/
Now watching how itâs playing out in todayâs (war and commercial) games industries. đł
đ Finished reading Stories Are Weapons: Psychological Warfare and the American Mind by Annalee Newitz ISBN: 9780393881516
Han Dynasty
đ Want to read American War by Omar El Akkad ISBN: 9781101973134
đ Want to read Says Who?: A Kinder, Funner Usage Guide for Everyone Who Cares about Words by Anne Curzan ISBN: 9780593444092
đ Want to read Mobility by Lydia Kiesling ISBN: 9781638930563
đ Want to read How We Show Up: Reclaiming Family, Friendship, and Community by Mia Birdsong ISBN: 9781580058070
đ Want to read Emergent Strategy: Shaping Change, Changing Worlds by Adrienne Maree Brown ISBN: 9781849352604
Fourth Avenue Pub
âď¸ I want the Read Write Suggest-Edit Accept-Edit Update Web.
The consumer Infinite Scroll Web leaves us feeling empty.
Too few of us participate in the Read Write Web, whether with personal sites or Wikipedia.
A week ago when we wrapped up #IndieWebCamp Portland and I was reading Kevin Marks (@kevinmarks@indieweb.social) live-tooting of the demosš, I noticed a few errors, typos or miscaptures, and pointed them out in-person.
Kevin was able to quickly edit his toots and update them for anyone reading, thanks to #Mastodonâs post editing feature and its support of #ActivityPub Updates. But this shouldnât require being in the same room, whether IRL or chat.
We should be able to suggest edits to each otherâs posts, as easily as we can reply and add a comment.
13 years ago I wrote²:
 âThe Read Write Web is no longer sufficient. I want the Read Fork Write Merge Web.â
Now I want the Read Write Suggest-Edit Accept-Edit Update Web.
The ⪠Reply button is fairly ubiquitous in modern post user interfaces (UIs).
Why not also a âď¸ Suggest Edit button, to craft a fix for a typo, grammar, or other minor error, and send the author for their review, and acceptance or rejection? Perhaps viewable only by the suggester and the author, to avoid "performative" suggested edits.
If the authorâs posts provide revision histories, when a suggested edit is accepted, a postâs history could show the contributor of the edit.
Instead of asking Kevin in-person, what if I could have posted special "Suggested Edit" responses in reply to his toots, for which he would receive special notifications, and could choose to one-click accept and update (or further edit) his toots?
To enable such UIs and interactions across servers and implementations, we may need a new type of responseÂł, perhaps with a special property (or more) to convey the edits being suggested.
There is documentation of this and similar use-cases, prior art / UIs, as well as some brainstorming on the #IndieWeb wiki:
* https://indieweb.org/edit
Our interaction after IndieWebCamp has inspired me to take another look at how can we design and prototype solutions to this problem.
For now, if you host your blog and posts as static files on GitHub (or equivalent), you could add a button like this to your posts alongside Like, Reply, Repost buttons:
âď¸ Suggest Edit
and link it to an edit URL for the static file for the post.
I donât use GitHub static files myself for posts, but hereâs an example of such an edit link for one of my projects:
https://tantek.com/github/cassis/edit/main/README.md
This will start the process of creating a âpull requestâ, GitHubâs jargonâ´ for a âsuggested editâ.
After completing GitHubâs ceremony of entering multiple text fields (summary & description), and multiple clicks to create said âpull requestâ, itâll be sent to the author to review. Presuming the author likes the suggested edit, they can perform the other half of GitHubâs jargon-filled ceremonies to âMergeâ or âSquash & Mergeâ, âDelete forkâ, etc. to accept the edit.
Itâs an awkward interactionâľ, however useful for at least prototyping a âď¸ Suggest Edit button on sites that store their posts as files in GitHub. Certainly worthy of experimenting with and gathering experience to design and build even better interactions.
We can start with the shortest path to getting something working, then learn, iterate, improve, repeat.
#readWriteWeb #editableWeb #suggestEdit #acceptEdit
References:
š https://indieweb.social/@kevinmarks/113025295600067213
² https://tantek.com/2011/174/t1/read-fork-write-merge-web-osb11
Âł https://indieweb.org/responses
â´ The phrase âpull requestâ was derived from the git command: âgit request-pullâ according to https://www.reddit.com/r/git/comments/nvahcp/comment/h12hzj7/
âľ âeditsâ in GitHub require taking far more steps, and navigating far more jargon, then say, Wikipedia pages, which come down to âEditâ and âSaveâ. We should aspire to Wikipediaâs simplicity, not GitHubâs ceremonies.
This is post 20 of #100PostsOfIndieWeb. #100Posts
â https://tantek.com/2024/242/t1/indiewebcamp-portland
â https://tantek.com/2024/246/t1/adventures-indieweb-activitypub-bridgy-fed
The consumer Infinite Scroll Web leaves us feeling empty.
Too few of us participate in the Read Write Web, whether with personal sites or Wikipedia.
A week ago when we wrapped up #IndieWebCamp Portland and I was reading Kevin Marks (@kevinmarks@indieweb.social) live-tooting of the demosš, I noticed a few errors, typos or miscaptures, and pointed them out in-person.
Kevin was able to quickly edit his toots and update them for anyone reading, thanks to #Mastodonâs post editing feature and its support of #ActivityPub Updates. But this shouldnât require being in the same room, whether IRL or chat.
We should be able to suggest edits to each otherâs posts, as easily as we can reply and add a comment.
13 years ago I wrote²:
 âThe Read Write Web is no longer sufficient. I want the Read Fork Write Merge Web.â
Now I want the Read Write Suggest-Edit Accept-Edit Update Web.
The ⪠Reply button is fairly ubiquitous in modern post user interfaces (UIs).
Why not also a âď¸ Suggest Edit button, to craft a fix for a typo, grammar, or other minor error, and send the author for their review, and acceptance or rejection? Perhaps viewable only by the suggester and the author, to avoid "performative" suggested edits.
If the authorâs posts provide revision histories, when a suggested edit is accepted, a postâs history could show the contributor of the edit.
Instead of asking Kevin in-person, what if I could have posted special "Suggested Edit" responses in reply to his toots, for which he would receive special notifications, and could choose to one-click accept and update (or further edit) his toots?
To enable such UIs and interactions across servers and implementations, we may need a new type of responseÂł, perhaps with a special property (or more) to convey the edits being suggested.
There is documentation of this and similar use-cases, prior art / UIs, as well as some brainstorming on the #IndieWeb wiki:
* https://indieweb.org/edit
Our interaction after IndieWebCamp has inspired me to take another look at how can we design and prototype solutions to this problem.
For now, if you host your blog and posts as static files on GitHub (or equivalent), you could add a button like this to your posts alongside Like, Reply, Repost buttons:
âď¸ Suggest Edit
and link it to an edit URL for the static file for the post.
I donât use GitHub static files myself for posts, but hereâs an example of such an edit link for one of my projects:
https://tantek.com/github/cassis/edit/main/README.md
This will start the process of creating a âpull requestâ, GitHubâs jargonâ´ for a âsuggested editâ.
After completing GitHubâs ceremony of entering multiple text fields (summary & description), and multiple clicks to create said âpull requestâ, itâll be sent to the author to review. Presuming the author likes the suggested edit, they can perform the other half of GitHubâs jargon-filled ceremonies to âMergeâ or âSquash & Mergeâ, âDelete forkâ, etc. to accept the edit.
Itâs an awkward interactionâľ, however useful for at least prototyping a âď¸ Suggest Edit button on sites that store their posts as files in GitHub. Certainly worthy of experimenting with and gathering experience to design and build even better interactions.
We can start with the shortest path to getting something working, then learn, iterate, improve, repeat.
#readWriteWeb #editableWeb #suggestEdit #acceptEdit
References:
š https://indieweb.social/@kevinmarks/113025295600067213
² https://tantek.com/2011/174/t1/read-fork-write-merge-web-osb11
Âł https://indieweb.org/responses
â´ The phrase âpull requestâ was derived from the git command: âgit request-pullâ according to https://www.reddit.com/r/git/comments/nvahcp/comment/h12hzj7/
âľ âeditsâ in GitHub require taking far more steps, and navigating far more jargon, then say, Wikipedia pages, which come down to âEditâ and âSaveâ. We should aspire to Wikipediaâs simplicity, not GitHubâs ceremonies.
This is post 20 of #100PostsOfIndieWeb. #100Posts
â https://tantek.com/2024/242/t1/indiewebcamp-portland
â https://tantek.com/2024/246/t1/adventures-indieweb-activitypub-bridgy-fed