April 2018

Beating The Human Wave Strategy In The Geek Trades

The seemingly insatiable demand for geekery creates a marketplace with many opportunities, but also many powerful distortions. Among them, the one that seems most puzzling to me is the trade’s notable disregard for the urgency of enculturating the "makers making" upon whom the entire business proposition rests. Successful geekery requires individual humans using individual judgment. That judgment is backed by a number of factors, two of which seem predominant: the range of experience of the judge, and the community in […]

Beating The Human Wave Strategy In The Geek Trades See Full Post

Sticky Change: Changers Feel Better

Yesterday, this popped out. two very common misconceptions: 1) that it is possible to organize your way into agility. 2) that the secret to sticky change is anything other than “changers feel better”. Michael D. Hill (@GeePawHill) April 19, 2018 Today I want to elaborate a little on that second point, that sticky change happens when the changers feel better. All three words of “changes feel better” carry weight, have subtleties, and present possible fail points, so let’s look at

Sticky Change: Changers Feel Better See Full Post

Agility Perks From Below

Plumbers make this joke on day one of having a new hire. "The first law of plumbing: shit flows downhill." That line probably pre-dates western civilization. It’s good to make a noobie kid laugh a little nervously. Agility doesn’t flow downhill. Agility doesn’t flow downhill, it perks up from below. In one sentence, this is because the bottom of the hill is where the people who directly make things make them, and agility is concerned most particularly with them, with

Agility Perks From Below See Full Post

The Technical Meaning Of Microtest

I write things called "microtests" to do my development. Doing this yields me greater success than I’ve had using any other technique in a 40-year career of geekery, so I advocate, wanting to share the technique far & wide. Before we can talk seriously about how or whether this works, we need a strong grasp of what a microtest is and does, from a strictly technical perspective, w/o all the trappings of the larger method and its attendant polemic. A

The Technical Meaning Of Microtest See Full Post

Success Theater, Corruption, and My Own Medicine

The more I work higher up the chain, the more I encounter folks who are openly seeking success theater, w/no interest or concern for actual value. This observation blinded me for many years. I have an odd-shaped-to-some but very strong sense of personal responsibility, myself, and I am no less prone to moralizing judgments than the next old testament prophet. My reactions varied, often enough based quite unfairly on the simple metric of how much I liked the person in

Success Theater, Corruption, and My Own Medicine See Full Post

How Long? (Technique Re-Mix)

How long (redux)? In the technical side of the modern synthesis, we develop code by writing and passing tests then re-working the code to make it as change-enabled as we can. The key "how long" aspect to this: how long does the code stay not working? That is, how long in between the times we could push the code straight to production? The desiderata in the modern synthesis is that we try to measure that number on a scale using

How Long? (Technique Re-Mix) See Full Post

TDD & The Lump Of Coding Fallacy | Video

Hey, it’s GeePaw, and if you’re just starting to look at TDD, refactoring, the modern technical synthesis, we need to start with a couple of minutes about the Lump Of Coding fallacy. You’re a working geek: you spend your days coding for money to add value to your company. And one day some random schmoe like me comes up to you and says, hey friend you really ought to try TDD, because that value that you’re adding, you could have

TDD & The Lump Of Coding Fallacy | Video See Full Post

How Long?

How long? What amount of time passes between you saving the file you just changed and you seeing the results of that change? If that answer is over 10 seconds you might want to wonder if you can make it shorter. If that answer is over 100 seconds, please consider making a radical change in your approach. Thinking is the bottleneck, not typing, we’ve been over this a bunch. But waiting you can bypass — all waiting you can bypass

How Long? See Full Post

TDD: Resist Integration Tests

The expense of an integration test can be extremely high. Consider the contentment app. This app makes drawings 1) that distribute across time, as if they were being drawn live in front of you, 2) that are generated stochastically, 3) with a "pixel-inaccessible" framework. Now, it’s important to understand that none of these problems are insurmountable. Before you tell me how you’d surmount them, let me tell you how I could. 1) screw time. Rig it so it draws as

TDD: Resist Integration Tests See Full Post

My TDD Isn’t Judging Your Responsibility

An old blog of mine, We’re In This For The Money, recently got some attention, delighting me, of course. A full h/t to Jim Speaker @jspeaker for that! He quoted me thus: Too busy to #TDD? Too busy to pair? Too busy to #refactor? Too busy to micro-test? I call bullshit. My buddy Erik Meade calls it Stupid Busy, and I think that nails it pretty well. All you’re really saying is that you’re too busy to go faster. ~@GeePawHill

My TDD Isn’t Judging Your Responsibility See Full Post

Scroll to Top