Thread by @GeePawHill

Let's take another look at the How I Work" muse, only this time let's come at it armed with our change-harvesting ideas: local, human, oriented, taken, and iterative.

geepawhill.org/2019/11/27/how…

Please be super-clear on this: the change-harvesting idea isn't primarily "about" rolling code. Rather, it's that rolling code is one level in which change-harvesting's approach can be concretized.

We can, will, apply change-harvesting to almost any of the trade's many & nefarious activities. But here, when it comes to coding, we get two advantages. 1) Many of my followers are coders, so we share language easily. 2) I know the area very well, so I can 'splain better here..

The description I wrote is shot through with all five of the adjectives. There are places where I use them directly, and others where they're implicit. Almost every sentence is impacted by several of them.

The gigantically obvious one: local. I speak repeatedly of the size of things, and this is one aspect of what we mean when we restrict ourselves to working local.

"Local" is an odd word. I use it to mean a rough conceptual cluster composed of ideas like "small", "near", and "simple". I do this because together they tend to add up to making my work easier.

I use automated refactorings heavily, a key factor in me using an IDE. Doing this shifts local a little: changes that may be quite widespread *textually* are still quite local *conceptually*. The IDE does the grunt work, faster & more reliably than me.

(Irrelevant aside: last night I saw a person on the kotlin slack asking for a good .vimrc, and I was flabbergasted. Why on *earth* someone would want to edit a language as IDE-able as kotlin in a 40-year-old modal text editor is beyond me.)

When I talk about how local the changes I make are, it raises a topic we've only brushed against and not faced directly. It's rking: soonest possible *multivalent* harvest. The value of those small changes is multifarious, not all one kind of value. That's a later conversation.

I rush to "not code yet". What's that about? Well, I situate myself first. I am finding out what is there, and finding out what I wish were there instead. It's the beginning of being oriented.

The thing about working local is that most of the steps I take don't close the problem at hand. I've said I limit problem-size to "a good day and a half". That's *way* too big to be considered local. Instead, I'll be taking small local steps towards that close.

And how do I decide what steps to take? By being oriented in the general direction of the day-and-a-half solution. That period where I situate myself is the time I use to develop the awareness I need to orient my changes in the broadly-correct direction.

I think of orientation as turning towards a horizon. The answer is "over there somewhere", and I work change-by-change, each oriented towards that horizon. My aim gets more precise as I get close, but only quite late in the game. The rest of the time, I'm orienting, not aiming.

"Taken" is the most wobbly of the adjectives when it comes to coding, but I think I still have a case. Remember that we take the change from the humans rather than give it to them? That idea is about pulling rather than pushing.

A great deal of geek pedagogy is about greenfield work -- making a program starting from a blank page. But nearly all professional software development is brownfield: after the first week of a project, blank pages are a fond memory. There's already code there, lots of it.

And here's the thing: the code that's already there solving the old problem tells me what it wants to be to solve the new problem.

I'm flashing on Chevy Chase in _Caddyshack_: murmuring "be the ball, be the ball".

Yes, I know, that sounds mystical. But it's not. It's the paucity of our language and our training that makes it sound silly.

The old school sees an endpoint first and what is there second, and it pushes what is there to become the endpoint. The change-harvester sees what is there first and the endpoint second, and it pulles what is there to approach the endpoint.

The iterative aspect is as obvious as the local: I absolutely see myself working change by change, and I haven't the least concern with the fact that any given change may be changing again something I've already changed once.

I drive using tests. Each test -- when I'm working optimally -- pulls another change into place. I do lots and lots of refactoring, too. Each refactoring is an oriented change pulled into place, too.

Notice there are multiple scales going on. Most 15-minute pull-change-commit cycles aren't the last one in the day-and-a-half problem. Most day-and-a-half solutions aren't the last one in a new feature. Most features aren't the last one in the user's cool new app.

It's change-harvest change-harvest change-harvest, all the way through. There's no end in sight, and no end desired: remember what happens when a dynamic unity stops changing. :)

And finally, the human. The whole described process is about the human doing the work. The overwhelming majority of what I've been learning for the last 20 years in this community isn't how to program computers in the abstract, it's how to program computers when you're a body.

Why do I refactor? Why change the text of code without changing its function? Because my body is much better at detecting key features in its world when that world supports the detection.

Why make every step so damned small? Because when you're a human, your mental bandwidth is, not to put too fine a point on it, itty-bitty. When the changes are small, I perform much better, and the relationship between size and performance is non-linear.

Why write all those tests? Partly because they force small, we already mentioned that. But that's not all of it. They're a kind of artificial memory. The computer remembers so the human doesn't have to. The computer notices a regression so the human doesn't have to.

A great deal of what I do when I'm coding, all of this, is about providing me with little jolts of juice. Tension & release *feels* good. When I feel good, I perform better. So I structure my work to get T&R distributed throughout the day. An eminently human approach.

So. I hope you're getting a feel for how the change-harvester's theory relates to her practice. A reminder: I didn't become a theorist and then turn it into practice. I became a practitioner and gradually wove the practices that work best for me into a theory.

There's more to it. First, I've already said, change-harvesting applies to a lot of the activities of a software development organization, not just rolling code. Second, I've elided nearly all talk of collaboration, which is fundamental to professional software development.

I notice I didn't discuss my commitment to CI or CD at all, yet both are a deep part of my daily development practice, and both are implied by the change-harvesting approach.

No matter. I hope you're starting to get this picture filled out a little. Please feel free to poke & prod: your responses absolutely fuel my efforts to create content, and all are valued.

It's all winter wonderland here today.

I strongly prefer summer, but it *is* beautiful, and warm inside, and I am going to curl up with the dogs and read.

Have a beautiful warm snuggly reading day!

Obligatory Non-Soundcloud Ad:

The Change-Harvesting Camerata is a community of folks with a shared problem: harvesting the value of change.

geepawhill.org/camerata

Join today!

Special launch bonus: First fifty yearly members get a free one-on-one coaching session with me!