3 ms·

Agreed on low-tech, low-tech can be great! My personal calendar is just a huge whiteboard I scribble on, and redraw at the end of every month. Physically crossi

Agreed on low-tech, low-tech can be great! My personal calendar is just a huge whiteboard I scribble on, and redraw at the end of every month. Physically crossing out tasks/appointments is rewarding in the way that a phone-tap or CTRL-X CTRL-V can never be. That being said - do you not find the duplication of tasks from the index card to day.md to be annoying/unnecessary? I know if I was rewriting the tasks from the index card to the .md file every day I'd get irritated and eventually just resort to the .md file, but maybe I need to learn to be a little more patient :)

100011_100001 5y ago
Perhaps I was not clear. My day.md file does not contain the 5 tasks I write in my index card. For a real example, my index card says "Abstraction Tweaks". My day.md looks like this: # <story-id> - SPIKE: Investigate the best way to abstract common Jenkinsfiles * Look at current Jenkinsfile types * Identify commonalities * If workflows had to change, what would that look like in a code change * Write a less abstract version, how does that change future code change approach and readability * Test * 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 So my index card is more like a pointer to the day.md story I am working on. Right now, perhaps it's obvious, I just started working this story. My breakdown of the work to be done is rather generic. As I start working on the first part "Look at current Jenkinsfile types", I will see the types, and then update that section with the different types as a note. This help me downstream when I am ready to make changes, I can make sure my abstractions in this case would work for all cases. Here is an example of a done task, including my thoughts, verbatim from my day.md. It's the worst case scenario when I get stuck. By convention, "" means action, ">" means thought. Markdown renders it nicely. * DONE Test `withEnv` removal - it fails * If it breaks move it into the rhel7-gradle Dockerfile * Test change - it fails * Test w/o gradle opts - success * Test w/o gradle user home - failure * Test w/o gradle home - success > how is this possible? Empty gradle user home or defined works, removing it fails... * Test no GRADLE_USER_HOME in Dockerfile ENV withEnv GRADLE_USER_HOME= - success * Test no GRADLE_USER_HOME in Dockerfile ENV no withEnv GRADLE_USER_HOME= - failure * Test GRADLE_USER_HOME in Dockerfile ENV no withEnv GRADLE_USER_HOME= - failure...container env points to /app/jenkins/.gradle...w/ Dockerfile ENV defined... * Test GRADLE_USER_HOME in Dockerfile ENV withEnv GRADLE_USER_HOME= - success...container env points to /home/gradle/.gradle which matches Dockerfile > Looks like the witEnv is shielding the ENV Dockefile definition from an override, where is it coming from? > Still need to test withEnv only surrounding gradleWorkflow, I don't think the docker workflow needs it * Jenkins Globals overwrite ENV variables. Removed them from test and everything works
- 600frogs 5y ago
  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 5y ago
    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 ...

100011_100001 5y ago

Perhaps I was not clear. My day.md file does not contain the 5 tasks I write in my index card. For a real example, my index card says "Abstraction Tweaks". My day.md looks like this: # <story-id> - SPIKE: Investigate the best way to abstract common Jenkinsfiles * Look at current Jenkinsfile types * Identify commonalities * If workflows had to change, what would that look like in a code change * Write a less abstract version, how does that change future code change approach and readability * Test * 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 So my index card is more like a pointer to the day.md story I am working on. Right now, perhaps it's obvious, I just started working this story. My breakdown of the work to be done is rather generic. As I start working on the first part "Look at current Jenkinsfile types", I will see the types, and then update that section with the different types as a note. This help me downstream when I am ready to make changes, I can make sure my abstractions in this case would work for all cases. Here is an example of a done task, including my thoughts, verbatim from my day.md. It's the worst case scenario when I get stuck. By convention, "" means action, ">" means thought. Markdown renders it nicely. * DONE Test `withEnv` removal - it fails * If it breaks move it into the rhel7-gradle Dockerfile * Test change - it fails * Test w/o gradle opts - success * Test w/o gradle user home - failure * Test w/o gradle home - success > how is this possible? Empty gradle user home or defined works, removing it fails... * Test no GRADLE_USER_HOME in Dockerfile ENV withEnv GRADLE_USER_HOME= - success * Test no GRADLE_USER_HOME in Dockerfile ENV no withEnv GRADLE_USER_HOME= - failure * Test GRADLE_USER_HOME in Dockerfile ENV no withEnv GRADLE_USER_HOME= - failure...container env points to /app/jenkins/.gradle...w/ Dockerfile ENV defined... * Test GRADLE_USER_HOME in Dockerfile ENV withEnv GRADLE_USER_HOME= - success...container env points to /home/gradle/.gradle which matches Dockerfile > Looks like the witEnv is shielding the ENV Dockefile definition from an override, where is it coming from? > Still need to test withEnv only surrounding gradleWorkflow, I don't think the docker workflow needs it * Jenkins Globals overwrite ENV variables. Removed them from test and everything works

600frogs 5y ago
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 5y ago
  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 ...