[600frogs]

Thanks for the concrete example, that's super interesting. Do you find this level of granularity helps, both short-term and long-term? I tend to find in a busy day that I've completely neglected to update my DONE list, and my suspicion is that if I stopped every 20 mins to update it I'd break my flow.

Long-term, I can see once in a blue moon going back to the exact thought process during an issue would be invaluable if something similar crops up, but 99 times out of 100 is this not over-documenting? I'm not trying to criticise here, I want to understand what value you get from it.

[100011_100001]

I am a firm believer that different personality types work differently. I can only speak about myself here, for me having a list of 5 priorities helps me immensely. It works so well that I do it on non work days as well. I find it easier to plan. Also I tend to gauge time wrong, I always estimate time on best case scenarios, so having 5 things that take an hour or less means I have a full day in reality.

As of the day.md stuff. If I am super busy doing non code work, I will neglect to update it. However that's fine, because I don't need a lot of structure for meetings etc.

If I am writing code and neglect my day.md because I am in the zone, I don't mind at all. I rather stay in the zone than make up tasks to complete.

Where day.md signs is when I am in overwhelm or I am unmotivated...which usually comes from overwhelm and I don't know it, or the thing I am working on is just plain boring.

There are two types of overwhelm. Strategic overwhelm, aka I don't know what I need to do, what exactly I am solving? The other time is implementation overwhelm, aka there are like 50 things I need to account for, I know what I need to solve but there are so many things I need to consider for a good solution.

Both of these lead to me not wanting to write code. So instead I will just create an outline of a plan. By doing that I can figure out what I need to solve, or ping someone to figure out what the story is meant to solve. However it also allows my brain to go to brainstorm mode and just think about what the implications of the change are. So out of the 50 things I might have to care about, I might realize it's really 10 things. Now at least I don't to do that mental work later. While writing code I might realize I need to consider 2 more side effects, or perhaps realize that it wasn't 10 dependencies but 7, for whatever reason. The cool thing is though, if I write it down I have something to work with. Mental pointers of what I need to consider.

If I am unmotivated to write code, day.md helps in a similar fashion. It allows me to do work, without writing code. Then I will try to trick myself, hey, this step is like 5 minutes, do that so you can at least make some progress today....and boom 2 hours later I have done the thing. I know I am tricking myself, but I also know that I get paid to write code, so tricks are OK. If however I do the thing for 5 minutes and don't feel like it, I will task switch. Sometimes just going for a walk, grabbing a cup of coffee is all you need.

As a continuation of this actual thing I am working on, here is my actual update for the story

* Look at current Jenkinsfile types > Currently our workflows are abstract because we don't want to change Jenkinsfiles per application > If we have remote Jenkinsfiles, do we still need the same level of abstraction > They will act more like a catalog, where people select the Jenkinsfile they want > This means from the catalog side you need to be able to see what each Jenkinsfile offers, so visibility is good > It also means code complexity will confuse the hell out of people * DONE Identify commonalities * DONE If workflows had to change, what would that look like in a code change * idea #1: add | add a new line, modify | no change needed * idea #2: add | no change, modify | no change needed * idea #3: add | no change, modify | no change needed * DONE Write a less abstract version, how does that change future code change approach and readability * Test * DONE Write a more abstract version, how does that change future code change approach and readability * Test * How easy is it to read current code vs your new abstraction

Note that I skipped around, and I didn't test. It's because ultimately I realized I don't have to test the code just yet, because I care about readability, addition and modification of code. I know I can get the new code to work because it's abstracting existing code that I am intimately familiar with.

Now, I am going to be busy with meetings for 2 hours, however when I get back I can quickly figure out what my thoughts were, that I have 3 main ideas, which are written in mostly real code and I have to figure out which one of my three ideas are worth it. I thought about add / modify, but my concern is readability. Specifically developers understanding what each steps are since abstraction can obfuscate things...but good method / class names make it easier to understand ...