Helping Geeks Produce for Over 40 Years.
My mission is to help people learn how to embrace change and harvest its value. That’s why I started the Camerata: a community of like-minded teams and individuals pushing forward the industry of software development. Click the button and discover the benefits of becoming a member today!
Latest News
Featured Video: The Lump of Coding Fallacy
Newcomers often think Test Driven Development will slow them down, but here, GeePaw explains how the "Lump of Coding Fallacy" leads them to that mistaken understanding.
GeePaw's Camerata
GeePaw's Camerata is live! A community dedicated to makers making. Access to the Slack, one-on-one time with GeePaw, store discounts, early access to educational videos, and more!
Town Halls
Starting at the end of March 2020, GeePaw will be hosting remote Town Halls via Zoom. These will be small gatherings capped at 25 participants and last about 90 minutes. Click the image to see the upcoming Town Halls.
Recommended Reading
Thanks to respondent feedback, I have been curating a list of all the reading that I mention in my blogs and elsewhere. I will update it as frequently as I can manage.
Recent Posts
Local Change – What and Why
The change-harvester uses these five words to describe the properties of successful change: human, local, oriented, taken, and iterative. Let’s talk about “local”. See the previous post “Human Change” here These muses turn in to blogs + podcasts, and you can subscribe to them at geepawhill.org .) When we say we want our changes to be local, we’re talking about neighborhood, some rough concept of nearness, in multiple dimensions. We want a proposed change to be “within reach”. Remembering humanness, we want it to be something we can get our heads around. And we want it to be something we
Human Change – What and Why
Today, let’s talk about the change-harvesters use of the concept-cluster we describe with the adjective “human”. We advocate that both the what and the how are best centered around the humans in our systems. The change-harvester looks at changes — in code, in individuals, in teams, in process & flows, in organizations — and sees that ,successfully applied change is human, local, oriented, taken, and iterative, often enough to adopt it as a general approach. So let’s do “human”. The idea here is that not only the changes we want to apply, but also the manner in which we adopt
Multivalence for Change Harvesters
I want to talk about value today, and especially want to consider an idea I call multivalence, which seems quite central to putting the change-harvesting ideas to work. I recently chanced across a timeline convo that by asked what we should call things it would be good to achieve that weren’t things that were directly visible to the customer. “What do we call valuable things that aren’t ‘value’?’ The answer I gave: “value”. Meanwhile, in another part of the forest, a few of us were schmoozing about the fairly straightforward traditional resistance to “pairing”, and where the backing ideas for
Lining It Up That Way (Rant)
The reason it’s so important for you to see 100 lines of code on your screen is that you have arranged the code so that 100 lines seems like a sane quantity. What you’re doing is working against your own capability. The reason it’s so important that no one interrupts you for six-hour blocks is that you have arranged the code so that six-hour blocks seem like a sane amount of concentration. What you’re doing is working against your own capability. The reason it’s so important that you keep your code from being at head for days or weeks at
TDD on the Front End
A recurring respondents’ theme is “TDD is irrelevant in front-end code”. It’s easy to offer/receive this comment combatively, but I think a little more rich discussion of the factors involved might bring us to new and different positions about UI and TDD. Most folks who offer that are living in some sort of JS world: their code is client-side scripts attached to html pages to render various contents received from another application. Their browsers are in effect frameworks, inside of which all their code runs. (Aside: One of the most prevalent trade problems caused by the explosive demand for software