Often, when a project reaches a certainly early/mid scale where I'm tackling some of the bigger problems, I'll push myself to work on it a little longer and finish it. If I might normally finish at 10pm, I'll push myself and go till 11:00 or midnight and finish the system.
Then, because it's so late, I tend to just close everything out. And because I've just completed a milestone, I'm faced with not only getting back into flow, but beginning the process of designing/implementing a whole new big thing.
It's at this point I really start to stumble, and I've lost a lot of projects to, "Whew, just finished that awesome system, I'm sure I'll pick this back up soon!" and I am at a total loss of how to power past these moments.
If anyone has any ideas, I'm all ears.
Or failing that, 15 minutes of cranking out garbage code that I know I'll revert helps get back into flow state too, but it's demoralizing deleting work.
You there's no concept of "scale" to something like this. Save a snack, a small task, for your brain to munch on in the morning, and you'll get in the routine much better than on an empty stomach.
What did however was an analysis of 1) what I did yesterday and 2) what I want to today. I started with just typing my head off for about 30 mins every morning. At first it was thoughts all over the place. As I kept at it and pushed through, over a few weeks on I could see patterns emerge. I could read what going on yesterday, a week ago or a couple of sprints ago or a release ago and see how things have evolved. This helped separating the important stuff from the fluff. This was what I needed to focus on. I now log the important stuff. Takes about 10 minutes a day and gets me in the flow of things. Totally worth the effort in time and mental cycles spent.
The author presents a lot of seemingly complex tools for this. Mine are, I believe, simpler -- a TODO list in .org mode (goal and next), and git log (for what just happened, always with --name-status to show what files were affected how, and maybe with -p to show the diff).
But you could use anything.
There is also https://github.com/alphapapa/outshine
Which gives you "full" orgmode in comment sections of your normal source code (haven't actually tried it myself).
Overall I think you are on the right track with your goals but, yes, orgmode does a great job of solving them already with a bunch of additional features too.
Also this process is not automatic - you have to navigate to the buffer and close the task when it's done. Also from the that buffer it's impossible to sync outside (GitLab/GitHub) or share your tasks with a team, what is possible with Kanboard if it's running on DigitalOcean/Heroku or simply synchronizes with GitHub.
Literate Programming in the Knuth sense with org-mode file using tangle blocks holding the source code which can be used to generate and build the project, and a combination of regular emacs lisp code and some org-mode evaluated emacs lisp to do whatever automation is needed.
Now the TODOs can be in the org file, which contains the source, and may also have a reference (automated) to the TODO, which when closed with the regular org-mode command (and is generally only two key chords) will remove the comment as well as update your agenda, calendar, kanban, etc.
I have a dev log in org mode. Any thoughts about what I'm working on go there. Including TODOs. It's always open, so there is no open/save/close process.
Of course, I have to update it. But it's just one more file that gets updated. It's not onerous.
Plus, I'm not destroying documentation about my development process. I have used this method since I started developing professionally 15 years ago. I can go back over a decade and look into why I did certain things for a piece of code and how I decided to break the work apart.
The organizing principle of the todo document is problems. The organizing principle of the code is something else -- control, data. Perhaps ideally they would align, but in my experience they don't.
>I had learned already never to empty the well of my writing, but always to stop when there was still something there in the deep part of the well, and let it refill at night from the springs that fed it.
The mentioned kanban software, `kanboard`, is super easy to setup and use -- I did a survey of about 10 self-hosted kanban software tools and this was definitely a front-runner in terms of overall simplicity and ease of setup and use. I did not review the plugin architecture at the time, but glad to hear that it is fairly straightforward.
Writing notes helps commit things to memory better for me too. Also, using paper to write notes is less of a distraction than using an electronic medium to write notes in this day and age.
Getting back into the swing of things is effortless. You can switch between projects within literally 2 seconds. It's so easy to resume exactly where you left off from the previous session. There's no need to tinker with window layouts or re-open code editors.
Last month I made a video that goes over this workflow at (8:02 is the specifics on switching between projects): https://nickjanetakis.com/blog/using-tmux-sessions-windows-p...
With GUI editors you'd have to use session / project files and then manually open / close your 1 instance of that editor when you switch between projects. It's kind of a clumsy experience (but doable).
There’s two major issues though - compared to entering my PC password, opening a tmux session vs clicking a button(or using a keyboard shortcut) is meaningless. Besides, for the last two decades, machines have had a sleep/hibernate functionality which means you can resume immediately, whether that’s a gui editor or a tmux session, with 0 interaction - I enter my password and my IDE is open, exactly where I left it (even in a debugging session if I needed it).
> With GUI editors you'd have to use session / project files and then manually open / close your 1 instance of that editor when you switch between projects. It's kind of a clumsy experience
I can’t think of a single gui editor that restricts you to one instance of it running, and I can’t think of a single gui editor which you would need to shut down to open a different session/workstation in. Visual studio for example has a list of recently opened projects in the file menu. In 3 clicks you can swap from one to another, or you can just open a second instance of it.
Vs code has Ctrl r to “open recent” and you can choose from the command pallete (no mouse needed)
Hibernate isn't dependable, especially not on a Windows box where it will do a full reboot to update itself which is out of your control. Also hibernate is quite buggy (even after 2 decades) and doesn't assist in switching between projects.
> I can’t think of a single gui editor that restricts you to one instance of it running...
You can run more than 1 copy of a GUI editor for sure, but are you really going to open 8 independent copies of VSCode? How will you pick which one to use? Would you put each one in its own independently labeled virtual desktop or put them all into 1 virtual desktop and now juggle 8 VSCode icons in your taskbar? That seems like a massive burden from a usability POV and from a system resource POV one copy of VSCode with a "full time developer" amount of plugins uses around 600mb of memory just to open it once. So if you had 8 of those open you would use around ~5 gigs of memory, and chances are your idle CPU is going to be jacked up too even when not typing into any of them (it does for me on my Windows box).
With terminal Vim you don't need to worry about system resources ever. It uses less than 10mb of memory even with 40+ plugins and your CPU load stays at zero even if you have 17 copies of Vim running (which is what I have currently running).
Open recent is also not dependable because chances are you're opening and editing things that aren't projects all the time (such as config files, etc.). This isn't all theory either. I used VSCode for over a year and these are all real problems I ran into. I only recently switched to Vim (relatively speaking) and all of those project management problems I had went away.
(For context, I am a game designer at AAA studio and I write a lot of code.)
Then again, if more amateur fiction writers did one thing well, I think that fiction in general would be improved.
I world build, draw out maps, plan characters then never write. Sometimes I wonder if I just enjoy world building. But I think I'm just intimidated.
“Completed ABC; TODO XYZ”
“WIP ABC; TODO XYZ”
When I get back, all I have to do is check the previous commit.