Change

Change Pro-Tip: Experiments, Cheating, and Responsibility

Coaching, Pro-Tip, Change / / 4 minutes of reading

If your change works, and if it’s small enough to take at one gulp, Then you might consider de-emphasizing the argument for adoption, and focusing your powers on gaining an experiment. (If you change doesn’t work, or it’s too big to take at one gulp, then you might want to go back to the drawing board.) Experiments are significantly easier to get than pre-argued pre-justified pre-determined change. Even very conservative teams can be convinced to try a small thing in […]

Change Pro-Tip: Experiments, Cheating, and Responsibility See Full Post

Using Kotlin for Data Builders

Change, Coaching, Kotlin / / 4 minutes of reading

In Kotlin, functions whose last argument is a lambda, i call them end-lambda’s, make natural expressions of tree-shaped data builders. Say you’re building Performances, where a Performance includes (possibly) the list of songs being performed. making shit up here, it might look like: performance { song { } song { } } First thing you notice: this thing is building some tree-shaped data, and it’s tree-shaped. None of this "song1= … song2= … performance = Performance(song1, song2) shit. If you’re

Using Kotlin for Data Builders See Full Post

Great Geeks Are Great Humans

Change, Coaching / / 1 minute of reading

You can’t be a great geek w/o being a great human. I get how the tradition says you can. I get how much you wish it were so. You can’t be a great geek w/o being a great human. Being a great human is fabulously hard. It’s the hardest thing humans have ever conceived of. So, raise your game. I need to raise my game. We need to raise our game. You beat the first boss handily. You found the

Great Geeks Are Great Humans See Full Post

Refactor Your Tests

Change, Pro-Tip, TDD / / 4 minutes of reading

TDD Pro-Tip: I spend considerable effort making it possible not only to implement a test I want, but to make that test easy to read, to write, to run, and to debug. I’ve talked a lot about five premises of TDD. The money premise, the steering premise, and the chaining premise all get involved when we come to the coding of the tests. We do TDD to ship more value faster, the money premise. What makes it able to do

Refactor Your Tests See Full Post

Try Different, Not Harder

Change, Coaching / / 5 minutes of reading

Change Pro-Tip: I give the same advice to myself as a coach that I do to my teams: "Try Different, Not Harder". A while back we covered Alice’s vision of how to change things. In countering it, I offered the adjustment "from final to iterative". The idea of iterative change is straightforward: It means that we change a thing, and then later we change it again, and still later we may change it again. I want to be sure we

Try Different, Not Harder See Full Post

Create Experiences Not Arguments

Change, Coaching, Pro-Tip / / 4 minutes of reading

Change Pro-Tip: When I can give people an experience, I get dramatically better results than when I give them reasoning. I’mo tell you one of my stories. Twenty years ago, with a considerable amount of "Shut up, I’m the pro from Dover", I got permission to do TDD in a corner of the app I was working on, an app that walked remote groundstations through reconfiguration using a "console". My buddy and boss Gary was unimpressed, but I had permission,

Create Experiences Not Arguments See Full Post

Seek Judgments Not Numbers

Change, Coaching / / 5 minutes of reading

Change Pro-Tip: I try to prioritize getting human judgments — opinions, reactions, feelings — because the quest for numbers holds too many easy traps. When I go to the doctor, she asks me how things are going. Here’s an answer I never ever give: "2.354". Could I? Sure. I could take all the numbers from all the parts of me. I could roll them up. I could make a spreadsheet. I could by averaging produce 3 decimal points of precision.

Seek Judgments Not Numbers See Full Post

Finding the Pivot Mount

Coaching, Change / / 5 minutes of reading

Refactoring Pro-Tip: When I choose a side-by-side approach, I start by finding (or making) the "pivot mount". the place where the final switchover can take place safely. (So, I re-read that last muse, the one driving this, and I blanched. I didn’t say that very well. The price we pay for extempore musing, I spoze. Still, it’s a worthy topic, so let’s see if I can keep my promise to talk about how, even tho I change terminology from the

Finding the Pivot Mount See Full Post

Refactoring: Side-by-Side v. In Situ

Coaching, Pro-Tip, Change / / 5 minutes of reading

Refactoring Pro-Tip: As soon as I move beyond small-scope refactorings, I ask whether my change would be easiest side-by-side or in situ. Before we even start this conversation, remember remember remember: easiest nearest owwie first, and keep repeating it. This conversation happens after we’ve found everything we can do in a scope of one or two classes. We write code iteratively in the modern synthesis. Our designs don’t burst Athena-like from our heads, fully-grown and ready to provide wisdom to

Refactoring: Side-by-Side v. In Situ See Full Post

Scroll to Top