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!
Recent Posts
Can We Be Honest?
Can we be honest? If we’re going to be successful change midwives, honesty is very important. In this technique card from Leading Technical Change, I talk about some of the ins & outs of this complicated topic. The first point is urgent: Being honest means believing everything you say, not saying everything you believe. Honesty is really important, but people quite often over-share in the name of pursuing honesty. Every healthy person, for instance, has moments of extreme negativity. Our
Detail: Not The Long Game
I was gratified by the response to my first "detail" article. But I did note that many persons praised my article for its commitment to the long game. Framing the commitment, for a geek, to detail, as a long game, seems right, sounds right, cuz after all, we only ever care about quality in the long game. And this is why y’all can’t convince anyone to do this or think this or feel this. When does a bad variable name
Slash the Load
The people who hire me ask me to help their teams make changes. Most of the time, my first step is to see how I can slash those teams’ load. Here’s a technique card from my seminar, "Leading Technical Change" Raw text of a technique card: Wait, what? First thing I do To me, this is dreadfully obvious, but for a lot of folks seeking change, it comes as a completely shocking idea. The weirdest part, though, is that it
Detail: Series Intro
Detail: The thing that strikes me over and over again, in my own work style, in my Friday group’s analytics, in Ron’s long-running Kotlin and short-running Gilded Rose series, is how much attention high-skill geeks pay to some of the smallest details in the code. An example. I was doing Gilded Rose the other day, first time in years, and we start with the ugly method, which we’re asked to add a feature to, following certain constraint rules to make
Joy Project: FGNO Plotter
Joy project: Today’s a comparatively light work day, so I’m gonna lay out what I’m actually trying to do with this project. The source, btw, is at: GitHub – GeePawHill/fgno-plotter Playtime project for the fgno meetup. Contribute to GeePawHill/fgno-plotter development by creating an account on GitHub. Feel free to poke around. There are a bunch of simultaneous missions going on with fgno-plotter, which is why it’s a joy and learning project. "fgno", btw, is an abbreviation of "Friday Geek’s Night
TDD Pro-Tip: Against Automated Macrotests
TDD Pro-Tip: I advocate against automated macro-tests — those whose base is entire running programs –, as their cost is high and their benefit is doubtful. I very rarely write them. There is a bewildering variety of terminology out there around what I’m calling macro-tests, so let’s poke around a little. The central idea of "macro-test" is that we write code that launches an entire subject program and probes its behavior "from the outside". There are often multiple programs in
Some TDD History
I spoze the historic and ongoing inability/unwillingness of the software trade to grasp and adopt test-driven development (TDD) is one of the most frustrating & demoralizing events of my forty-two years as a professional geek. I believe there are several related factors in play, ranging in abstraction level from pressures of global ieconmics to mistakes in local human interaction. Studying this large-scale failure, even while having some small-scale successes, underlies much of my work on change. Because, while the overall
On Over-Coding
Let’s talk for a minute about "over-coding". Over-coding, when you’re a TDD’ist, is writing more code than you (intended to) have test to cover. But I will offer a few thoughts on this to non TDD’ers and TDD’ers alike. Many people, pro-TDD and con- both, seem to think of TDD as the name for a collection or rigorous mechanical rules. TDD is a kind of jack-in-the-box, where you sit there and turn the handle, circle circle circle, and out pops
Robot Worlds E05: A Making UI!
A Making UI We’ve got a very crude skeleton running, let’s get it on the screen, inside a "making app"! If you want to follow along, the repo is at https://github.com/GeePawHill/robot-worlds. Transcript and captions coming soon . . .
Ten I-Statements About Change
Here’s ten I-Statements about change, in the geek trades, and beyond. My hope is that it will give you a richer sense of where I’m coming from in my blogs, talks, videos, and courses. Before we begin, though these statements are about the geek trades, I am actually far more concerned with change in the world. We can change this. We’re the only thing that possibly can. Stay safe, stay strong, stay angry, stay kind. Black Lives Matter. A little
Trade Collapse Begins?
I’ve oft mentioned how the twin cost-revolutions in geekery warped & nearly destroyed our trade. Then wondered if we’ll get to a place where it’s no longer profitable for most companies to write bad software poorly. This morning I wonder if I’m seeing the beginning of it. I don’t have any facts & figures for you. But it feels like I’m seeing more and more companies wonder if the gravy train’s caboose will soon pass the station. It won’t happen
Robot Worlds E04: Yes, Commander!
Robot Worlds: End-to-End-ish Time to flesh out at least one of those ends we got from last time! If you want to follow along, the repo is at https://github.com/GeePawHill/robot-worlds. Transcript and captions coming soon . . .