Lotta inspiration for junior geeks stuff floating around. I'm having a low productivity day today because, well, you know all of that, so I'll take a minute nd pitch in. Do you know what I did for about twelve elapsed hours of coding time? I solved a problem. Cuz, you know, I got mad skillz, and have been geeking for forty years, and am even, in a couple of microdomains, a bona fide citable expert. I'll tell you the problem I solved, next tweet, but before we take the dive, I need you to just, relax, okay? Explaining this problem I solved might get a little heavy. I mean, for reals, yo, I'm a master geek and this took me twelve hours to solve, it's prolly gonna be daunting.

---

You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter, or drop a voice message via the voice messages link here on Anchor. If you are interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata.

The strategy pattern lets you make "pluggable algorithms", so clients have different behavior without having different code themselves. We often use it to capture the "consequence in code" of some condition, which we can then let other code use without re-testing the condition. Here's a little java snippet:

---

You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter, or drop a voice message via the voice messages link here on Anchor. If you are interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata.

Another refactoring topic today: dealing with nulls. There are a bunch of techniques, but they amount to a) don't, and b) do but only one time ever. The basic idea: a null always occurs in a particular context, and in that context, it has a meaning. When we pass it up or down our call-stack, we are *changing* contexts, and hence changing meanings. We're using the same symbol to mean different things at different times. Using the same generic symbol to mean different things in different contexts is anti-signal. It represents a loss of meaning. 

---

You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter, or drop a voice message via the voice messages link here on Anchor. If you are interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata.

When I can't test it where it is, I look to move it somewhere else, where I can test it. Today's notion isn't so much a single refactoring as it is a strategy that can be achieved in different ways (and different multiple steps). A modern and frequently occurring case: using a cool framework to expose service endpoints, we write a function and then we annotate it and poof, it's an endpoint. This is how Java+Swing works, or Python+Flask. When we give that function a body, it will be a body of "our branching logic" (OBL). We've already discussed that OBL is the main target of our tests, so we definitely want to test that function. Sadly, testing that usually involves one or more of three owwies. We'll have to either/or/and 1) fire up the app, 2) fire up the framework's test rig, 3) instantiate the class containing the method. Most of the time, none of these three choices is a fountain of geek joy. The problem, in all three choices, is in the weight of that framework. And it's not a problem that's avoidable: we chose that framework precisely cuz it does so much for us. Of course it's heavy.

---

You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter, or drop a voice message via the voice messages link here on Anchor. If you are interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata.

Another refactoring today: Use the observer pattern to invert an infelicitous dependency. In and of itself, this is a modest refactoring, but its smell often co-presents with others, and unravelling it all can be tricky. (Note: We aren't remotely done talking about first and second-order refactorings, there are plenty more to go. But I'm not writing a catalog, I'm working a project, so when a hefty one like this comes along, that's when I'm talking about it. You're gettin' em as I'm doin' em.) "Infelicitous dependency", eh? What could make a dependency an unhappy one? There are a lot of possibilities, but for me they usually amount to one of two cases: 1) an important abstraction is dependent on an unimportant detail, 2) it keeps me from writing a test I want to write. A concrete example might help, and I have just the infelicitous dependency we need for this, because it fits both bills, being both a "wrong direction" dependency and an inherently anti-testing class. Aren't we just terribly terribly lucky?

---

You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter, or drop a voice message via the voice messages link here on Anchor. If you are interested in becoming more involved in the Change-Harvesting community, click here to learn about GeePaw's Camerata.

Demeter violations are places where a client accesses not just an upstream service, but that service's upstream services, or even that service's service's upstream services. It's a common problem in evolving code, and left untended, a classic source of unchangeable code. Demeter calls look this: a.getB().getC().doSomething(). a is getting a B, but is using that B expressly to get a C, then finally calling some method on the C to do something. (The getX()'s could as easily be exposed fields rather than methods: depends on idiom & language.) I want to stave off some potential confusion. 1) You might be used to thinking that any chain of '.'s like these is just "fluent". 2) You might, alternatively, be thinking that any chain of '.'s like these is inherently evil. Neither of these assumptions is necessarily valid.

---

You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter, or drop a voice message via the voice messages link here on Anchor. If you are interested in becoming more involved in the Change-Harvesting community, click here to learn about GeePaw's Camerata.

A key value for those who take up the change-harvesting approach: "keep it running". This is actually a direct result of human, local, oriented, taken, iterative, and argues against many finish-line efficiency approaches. Think of a change as a point A, with an arrow coming out of it and ending at a point B. At the two points, we have a running system, but along the arrow, we don't: our change is in flight. The change-harvester seeks to keep those arrows as short as possible. I say seeks, but that's a little weak, actually: the change-harvester obsesses over the length of that arrow, and will do a whole lot of things to keep it short, including purposefully stepping away from an idealized straight line towards a target on the horizon.

---

You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter, or drop a voice message via the voice messages link here on Anchor. If you are interested in becoming more involved in the Change-Harvesting community, click here to learn about GeePaw's Camerata.

In our continuing conversation about refactoring, I want to go a little abstract today, and talk about chunking and naming. Naturally, a topic this important has already been addressed by a stupid joke in the movie Airplane!, so we'll start there. A passenger is approached by a steward, asking if he might be able to help with a problem in the cockpit. He says, "The cockpit! What is it?". She says, "It's the little room at the front of the plane where the pilots sit, but that's not important right now." The number of things one can hold in one's head at one time -- mental bandwidth -- is quite small. If the things are entirely unrelated to one another, it's on the order of 4-6 things. By contrast, the number of things one can need to hold in one's head at one time -- context bandwidth -- is ridiculously large. If the context is "reality", it's effectively infinite. But far smaller contexts than reality, everyday ones, still dwarf mental bandwidth. 

---

You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter, or drop a voice message via the voice messages link here on Anchor. If you are interested in becoming more involved in the Change-Harvesting community, click here to learn about GeePaw's Camerata.

Change-harvesting takes the stance that our most reliable strategy for change is a highly iterative process of act-look-think, in roughly equal proportions, repeated in small local cycles. We oppose that approach to look-think-act, emphasis on think, in large global cycles.  This opposition is, of course, not a philosophical light-switch, an all-or-none thing. If you abstract away the locality factor, a series of five a-t-l's looks like an a followed by a series of four t-l-a's, followed by a final t-l. :)  So the difference between these issues has to do with the locality and its implications and the relative proportions of the thinking, looking, and acting. The change-harvester wants maximum locality, and wants equal effort applied to the thinking, the looking, and the acting.  When we contrast the two approaches, the change-harvester and the more standard trade approach, we use one as the base and one as the difference, and this leads us to the language saying "bias for action". 

Episode 49 is live! If you are interested in becoming a part of the conversation, Click here to join the Change-Harvesting Camerata Today!

---

If you have any feedback you can always tweet @GeePawHill on Twitter, or drop a voice message via the voice messages link here on Anchor. You can also read the full transcription of this podcast over on GeePawHill.org.

First things first, "large scale refactoring" is really a colloquial expression, a shorthand we sometimes use, but in my experience there is no such thing, for two reasons. The first reason is definitional. Remember, refactoring doesn't mean "changing my design", it means "changing my design without changing its function". We almost never do this at large scale.  The marvel and the horror of this trade is the extraordinary demand pressure it operates under. Anyone who's done time in the silicon mines knows this. It is the origin of nearly every bad process in the trade.

Episode 48 is live! If you are interested in becoming a part of the conversation, Click here to join the Change-Harvesting Camerata Today!

---

If you have any feedback you can always tweet @GeePawHill on Twitter, or drop a voice message via the voice messages link here on Anchor. You can also read the full transcription of this podcast over on GeePawHill.org.