A little more on coaching theory today… Folks ask me a lot of questions whose fundamental focus could be expressed as "how do you get them to do what you want them to do?" so. Here goes. I hereby reveal my entire competitive advantage as a professional coach, by telling you my special secret for how I get them to do what I want them to do. I don’t. I don’t get them to do what I want them to […]
How I Get Them To Do What I Want See Full Post
To have a serious conversation about how to test, we have to start by considering what to test. As a microtesting TDD’er, what I want to test is our logic. Enter the Money Premise The money premise of TDD reminds us we’re in this for the money, that is, the primary purpose of TDD is to enable us to ship more value faster. Deciding what is "value" is not a TDD task. The larger agility certainly asks us to make
How To Test Depends On What To Test: Money, Chaining, And Steering See Full Post
So, day off before travel before onsite, playing ONI, having fun, but I want to muse about a highly geeky matter anyway… Do you ever override in a sub-class a method that’s already implemented in a super-class? I want to recommend to you a policy of avoiding that like the plague, whenever you can. I will go further: I avoid, maybe not as much as the plague, but surely as much as the measles, even deriving any sub-class off of
Avoid Implementation Inheritance: GeePaw Goes All Geek-y See Full Post
Hey, there, it’s GeePaw! And you are watching the first ever GeePaw video aimed specifically at coaches. I hope you like it. Do you know what the first absolute prerequisite for being a successful software development coach is? You have to like people. You have to like people. You have to like their style. You have to like their resistance. You have to like when they do the thing you want them to do. You have to like when they
Coaching? Like People | Video See Full Post
Coaches, we all know that confidence is key, yes? It’s not the only key, but it’s key, especially in the beginning. People look to you for ideas, then. And they’re lookinig to you for a number of reasons, but one of those reasons is because they think you’ll have some. And early on, there’s very little reason for them to think that. They don’t know you, they are guessing. And that perceived confidence in them is matched by an internal
Coaches: Whence Confidence? See Full Post
When I was geek-young, not quite forty years ago, I worked in a tiny two-person shop, and we were entirely without "method". We just wrote code. At that time, there were plenty of analysts of geekery, and they were certainly writing about how to geek, but 1) their ideas were seen as more of a bazaar than a cathedral, and 2) most of the trade did exactly what we did at good ol’ MIS. (Chris Martz, or Jan, if you’re
No One Way: GeePaw On Method See Full Post
Of all the routine requests I get from clients, the one I find most difficult to deal with is this: "Help us choose a metric so we can tell if things are going well." the problem is that "numbers as health indicators" is so deeply embedded in our worldviews, so deeply correct on paper, and so deeply counter-productive in every case i’ve seen in practice. Think about your own health for a minute. Is it a 9 or a 3?
The First Metric: How Are You Feeling? See Full Post
Possible causal point for a failure to value TDD: geeks thinking the main source of bugs in professional software is not handling the main case successfully. In any feature in any app, there are one or more primary cases. A given story is likely to be concerned with one of these at a time. When you’re geek-young, the great challenge is just to close out the primary case. Hell, you barely learned the syntax, you’re just learning the library-set. Just
TDD & The Geek-Young: Is Tdd Right For Noobs? See Full Post
I’m bettin’ u already got some code. If yer a geek in a substantial code base in an org w/more than a half-dozen other geeks, i’m bettin’ u already got a lot of code. In your team’s head, if not somewhere on an out-of-date piece of paper, there is a picture of "our code". I want to draw a box somewhere where there’s room in that picture, and I want to label it "rigorous". Let’s call it the rigorous playpen.
The Rigorous Playpen See Full Post
Companies spend a great deal of time and energy seeking to get their teams synchronized. Several forces motivate these efforts. It’s worth taking a second to look at these. One force: the belief that synchronization provides steering points. The notion here is that since we’ve just synchronized, now is a good time to react to the market and adjust the direction in which the project is headed. Second: the belief that no given team is able to do all the
Sync Points Reduce Our Trade’s Effectiveness See Full Post
