> For some, by contrast, the big goal became a source of panic.
This reminded me of something Dr. Jennifer Heisz said on her current book tour for "Move the Body, Heal the Mind" where she said that we might better cope with overwhelming tasks by lowering the stakes of what we're doing. Hearing her say that reminded me of Test-Driven Development. Taking small steps, tabling related or inspired work for later, and making sure we're staying focused on one thing at a time has brought great relief through lower the stakes of any individual commit or PR.
(I read TDD before doing the technical phone screen at Pivotal Labs and it truly helped me stay calm and focused when I was certainly anxious. Thanks are in order!)
I am energized by the combination of a big, vague goal (to give myself a sense of significance & purpose) & teensy, tiny steps (so I don't get overwhelmed).
A framework I was reminded of when I read this article and which I like very much to describe the approach described here is the “Vector Theory of Change” from the Cynefin corpus of theories and methods.
I find it nicely captures the idea of tiny, teensy steps and the idea of striving for “more of this, less of that” towards a big but vague goal that you observed with the more experienced folks.
- Work out a contract/interface for the change. Sounds obvious but I’ve seen it go wrong fairly often, results aren’t tight and clean.
All the flavours of this you have explained, the tricky question (at least for me) is when you use which which approach. Specially in the beginning of the discussion you describe when group perspective is all over the place.
I have had this gut feeling that it'd be much easier to refactor large codebases just by rewriting the syntax tree 😬 sadly the codebase I work with doesn't have the needed tools for that. Thank you for telling about smaltalk rewriter. I'll look into it and see if I can come up with something myself.
> For some, by contrast, the big goal became a source of panic.
This reminded me of something Dr. Jennifer Heisz said on her current book tour for "Move the Body, Heal the Mind" where she said that we might better cope with overwhelming tasks by lowering the stakes of what we're doing. Hearing her say that reminded me of Test-Driven Development. Taking small steps, tabling related or inspired work for later, and making sure we're staying focused on one thing at a time has brought great relief through lower the stakes of any individual commit or PR.
(I read TDD before doing the technical phone screen at Pivotal Labs and it truly helped me stay calm and focused when I was certainly anxious. Thanks are in order!)
I am energized by the combination of a big, vague goal (to give myself a sense of significance & purpose) & teensy, tiny steps (so I don't get overwhelmed).
A framework I was reminded of when I read this article and which I like very much to describe the approach described here is the “Vector Theory of Change” from the Cynefin corpus of theories and methods.
I find it nicely captures the idea of tiny, teensy steps and the idea of striving for “more of this, less of that” towards a big but vague goal that you observed with the more experienced folks.
https://cynefin.io/wiki/Vector_theory_of_change
Trick:
- Work out a contract/interface for the change. Sounds obvious but I’ve seen it go wrong fairly often, results aren’t tight and clean.
All the flavours of this you have explained, the tricky question (at least for me) is when you use which which approach. Specially in the beginning of the discussion you describe when group perspective is all over the place.
I have had this gut feeling that it'd be much easier to refactor large codebases just by rewriting the syntax tree 😬 sadly the codebase I work with doesn't have the needed tools for that. Thank you for telling about smaltalk rewriter. I'll look into it and see if I can come up with something myself.
AST-based tools are the wave of the future & have been for 25 years.