Great Geeks Are Great Humans

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 Go to Post »

Refactor Your Tests

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 Go to Post »

Try Different, Not Harder

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 Go to Post »

Create Experiences Not Arguments

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 Go to Post »

Seek Judgements Not Numbers

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 Judgements Not Numbers Go to Post »

Thicken Yourself

Coaching Pro-Tip: Thicken yourself. Do that by pursuing the backstory of any idea whatsoever that has nothing to do with your trade. That’s it. No thread.

Finding the Pivot Mount

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 Go to Post »

Refactoring: Side-by-Side v. In Situ

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 Go to Post »

We Haven’t Seen It All

I was on the road half to two-thirds time for for about 25 years, nearly always visiting or working with software teams. I’ve worked with teams as small as 2 and as large as 500. I’ve worked in the US, much of Europe, and even a bit of China. The orgs involved might be centered around software, product or service companies, or they might be IT departments, embedded in far larger organizations. The kind of software? Oh, every kind. Embedded …

We Haven’t Seen It All Go to Post »

Change the Problem

I’ll tell ya a story. Once upon a time there was a team that had it pretty good. They were internal-facing in a VBCA, supporting a variety of analysts of different types, with about 3 dozen small projects clustered around a large but mostly stable analysis model. The work was mostly about fronting the analysis model in several different ways to several different other teams, each of whom had different (fairly cool and interesting) needs. So they rolled C#, and …

Change the Problem Go to Post »

Scroll to Top