Shows
Software Developers Journey#215 Michael -Geepaw- Hill is a joyful street-geekGeepaw (Michael Hill) story started like no other, with the tale of his firing. He told us how he began as a computer salesman and got interested in programming and the Forth programming language. We briefly discussed being independent before talking more and more about the state of our industry. We spoke about joy being mandatory for the team's success. We discussed methods and how they won't solve a thing if joy isn't present, not even Extreme Programming. We finally talked about motivators, Geepaw adding "Rythm" and "Safety" to the well-known "Autonomy, Master and Purpose" of Daniel pink.
2022-08-1649 min
Roasting MarshmallowsThree software engineering coaches get coached by GeePaw HillHow much are you able to learn on your own? For some people, reading books, articles, and going to certain training courses are all they need to keep steadily growing their skillset.For teams however, things are a bit more challenging. Retrospectives are indeed a great help, but these are still from the team's own perspective. Sending a team to training could help as well, but how do you know what training to pick? Sometimes external help, in the form coaching, can be beneficial for you and your team.Someone who does such coaching is...
2021-07-201h 07
PawCast with GeePaw HillRe-Orienting Around Backsteps | #119When large teams struggle with trunk-based development (TBD) or continuous integration/deployment (CI/CD), a good strategy is to re-orient how the teams face "backsteps", moments in our workflow where a discovery forces us to re-open a stage we thought was closed. Large teams & projects often pre-date the use of modern synthesis techniques like TBD or CD, and during adoption, intermixing their Before with this new After can produce quite a bit of discomfort. If it gets bad enough, it can even kill off the improvement effort. What to do?
---
You can read the f...
2021-05-0409 minPawCast with GeePaw HillOn Agile Methods | #118A couple of days back, I tweeted about SAFe. It created some stir on the timeline, which was great, as I got to see a lot of perspectives. I want to use that tweet as an excuse to talk about something much larger. This will be a long one. :)
---
You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter, or drop a voice message via the voice messages link here on Anchor. If you are interested in becoming more involved in the C...
2021-04-2710 min
The 6 Figure DeveloperEpisode 193 – Software Coaching with GeePaw Hill
GeePaw Hill is a coach – a professional harvester of the value of change — in the software development industry. A geek for forty years, he’s spent the last two decades helping individuals, teams, and organizations take steps to become closer to who or how they wish to be. You can reach him through his site: https://geepawhill.org.
Links
https://twitter.com/GeePawHill
https://www.geepawhill.org/
https://www.linkedin.com/in/geepawhill
“Tempting Time” by Animals As Leaders used with permissions – All Rights Reserved
× Subscribe now! N...
2021-04-2636 minPawCast with GeePaw HillStandup Braindump | #117The standup is a short recurring meeting used to (re-)focus the team-mind on effectively moving stories through our workflow. Here's my recommended approach to having standups be useful and brief. The general sequence is 1) address team-wide emergency issues, 2) work story-by-story, 3) distribute new work, 4) address team-wide non-emergency issues. Note that, quite often, there is no part 1, and no part 4. Sometimes there's not even a part 3. Some general tips, then:
---
You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter, or drop a...
2021-04-2005 minPawCast with GeePaw HillThe UI Monolith Making App | #116The ultimate making app for a shipping multi-service system is actually a one-machine monolith with a UI. If your team is experiencing the most common pains from working in a large SOA environment, the productivity payback will be enormous. We've talked a lot about the idea of having a shipping app for our customers and a making app for us. We can use the same source base to make multiple binaries. We target customer needs with one of those, and we target developer needs with the rest. The economics of this approach are straightforward: As long as a making...
2021-04-1310 minPawCast with GeePaw HillRice & Garlic & More Smaller Steps | #115My rice'n'garlic advice, "take many more much smaller steps," can be said another way: reject any proposed path that requires a step size larger than the limit you've set for that particular domain of activity. "Rice'n'garlic advice" is blind advice, for when people ask you what to do, but you're not there & can't see. You have to guess. A professional chef I know, when asked to give blind advice, always says this: 1) That's too much rice. 2) That's not enough garlic. This kind of advice isn't expressing a universal law. (It is difficult to do, but you *can* have too...
2021-04-0608 minPawCast with GeePaw HillA Making-App UI | #114Once armed with the idea of a shipping app and a making app, a whole range of possibilities open up. Among the most powerful: give your making app a UI just for making. A "making app" is when we take the same sourcecode from the program we're shipping, and use it for another program at the same time. That program is one we develop and tailor expressly to enable us to work more effectively on the shipping app. We tend to overlook it, but when we run our unit tests, for instance, we're actually running a making app. Whole...
2021-03-3008 minPawCast with GeePaw HillScenario Builders | #113In a data-rich environment, we can use the Builder concept to make DSL's for our Making application. This often makes testing the hard business core of our code both faster and easier. We've spoken in the past about using our codebase to do more than one thing. We always use it to create our shipping app. But we can and do use it for an app that improves our *making* process. We call that the making app. When you're running your microtests, it doesn't necessarily look or feel like you're running an app, but you are. And that app...
2021-03-2307 minPawCast with GeePaw HillHumans & Mistakes | #112Approaches in software development -- or anything else -- that don't take ordinray human failings as their starting point are prone to dramatic failure. "The Impossible Human" is, well, noticeably uncommon. Let's dig in on that. Some years back, I made content for a CMS that had a whole lot of overlapping parts, each with its own special language. I found it very difficult to express myself quickly & cleanly, and, it being me, I complained about it a lot. And very often, the responses I received were in the form of "It's easy, just remember X." It still being...
2021-03-1107 minPawCast with GeePaw HillWeb-To-Database Potshots | #111"It puts the database on its browser skin, or else it gets the hose again." This task occupies the daily life of a great many programmers. Today, I want to throw out some random sparks of advice for people working in that setting. In enterprise IT, it is commonplace for backend folks to work on problems shaped like this: there's a web endpoint controller on the top, a database on the bottom, and some simple or complicated business logic in the middle. I watch people working in this kind of environment quite a bit, and I have to tell...
2021-03-0309 minPawCast with GeePaw HillAn Early TDD Experience | #110When we talk about transitioning to microtest TDD, we have to figure out how to provide the right experiences in the right order. That's why I propose we start by getting the experience of changing a well-microtested graceful class. "Create Experiences, Not Arguments" is one of the core habits of change-harvesters. We want to take that slogan very seriously when we approach any significant change to our practice. And microtest TDD, believe me, is a significant change. A would-be TDD coach or instructor nearly always carries an implicit belief that her victims do not have, drawn from lived experience...
2021-02-2308 minPawCast with GeePaw HillTechnique & Transition | #109Microtest TDD is a "way of coding", not an after-market bolt-on to old-school approaches, and as a result, we have to constantly intertwine our conversation about technique with our conversation about transition. Technique, skills, philosophy, theory, all of these are tremendous delights to me. I love to muse & mull & illustrate & analyze & argue & point, and I greatly enjoy doing it on the topic of the modern synthesis in software development. But all of this explication & analysis is about a framework of related ideas. And that body of knowledge is a "there", a point on the time horizon we can orient...
2021-02-1607 minPawCast with GeePaw HillAwkward & Graceful | #108In microtest TDD, we describe collaborations as "awkward" or "graceful". The distinction is critical to understanding how the Steering premise and the Pieces premise work together to make TDD a productivity tool. Let's dig in. We talked the other day about understanding & manipulating dependency in microtest TDD. The awkward/graceful distinction is at the heart of this. It can be a long journey to get it all, but it *starts* as soon as you take TDD for a spin in your day job. To get into this, let's take two classes most of us are familiar with: String and...
2021-02-1208 minPawCast with GeePaw HillTDD's Goldilocks Challenge | #107Successful microtest TDD depends on our ability to solve a goldilocks challenge: when we test our code pieces, do we isolate them too much, too little, or just right? Finding the sweet spot will mean letting go of rulesets & purity. The five premises we've been over: value, judgment, correlation, steering, and pieces, guide us in a complicated dance of software design. At the center of that dance is our awareness of -- and our manipulation of -- "dependency", how one part of the code uses other parts of it. From the moment you wrote your first program, you produced...
2021-02-0908 minPawCast with GeePaw HillLearning TDD w/ Four Mentors | #106Because microtest TDD is more a "way of geeking" than a technique or a received body of knowledge, building one's faculties is a long and sometimes perilous effort. Let's talk about learning. I want to approach the question(s) of learning TDD in some ways that are a little different from others I've seen. I've written two TDD curricula myself, and am involved currently in helping with two more. I see all of them, including the current ones, as "interesting failures". At first, learning/teaching TDD seems like a road, then over time it seems to become a tree...
2021-02-0510 minPawCast with GeePaw HillTDD As Change Strategy | #105Microtest TDD is an effective change strategy because it dramatically improves our performance at comprehension, confirmation, and regression detection, all critical factors in handling change quickly & safely. We've covered a lot of ground in considering TDD recently. The five premises, the need for a change strategy, the increasing collaboration, complication, and continuity of modern software, and some high-level less-obvious aspects of the practice itself. I want to put some of these pieces together, and show you how TDD adds up to an effective change strategy.
It doesn't "boil down" very well: as with most conversations around complex systems...
2021-02-0208 minPawCast with GeePaw HillOn Political Content | #104I got one of those messages I sometimes get from a reader, telling me that including my politics in my muses/blogs is off-putting.
As a general rule, I don't bother to respond to these. I gain and lose followers all the time, everyoen who makes content does, for all sorts of reasons, and that's just one more.
Today, though, surrounded by all of this, I feel like I want to give a more full statement on the matter.
---
You can read the full transcription of this podcast over on...
2021-01-2904 minPawCast with GeePaw HillAspects of TDD Practice | #103Before we can make the case that microtest TDD is an effective change strategy, there's a few high-level aspects of it that we need to highlight. We tend to take these for granted in our case, but newcomers won't already know them. Today, I'm writing for the newcomer. It's going to be a little rambly, because the ideas aren't partitioning a single conceptual level into its component parts. Think of me as going over a text with a yellow highlighter, bringing out some points newcomers might not readily see. Twinning: When we do TDD, we are working in a...
2021-01-2608 minPawCast with GeePaw HillWhy Have a Change Strategy? | #102Microtest Test-Driven Development is a strategy for *change*. To understand the case, we need to answer two questions: 1) Why have a strategy for change? 2) How does TDD provide one? Let's take up the first question today. Why is having a change strategy so urgent?
The TL;DR is dead simple:
Because continuous ongoing change is at the base of all software development, both before and after our software is in the field.
---
You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always...
2021-01-2207 minPawCast with GeePaw HillThe Value Premise | #101Today it's microtest TDD's Value Premise: TDD ships more value faster when that value depends on changing our branching logic safely & quickly. Let's dig in. I am frequently presented with declarations that TDD is fine for plebs like me, but useless for software of type X. I've heard every variety of app type or coding specialty or domain substituted for that X. In other parts of the forest, I hear that the purpose of TDD is high quality, and if you don't care about that, you don't need TDD. Or that it's for satisfying personal or professional ethics, and...
2021-01-1909 minPawCast with GeePaw HillThe Correlation Premise | #100Today, let’s take on microtest TDD’s Correlation Premise: Internal software quality (ISQ) and productivity are directly correlated. They go up together, and they go down together. The correlation premise lies in direct opposition to the widespread but grossly over-simple analysis that suggests we can “go faster” by shorting the internal quality of our code. It says, on the contrary, the lower that internal quality, the lower our productivity. Start by noting that we’re talking about internal software quality (ISQ), not external software quality (ESQ). What’s the difference? ISQ is the attributes of the program that we can only...
2020-12-2506 minPawCast with GeePaw HillThe Judgment Premise | #99Today, let’s talk about microtest TDD’s Judgment Premise: “We are absolutely and permanently reliant on individual humans using their individual judgment in TDD.” The judgment premise emphasizes the human in test-driven development. There are no known non-humans practicing TDD, so it may seem a odd that we have to talk about this, and yet, we do. As software geeks, we work with the most rigid deterministic systems conceivable, and we do much of that work in abstract mental space. To say that our target systems are machine-like is to say too little, really: they’re more machine-like than any r...
2020-12-2205 minPawCast with GeePaw HillThe Steering Premise | #98Microtest TDD's Steering Premise is quite simple, which may be why it sometimes meets furious opposition. It says "Tests and testability are first-class citizens in design." Let's talk that over a little. There are, for any software problem, an infinite number of functionally correct designs. If implemented, they will work. But we don't *implement* an infinite number of designs. Why not? Because though they may be functionally correct, they still don't fit our context. We reject designs -- more often we reject individual choices in designs -- for a variety of reasons: reliability, cost of hardware, poor fit to...
2020-12-1106 minPawCast with GeePaw HillThe Pieces Premise | #97The Pieces Premise says, "To get the whole thing to do what you want, start by getting each piece of it to do what you want. It's one of the basic underpinning of microtest TDD. The idea behind the pieces premise is actually pretty straightforward. All programs are divided into pieces, separate parts, each of which performs some behavior the program needs. If the pieces don't work, the whole won't work. I have seen a lot of struggling TDD efforts in my time. A great many of them start off well and end poorly, and it's very often because...
2020-12-0808 minPawCast with GeePaw HillCollaboration, Complication, Continuity | #96I was recently asked, by two different groups, two seemingly different questions, but I gave them both the same answer: Collaboration, Complication, and Continuity. Let's mull that situation over. I spoke at a user group recently, on their choice of topic. They, ever so gently, pointed out that I'm old as dirt and have been a geek for forty years. And their question was how has programming changed since the caveman days of the '80s? In another part of the forest, I gave a university lecture last month, and because I was the industry expert, one of the...
2020-12-0107 minPawCast with GeePaw HillOld Coach at the End of the Bar | #95I am supposed to be shooting the next Real Programmer episode today, but I had a really good wrap-up meeting that was important, and I'm waiting for one more piece I need to send a first invoice to a new client, and I want to talk about coaching. In another part of the forest, some folks are discussing the frustrations of what is, by whatever name we call it, coaching. And the long and the short of it is "they won't even try what I want them to do". These sorts of conversations are pretty much standard "coaches-at-the-bar" talk...
2020-11-2705 minPawCast with GeePaw HillChange Harvesters Iterate Change | #94Human, local, oriented, taken, and iterative, these are the change-harvester's bywords. In iterative change, we not only accept the reality of gradual stepwise refinement -- changing what we've already changed before -- we actually anticipate it and take advantage of it. With iteration, I think a great starting point for the concept is to watch just about any youtube video where a skilled artist draws a realistic rendering. What you will see almost inevitably is a direct implementation of iterative change. The strokes begin quite broadly, faintly indicating the broad contours of the subject. Experience is relevant here: those...
2020-11-2408 minPawCast with GeePaw HillChange Harvesters Take Change | #93In change-harvesting, we use this word "taken" in multiple senses, but to put it in a single sentence: the change-harvester takes both the substance of and the approach to change from what is already there. We *take* our changes from here, we don't *give* our changes to there. To go from A to B, it is easy to focus all of our attention on B. The change-harvester is saying we can't make effective changes unless we see them as *changes*, as transformations to A. And that implies paying a great deal of attention to what that A is and...
2020-09-2507 minPawCast with GeePaw HillChange Harvesters Orient Their Changes | #92Locality drives us to steps that are nearby, within our ready grasp, & therefore inherently small. But our *vision* isn't small, our program isn't, it's quite large. We can't get to it in one local step. How do we reconcile this? Oriented, taken, & iterative, each have an angle. Oriented is as simple as this: After every local step, we take a second and simply turn our selves back towards our distant target before we choose or take the next step. Humans are actually quite good at this. You do it when you cross a busy road. There, it happens so...
2020-09-2208 minPawCast with GeePaw HillChange Harvesting Makes Local Changes | #91We change-harvesters say human, local, oriented, taken, and iterative. We talked about human a couple of day ago, let's take on local. A quick sketch of the idea, and a couple of cases will do, yeah? When we say that we want our changes to be "local", what do we mean? I think in terms of two nearby metaphors, "neighborhood" and "reach". We want our changes to be in the neighborhood, and we want them to be in easy reach. Of course, "small" comes to mind right away, but it has its problems, most notably that it almost immediately...
2020-09-1808 minPawCast with GeePaw HillChange Harvesting Emphasizes The Human | #90Human, local, oriented, taken, and iterative: this is how change-harvesting in software development approaches change in most contexts in the trade. Let's take "human" today, and see where it leads us. When we use that word "human", change-harvesters are getting at the fact that, in systems involving humans, machines, and procedures, the humans are the most powerful force. When we seek change while ignoring human factors, we go awry quite rapidly. Human emphasis, in this usage, opposes both procedural and mechanical emphases. A common form of the problem is to implement a system using simple logic and uni-directional causality...
2020-09-1507 minPawCast with GeePaw HillThe Cost of Rework Avoidance Theory | #89To make the case for Change Harvesting as an approach, it's important to understand that the cost of Rework Avoidance Theory isn't imaginary or subtle, but both concrete & quite high. The most essential aspect of the RAT (Rework Avoidance Theory) is its emphasis on the endpoint: the City On The Hill we call it. The central concept: define the City rigorously, optimize building it off-line, move in to it only when it's done, and never change it again. In the RAT's idea of efficiency, changing a thing is waste. After all, why did we build it all if we're...
2020-09-1108 minPawCast with GeePaw HillCHT Means Different Design Imperatives | #88Change-harvesting software design centers "online" brownfield development: change-centric thinking. Most older sets of design imperatives are based in "offline" greenfield development: build-centric thinking. The differences can -- and should -- lead to design disagreements. The significance of "online brownfield" vs "offline greenfield" is hard to overstate, in all areas of software development, but especially so when we talk about what makes a design "good" or "bad". In four decades, I've read countless books about software design. I've had my favorites, and I'm sure you've had yours. Some of my favorites really don't stand the test of time, of course...
2020-09-0808 minPawCast with GeePaw HillHuman-less Change Fails | #87A lot of the reasons that change fails, inside & outside technical organizations, come down to one broad statement: the people who have to make the changes are humans, and the people who want them to make the changes have not successfully taken this into account. People ask me why the change they're trying to make doesn't happen. The questions come from all levels of an org, from the very top to the very bottom. "Why won't they change?" It's often accompanied by an implicit theory. It's often aimed at me because I have had some success. I should say...
2020-09-0406 minPawCast with GeePaw HillCHT-Style Implementation | #86When we did our compare & contrast of the working models underpinned by Change-Harvesting theory (CHT) vs Rework Avoidance Theory (RAT), we temporarily sidestepped the specific differences of the implementation part. Let’s drill in on that today. It was quite a sidestep: other than the implementation part of the two models, they have much in common, with the key difference being the highly iterative nature of CHT’s approach. If we squint a little, & we don’t talk implementation, we can see the CHT model as being a daisy-chain of RATs. Each step is a “mini-RAT”, on a scale of a coupl...
2020-09-0108 minPawCast with GeePaw HillChange Harvesting vs Rework Avoidance | #85Let's compare and contrast the RAT (Rework Avoidance Theory) model of software development with the CHT (Change Harvester Theory) model. The differences are multiple and pronounced, so this may take us a while. I want to talk not so much about the theories today, as about the working models they underpin and lead to. Those models are a kind of inner core of making software, shaping our activities of course, but also our solutions, and even the problems. The RAT model sees software development as an off-line program-construction activity composed of these parts: defining, decomposing, estimating, implementing, assembling, and...
2020-08-2809 minPawCast with GeePaw HillIterative User Value in Flows | #84A flow app, one that steps the user through an acyclic graph, typically gathering info at each stage, can be built to provide iterative user value by gradual refinement. Let's look at how that's done. The standard flow app is when we walk the user through a complex operation, and we gather the pieces step by step. Though it looks like a straight line to any given user, the answers in previous steps actually shape the following steps, hence the directed graph under the hood. In most web environments, flows are page-to-page. In desktop apps, they're set up like...
2020-08-2506 minPawCast with GeePaw HillThe Correlation Principle | #83The correlation principle says that our productivity is tightly correlated with the internal quality of software. The two go up together, and they go down together, and you can't trade away the one to get more of the other. The basic idea of the correlation premise is actually pretty simple, but when we introduce it, we generally get a chorus of yabbits. ("Yeah, but...") There are several confusions common to most of that chorus, so let's look at them one at a time. Confusion: mixing up internal software quality and external software quality. The yabbit takes this form: "Yeah...
2020-08-2110 minPawCast with GeePaw HillIterative User Value | #82How do we iterate user value? How can we follow the "more smaller steps" approach and still deliver a positive experience for the user? Today let's look at some ways to approach this problem. The problem. We want our work to come in stories of about one team-day and a half, but that's not much time, and we need to provide a steady flow of value to our users. The truth is, most of us have been trained away from even *trying* to do this. It's no wonder it's not obvious how to do it now. I want to...
2020-08-1809 minPawCast with GeePaw HillPathing: A Style of Laying Out Work | #81I do “pathing” when I project my work into the future: laying out a sequence of work steps, where each step ends with the code in a shippable state. More than design, and more than planning, pathing is a kind of work-style, and it brings me several benefits. When we're pathing, we're really just decomposing a problem, breaking it into several smaller problems. What makes me call it pathing -- instead of design or planning -- are two requirements we want each sub-problem to meet before we're satisfied with it: size and shippability. I use the pathing workstyle most freq...
2020-08-1407 minPawCast with GeePaw HillEmbrace Change: Modern Geekery Practices | #80We *change* software, therefore we want everything around us to support that: code, technique, tools, controls, tracking, planning, infrastructure, and above all, culture. The last two decades have added a broad assortment of change-enabling elements to the trade. To get an idea of this breadth, let's do a little enumeration. Change, how do we embrace thee? Let me count (some of) the ways...Three broad features will emerge, so I'm going to call them out now before we get to details. These are a very much heightened focus on collaboration, iteration, and confirmation. They work together and separately to...
2020-08-1108 minPawCast with GeePaw HillPedagogy In The Trade: Changing Emphasis | #79I want to start talking about teaching in the geek trades. Today in particular, I want to talk about "emphasis", what our style & materials stresses or underlines about the path to mastery for our up and coming geeks. I am by nature an analyst, a theorist, and a person driven to critique. That makes me pretty negative-seeming at times. That's not accidental. I find that I often can't find a way forward until I have thoroughly identified what I don't like about where I am now. Of course, while one does this, one also shares it, often enough in...
2020-08-0709 minPawCast with GeePaw HillRetrospectives: Variety Is Key | #78I strongly recommend high variation in both format and facilitator of retrospectives. So let me sketch, as quickly as possible, the retro-scheme I see the most of, and don’t care for. It’s got four columns. "Didn’t go well". "Went Well", "Action Items", "Kudos". Sometimes they change the text of the columns. One person, the same person each time, leads the meeting, by gathering stickies, virtual or otherwise, and plunking them on a board in the right column. That person typically groups the ones that seem closely related. Now we "process" them. This involves reading them each out lo...
2020-08-0408 minPawCast with GeePaw HillTDD Tests Are First-Class Code | #77My standards for TDD microtests are the same standards I have for shipping code, and I follow them in microtests for the same reason I follow them in shipping code: they make me faster. I go out in the field, and I inspect a lot of tests, and I have to say, lousy factoring, bad naming, massive duplication, and low signal-to-noise are pretty much the order of the day out there. This often holds true even when the shipping code is comparatively well made. I suspect a lot of this comes from the "chore" outlook that's so prevalent around...
2020-07-3109 minPawCast with GeePaw HillRe-Balancing Made, Making, and Makers | #76Some years back I realized my most beloved parts of our software movement could be characterized as re-balancing our approach towards the triad of Made, Makers, and Making, and away from a prior focus only on the Made. Let's schmooze about this. First of all, what do I even mean, about this adjustment of focus? For easy writing and reading, I'll treat this as a Before & After thing, even tho I know full well that's a fiction, for two reasons. First, although "Agile" is the buzzword of the decade, it's still not a majority or even plurality in market...
2020-07-2809 minPawCast with GeePaw HillMicrotest TDD is Gray-Box | #75In the '70's, an important movement developed in testing theory, called "black box" testing. The idea is straightforward: We can prove our software works by treating it as a closed opaque container with only some knobs and meters on the front of it, a "black box". The tests we write don't know what 's inside the box, they only know the specification of how the surface controls are supposed to work. If they don't work tht way it's a fail, if they do work that way it's a pass. This idea has great merit under certain circumstances. It...
2020-07-2410 minPawCast with GeePaw HillUnderstanding Incremental Switchover | #74The incremental switchover approach is my default response to any transformation problem I can't resolve in an hour. It's the secret to successful brownfield development, but it's not widely understood & used. Let's take some time to understand it. Incremental switchover might be called "the art of the path". At its simplest, given two points A, where we are, and Z, where we wish we were, incremental switchover concerns itself with B, C, D, and so on, the route we take. We talked about RAT a couple of days ago: Rework Avoidance Theory. RAT is also concerned with path, but...
2020-07-2110 minPawCast with GeePaw HillThe RAT: Rework Avoidance Theory | #73Rework Avoidance Theory is a cluster of related ideas seeing a change as having a clear start-point & end-point and a straight & stable path between them. It draws its inspiration largely from logic based in relatively straightforward metaphors to the physical world. One metaphor is that of a footrace. The change is a well-marked track with one runner. It assumes 1) linear cost of step regardless of size, 2) stability and perfect knowledge of path and endpoints, and 3) indifference to post-footrace consequences. A second metaphor is that of seeing the change as a finished product, built in standard parts by isolated individuals...
2020-07-1708 minPawCast with GeePaw HillTurning Implicit into Explicit | #72An implicit understanding is anything a skilled geek would have to be told before being set loose in your codebase to make a change. Implicit understandings take lots of different forms, but at their simplest, they often involve hidden correlations. Probably the most common form of implicit understanding is related to the smell we call primitive obsession. You'll see a series of methods, and each method takes the same three arguments, an int for the ID, a string for the descriptor, and a decimal for the amount, let's say. Those three arguments are actually correlated: together, they uniquely identify...
2020-07-1409 minPawCast with GeePaw HillModel-View, The Desktop, and TDD | #71The basic idea behind all Model/View schemes, and there are several of them, is just this: draw a thick line between what your program does and how your program shows what it does. In other words, it's a compositional heuristic, guidance for how we break our problems into smaller problems. Give some objects/modules the responsibility for doing the work, and give other objects/modules the responsibility for showing the work. Tho it was originally conceived in the smalltalk world, there are many modern usages of the idea. Nearly all UI-centric frameworks take the Model/View split as...
2020-07-1011 minPawCast with GeePaw HillHelping Your Downstream Collaborators | #70Let's talk about ways to make life easier for downstream developers, be they front-end or dependent back-end people. Whether you have a bunch of front-end folks driven from your monolith, or you live in service-mesh land with dozens of microservices, the people downstream from you have to use your output to make their output. They are, in fact, a kind of customer. We've talked at some length about the Made, the Making, and the Makers, and how the trade is normally over-obsessed with the Made, and under-emphasizes both Making and Makers. Here are some ideas, no particular order, for...
2020-07-0708 minPawCast with GeePaw HillMetrics and Three Traps | #69In twenty years of coaching software development teams, I've seen maybe a hundred or more orgs try to figure out how to measure their process, and the majority of them have fallen into some mix of three traps: 1) the more trap, 2) the objectivity trap, 3) the rollup trap. Years ago I heard the non-standard saying that "the road to hell is lined with great parking spaces". I see these traps that way: they seem to suck us in more or less thoughtlessly, and once in them, we seem to fight noisily about decorating them, but never consider leaving them.
2020-07-0306 minPawCast with GeePaw HillThe Right Step | #68A lot of folks spend a great deal of time arguing about which step is the right step. A change-harvester would say to stop worrying about this so much. The right step to take is 1) small, 2) not definitely backwards, and 3) not the last one. Let's take up "not the last one". A lot of thinking about change comes with the baked-in idea that there will be an end to it, a "finish line", if you will. We will make a change, or some changes, and in so doing we will cross a finish line, after which change stops. This...
2020-06-3008 minPawCast with GeePaw HillMore on Small Steps | #67The single most important thing my years of doing XP helped me learn, specifically TDD and refactoring, is about the size of the steps. When I started it, I had in mind “small steps” that were, well, they weren’t really small at all, just “comparatively less gigantic”. Graybeards like me came up a certain way. We relied heavily on 1) large and well-organized memory, 2) a facility for rapid transition back and forth between high-structured high-detail imperative text and ordinary meaning, 3) an ability to imagine large transformations “whole”. It’s a curious contradiction, to me, that these attributes were what enabled me to be...
2020-06-2606 minPawCast with GeePaw HillPull & Swarm | #66Pull & Swarm is a technique for approaching the workload in front of a small team. It amounts to pulling one story from our queue at a time, and throwing all of our resources and humans at the same story at the same time. P&S can be useful to Scrum-based teams, but also to any small team using any method. Some teams I have worked with have done *pure* P&S. No planning as a group at all, no ceremonies, just make a queue with a half-dozen things in it, pull one, finish it, on to the next. But...
2020-06-2308 minPawCast with GeePaw HillMicrotest TDD: Economics | #65The economic aspects of microtest TDD are inextricably tied to the operational aspects of it. If we concentrate only on the artifacts involved, we will lose the picture and misunderstand the value proposition. As a professional geek, the heart of my job is changing rigidly structured imperative text in collaboration with other humans, in order to meet a variety of locally or temporally aligned goals. That's fancy talk for "I change code, in community, for money." The central event is the *changing* of code. (It's remarkable to me how very little attention we pay to this in the trade...
2020-06-1908 minPawCast with GeePaw HillHitting On Speakers (Rant-y) | #64I want to talk about this thing where you see someone on stage/screen presenting material about geekery, you decide you're attracted, and you send them mail or dm hitting on them.
You must not do this.
It is rude, unprofessional, and hurtful to many people.
Stop it.
---
You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter, or drop a voice message via the voice messages link here on Anchor. If you are interested in...
2020-06-1606 minPawCast with GeePaw HillMicrotest TDD: More Definition | #63What's a microtest, anyway? I write a ton of tests as I'm building code, and the majority of these are a particular kind or style of test, the microtest kind. Let's talk about what I mean by that, today, then we'll talk later about how that turns out to help me so much. A microtest is a small, fast, precise, easy-to-invoke/read/write/debug chunk of code that exercises a single particular path through another chunk of code containing the branching logic from my shipping app. Microtests are first-class source code, maintained and kept side-by-side in the vault with...
2020-06-1207 minPawCast with GeePaw HillMicrotest TDD: The Big Picture | #62I think of my style of coding as "microtest TDD". That can be misleading for folks, so let's take a walk over a few of the ideas, implicit and explicit, that make up the approach. First things first, bear the money premise in mind in all that follows, to wit: "I'm in this for the money." In the software trade, we make money by shipping more value faster. This is why I adopt these practices, because when I do them, I go faster. In particular, I don't do them out of a fondness for artistry, intellectual purity, common decency...
2020-06-0905 minPawCast with GeePaw HillThe Jump To Microservices | #61More seriously, the first piece of advice I'd give a monolith-owner about converting to microservices would be to work very hard to factor their monolith well. Interestingly, across dozens of cases, I've never seen that advice taken. There's always a well-dressed person with excellent powerpoint who is happy to give a compelling case for a technical solution to a problem that isn't technical. If you can't factor the monolith, you won't be able to factor your microservices. All of the same forces will be in play, all of them, with the difference that in a monolith excellent factoring is...
2020-06-0504 minPawCast with GeePaw HillAn Intro to Spikes | #60I use spikes, periods of code-changing activity that end with no pushes, all the time, at small scale and large, as a way to develop my path. It's a vital technique, and it's often underplayed, so let's spend some time with it. What's a spike? A spike is a stretch of time I spend mucking about in code, and that stretch of time has one rule: "Do anything you want, because you can't keep it." We originally used the term to describe a certain kind of story. We'd be facing some task without the slightest clue of how to...
2020-06-0209 minPawCast with GeePaw HillSteps, Value, and Change-Harvesting | #59Let's talk about steps and value. Out in the world, folks make a lot of decisions involving these ideas, they reason about them. We want to make sure our reasoning is based on a thorough understanding of the implicit premises. What's a step? A step is a gap or space, in time and activity, in between two points, a Before point and an After point. At the Before point, a system is "ready". At the After point, a system is "ready". In between, during the step, the system is "unready". That idea, of ready or unready, needs a little...
2020-05-2910 minPawCast with GeePaw HillMy Best Bug | #58I shipped a word processor that formatted the hard drive every 1024 saves. Must have '84 or '85. I was a bright 25-year-old with about five years in the game. I was one of two programmers who wrote & maintained a suite of apps kinda like Office: spreadsheet, wp, database, plotter, such like. We customized everything for three or four vertical markets. So I wrote most of the wp. This was in Forth, on a variety of OS/CPU combinations. Young'uns don't necessarily know this, but in those fays there'd be a new microcomputer with a custom OS and one of...
2020-05-2606 minPawCast with GeePaw HillJuniors & Seniors | #57Lotta inspiration for junior geeks stuff floating around. I'm having a low productivity day today because, well, you know all of that, so I'll take a minute nd pitch in. Do you know what I did for about twelve elapsed hours of coding time? I solved a problem. Cuz, you know, I got mad skillz, and have been geeking for forty years, and am even, in a couple of microdomains, a bona fide citable expert. I'll tell you the problem I solved, next tweet, but before we take the dive, I need you to just, relax, okay? Explaining this...
2020-05-2207 minPawCast with GeePaw HillUsing the Strategy Pattern | #56The strategy pattern lets you make "pluggable algorithms", so clients have different behavior without having different code themselves. We often use it to capture the "consequence in code" of some condition, which we can then let other code use without re-testing the condition. Here's a little java snippet:
dimension = horizontal ? width : height
If you're not familiar with ternary operations, what this says is "if horizontal is true, use the width, otherwise use the height". That snippet occurs in the context of a SplitPane (from JavaFx). A SplitPane holds N other panes, and its job is...
2020-05-1909 minPawCast with GeePaw HillDealing with Nulls | #55Another refactoring topic today: dealing with nulls. There are a bunch of techniques, but they amount to a) don't, and b) do but only one time ever. The basic idea: a null always occurs in a particular context, and in that context, it has a meaning. When we pass it up or down our call-stack, we are *changing* contexts, and hence changing meanings. We're using the same symbol to mean different things at different times. Using the same generic symbol to mean different things in different contexts is anti-signal. It represents a loss of meaning.
---
2020-05-1509 minPawCast with GeePaw HillRefactoring Strategy: Move It Where You Can Test It | #54When I can't test it where it is, I look to move it somewhere else, where I can test it. Today's notion isn't so much a single refactoring as it is a strategy that can be achieved in different ways (and different multiple steps). A modern and frequently occurring case: using a cool framework to expose service endpoints, we write a function and then we annotate it and poof, it's an endpoint. This is how Java+Swing works, or Python+Flask. When we give that function a body, it will be a body of "our branching logic" (OBL). We've...
2020-05-1207 minPawCast with GeePaw HillRefactoring: Invert Dependency With Observer | #53Another refactoring today: Use the observer pattern to invert an infelicitous dependency. In and of itself, this is a modest refactoring, but its smell often co-presents with others, and unravelling it all can be tricky. (Note: We aren't remotely done talking about first and second-order refactorings, there are plenty more to go. But I'm not writing a catalog, I'm working a project, so when a hefty one like this comes along, that's when I'm talking about it. You're gettin' em as I'm doin' em.) "Infelicitous dependency", eh? What could make a dependency an unhappy one? There are a lot...
2020-05-0810 minPawCast with GeePaw HillRefactoring: Demeter-Wrapping | #52Demeter violations are places where a client accesses not just an upstream service, but that service's upstream services, or even that service's service's upstream services. It's a common problem in evolving code, and left untended, a classic source of unchangeable code. Demeter calls look this: a.getB().getC().doSomething(). a is getting a B, but is using that B expressly to get a C, then finally calling some method on the C to do something. (The getX()'s could as easily be exposed fields rather than methods: depends on idiom & language.) I want to stave off some potential confusion. 1...
2020-05-0507 minPawCast with GeePaw HillRefactoring: Keep It Running | #51A key value for those who take up the change-harvesting approach: "keep it running". This is actually a direct result of human, local, oriented, taken, iterative, and argues against many finish-line efficiency approaches. Think of a change as a point A, with an arrow coming out of it and ending at a point B. At the two points, we have a running system, but along the arrow, we don't: our change is in flight. The change-harvester seeks to keep those arrows as short as possible. I say seeks, but that's a little weak, actually: the change-harvester obsesses over the...
2020-05-0106 minPawCast with GeePaw HillChunking & Naming | #50In our continuing conversation about refactoring, I want to go a little abstract today, and talk about chunking and naming. Naturally, a topic this important has already been addressed by a stupid joke in the movie Airplane!, so we'll start there. A passenger is approached by a steward, asking if he might be able to help with a problem in the cockpit. He says, "The cockpit! What is it?". She says, "It's the little room at the front of the plane where the pilots sit, but that's not important right now." The number of things one can hold in...
2020-04-2807 minPawCast with GeePaw HillLarge-Scale Transformation and the Bias for Action | #49Change-harvesting takes the stance that our most reliable strategy for change is a highly iterative process of act-look-think, in roughly equal proportions, repeated in small local cycles. We oppose that approach to look-think-act, emphasis on think, in large global cycles. This opposition is, of course, not a philosophical light-switch, an all-or-none thing. If you abstract away the locality factor, a series of five a-t-l's looks like an a followed by a series of four t-l-a's, followed by a final t-l. :) So the difference between these issues has to do with the locality and its implications and the relative proportions of...
2020-04-2408 minPawCast with GeePaw HillLarge-Scale Refactorings | #48First things first, "large scale refactoring" is really a colloquial expression, a shorthand we sometimes use, but in my experience there is no such thing, for two reasons. The first reason is definitional. Remember, refactoring doesn't mean "changing my design", it means "changing my design without changing its function". We almost never do this at large scale. The marvel and the horror of this trade is the extraordinary demand pressure it operates under. Anyone who's done time in the silicon mines knows this. It is the origin of nearly every bad process in the trade.
"Takin' it o...
2020-04-2109 minPawCast with GeePaw HillSecond-Order Refactoring: Narrow The Question | #47Another small second-order refactoring for you today. I call it "narrow the question".
If you're asking an object for data, ask for exactly what you want to know, instead of what you'd need to compute what you want to know. A very simple example: the PlayerView wants to disable/enable some of its controls when the Player is actively playing. In the "before" code, PlayerView asks the Player for its PlayerState and decides, based on its value, whether that means the Player is playing or not.In the "after" code, PlayerView just directly asks the Player if...
2020-04-1705 minPawCast with GeePaw HillSecond-Order Refactoring: Swap Supplier and Supply | #46As a hardcore user of TDD and refactoring, there are a number of what I think of as "second tier" refactorings that I use quite frequently.
In one's first intro to refactoring, one sees a lot of "rename", "re-order", "inline", and "extract". These are pretty potent tools, don't get me wrong, but I think of them as, idunno, atoms. I think of these "second order" refactorings as small inorganic molecules. An example of this would be one I call "swap supplier & supply". Let's take a look, in this case, at a real one.
Episode 46 is l...
2020-04-1407 minPawCast with GeePaw HillWorking By Stories - A Change Harvester's Take | #45Let's talk about "Working By Stories" for this first one. I'll describe what I/we mean by that, and then we'll try to look at it through our change-harvesting lens. I had thought to do TDD & Refactoring first. But working by stories has some advantages. It's a smaller topic, it doesn't involve us in a lot of technique arguments, and it seems to be more widespread in adoption. Change-harvesting is expressly not limited in scope to code & coding. It's not a new technique for programming, it's an outlook and a concomitant strategy for successful change in complex adaptive systems...
2020-04-1010 minPawCast with GeePaw HillIterative Change - What and Why | #44The heart of the iterative approach is assuming change. We embrace it, we plan for it, we expect it, we encourage it, we enjoy it, we see it as the central act that defines what we are and what we do. A dynamic unity is a unity because it stays "the same", it persists across time. But it's also wildly dynamic: it is undergoing constant change, in its parts, their arrangement, the flows, even its boundary. The single unchanging aspect of a dynamic unity? The changing itself. You are a dynamic unity. Notice two things: 1) Many of your parts...
2020-04-0704 minPawCast with GeePaw HillTaken Change - What and Why | #43To get to there, we want to start from, work with, adjust, and nurture what we have right here. A couple of examples might tighten this right up for you. We'll take one from changing code and one from changing process. In the early days of a coding project, everything is new. We're working with a blank page, and our creation-act is almost entirely about adding to that page. One has tremendous range of motion, the freedom to spitball, to write whatever we want however we want it. In fairly short order, though, our project thickens, with new capabilities...
2020-04-0306 minPawCast with GeePaw HillOriented Change - What and Why | #42We've said that leaning in to the humans in our systems leads us to locality pretty directly. We say "find the smallest easiest nearest change with detectable outcome and make it". But this gives us a puzzle: there are often a lot of such changes. How do we decide between them? The change-harvester's "oriented" says don't sweat it too much: turn to face your non-local goal, and grab any change that doesn't make it further away. Don't spend a lot of cycles deciding which change aims precisely, take anything that's not definitely wrong and do it. Goals that are...
2020-03-3104 minPawCast with GeePaw HillLocal Change - What and Why | #41The change-harvester uses these five words to describe the properties of successful change: human, local, oriented, taken, and iterative. Let's talk about "local".
Episode 41 is live! If you are interested in becoming a part of the conversation, Click here to join the Change-Harvesting Camerata Today!
---
If you have any feedback you can always tweet @GeePawHill on Twitter, or drop a voice message via the voice messages link here on Anchor. You can also read the full transcription of this podcast over on GeePawHill.org.
---
Send in a voice message: https...
2020-03-2705 minPawCast with GeePaw HillHuman Change - What and Why | #40Today, let's talk about the change-harvesters use of the concept-cluster we describe with the adjective "human". We advocate that both the what and the how are best centered around the humans in our systems. The change-harvester looks at changes -- in code, in individuals, in teams, in process & flows, in organizations -- and sees that ,successfully applied change is human, local, oriented, taken, and iterative, often enough to adopt it as a general approach. So let's do "human".
Episode 40 is live! If you are interested in becoming a part of the conversation, Click here to join the...
2020-03-2408 minPawCast with GeePaw HillMultivalence for Change Harvesters | #39Monovalence is creating a kind of value "one ring to rule them all" then either coercing any other type of value into that one ring or ignoring it when the decision-maker can't figure out how, or just as commonly, forgets. In fact, there's lots of value in a dynamic unity that creates software that is not visible to the customer. Some of it's easily coercible, the kind of acts we call "axe sharpening". Some less so, things like enabling humans to work at all.
Episode 39 is live! If you are interested in becoming a part of the c...
2020-03-2105 minPawCast with GeePaw HillLining It Up That Way (Rant) | #38The reason it's so important for you to see 100 lines of code on your screen is that you have arranged the code so that 100 lines seems like a sane quantity. What you're doing is working against your own capability.
Episode 38 is live! If you are interested in becoming a part of the conversation, Click here to join the Change-Harvesting Camerata Today!
---
If you have any feedback you can always tweet @GeePawHill on Twitter, or drop a voice message via the voice messages link here on Anchor. You can also read the full...
2020-03-1802 minPawCast with GeePaw HillTDD On The Front End | #37A recurring respondents' theme is "TDD is irrelevant in front-end code". It's easy to offer/receive this comment combatively, but I think a little more rich discussion of the factors involved might bring us to new and different positions about UI and TDD.
Most folks who offer that are living in some sort of JS world: their code is client-side scripts attached to html pages to render various contents received from another application. Their browsers are in effect frameworks, inside of which all their code runs.
(Aside: One of the most prevalent trade problems caused...
2020-03-1012 minPawCast with GeePaw HillThe Change-Harvester's Value | #36The change-harvester's take on "value" is quite different from the software trade's "standard" view. To get at that difference will take us a little time.
Three differences stand out for me just now, and they have to do with 1) definition, 2) distribution schedule, and 3) temporal stability. I want to take a look at these in a particular context: "the long story".
(Aside: I'm mildly sick today, so it's gonna spill out a little more slowly. It's dumb to work when you're sick, but you don't understand: I want to go out for dinner & drinks this evening...
2020-03-0606 min
Programming LeadershipChanging How We Change Software with GeePaw HillWhat if we could create a trade culture that allowed for change rather than relying on mechanical thinking? In this episode of Programming Leadership, Marcus and his guest, GeePaw Hill, discuss how the doubling rate in the software industry has resulted in a complete lack of trade discipline. Drawing on his 40 years in the software industry, GeePaw’s solution is to develop a thick culture in which certain standards are established across the industry. They also discuss why the industrial model of work is so unsatisfying, the real reason why good workers leave organizations, and the importance of luck....
2020-03-0500 minPawCast with GeePaw HillReadability and Scannability | #35I distinguish quite strongly between "readability" and what I call "scannability". I think that our trade's pedagogues, even our very good ones, conflate the two, and in so doing inaccurately describe programming and ineffectively prescribe remedies.
Maybe the way to approach the idea is through your experience of seeing. Humans -- most vertebrates, in fact -- rely heavily on "seeing". The fabric of our experience is richly visual. A large portion of our neocortex is given over to it. Its use as metaphor is ubiquitous.
(Age 12, I had an older uncle-figure, blind from birth, was...
2020-03-0308 minPawCast with GeePaw HillMy Direction Forward | #34Here's a thing that happens: "We tried your advice by not trying your advice except partly where we did what we want but gave it your labels and it didn't work and therefore you are wrong."
Now, if you've given that advice for many years, and followed it in your own endeavors, and you, your teams, and many others have succeeded with it, what are you to make of such a statement?
Well. Let's not hedge, the world has too much hedging, the truth is the first fifty times one experiences this one is likely...
2020-02-2804 minPawCast with GeePaw HillKontentment and Human Arcs | #33Aight. I been away from programming for a couple of months, but there was a reason I started talking the other day about the kontentment project: I’m wanting mucho change in it. For a talk I’m giving, I want the ability to draw human arcs, with the same ease with which I can draw human lines. So I set out today to get that in. Human straight lines start with a line segment AB. Pick two random locations on that line, so we got 4 points. Now jiggle all four points a little — that’s official terminology — and make them...
2020-02-2508 minPawCast with GeePaw HillFrames In The Software Trade: An Example | #32We've talked about frames adding up to worldviews adding up to cultures, but it all feels pretty vague in its possible importance. We need some informal sense of how this works in practice. In the immortal words of Brian Marick, "an example would be handy right about now." Continuous Integration (CI) is the practice of frequently cycling code through the source vault. People practicing CI do this several times a day. In "git" terms, they both pull/merge/push, depending on language & task, once every 15-90 minutes.
Episode 32 is live! If you are interested in becoming a...
2020-02-2107 minPawCast with GeePaw HillThe Kontentment Project | #31If you look at my videos, like the "Lump Of Coding Fallacy" for instance, they are basically two-layered. At the back, you got me as a talking head. In front, you got text, lines, and images. Stuff fades in and fades out, and the lines, in particular, "draw" as I blah-blah-blah. It's almost as if I were talking while sitting behind a large glass pane that was being drawn upon in bright very "human-ish" ways. Essentially, every video is a composite of two video sources, a transparent (color keyed as we say) one atop an opaque one. kontentment is...
2020-02-1806 minPawCast with GeePaw HillThe Cost of Changing Microtests | #30Here's one: a respondent says, "If I write a lot of small tests and I change how a feature works, I have to change or throw out all those microtests, which is a lot of work." (The respondent proposed an answer for this problem, and it's not a bad one, but raises some other questions we might get to later.) The one-liner response: "For me, it's *significantly* less work to do that than to work in any other way I've tried to date." I'm not gonna stop with the one-liner, cuz this is actually pretty important and we need...
2020-02-1408 minPawCast with GeePaw HillHow I Work (Test-Driving Mix) | #29A decade ago I coined the term "microtest" for the kind of tests I write (or 95% of them). I found it easier to give people a new word than to try to parse the wildly variable meaning of any of the old words then in play, or even more inefficiently, argue definitions. I still do. A microtest is a short, precise, descriptive, fast, grok-at-a-glance, executable and persistent demonstration that what I said is what the computer heard is what I meant.
Episode 29 is live! If you are interested in becoming a part of the conversation, Click here...
2020-02-1111 minPawCast with GeePaw HillDiscipline: A Short Rant | #28People use the word "discipline" reasonably often when they talk about the software trade. I tend to avoid that word, and I wish more folks followed me in that policy. Most of those folks are not meaning anything untoward. They might easily use "orderly", "consistent", "persistent", "systematic", and so on, instead of "discipline", and as I say, I wish they would. "Discipline", in other parts of the forest, is an ordinary part of the vocabulary of extrinsic motivation by punishment that is a common element in command-and-control arrangements. "Discipline", in that part of the forest, is also used as...
2020-02-0703 minPawCast with GeePaw HillProgramming Interviews For Dummies | #27Before anything else, there's the series titles, and I'm going to make a joke: I always wanted to write "Low Self-Esteem For Dummies!" and see how many copies I could sell. There's a serious thought behind the joke. I don't like "...For Dummies", and I never buy one or recommend one. I am not a dummy. People who are asking for info aren't dummies. People who are learning to do a thing aren't dummies. People who ask dumb questions aren't dummies. When I was a kid, I asked one. A grownup said to Mom, "He sure asks a lot...
2020-02-0406 minPawCast with GeePaw HillWhen to Start TDD | #1First Episode of the GeePaw Podcast is now live! These episodes will be posted every Monday morning and will go hand-in-hand with either an old or new blog post on the website GeePawHill.Org. If you love it, sign up to the GeePaw Weekly newsletter to receive updates on all blogs and podcasts straight to your inbox.
---
Send in a voice message: https://podcasters.spotify.com/pod/show/geepawhill/message
2019-10-2108 min
Developer On FireEpisode 346 | GeePaw Hill - How You Love It
Guest:
GeePaw Hill
@geepawhill
Full show notes are at https://developeronfire.com/podcast/episode-346-geepaw-hill-how-you-love-it
2018-06-1100 min
Agile for Humans with Ryan Ripley and Todd Miller61: Agile Musings with GeePaw HillGeePaw Hill (@GeePawHill) and Amitai Schleier (@schmonz) joined me (@RyanRipley) to discuss internal quality vs external quality, generating insights about software, and the dangers of dogma in agile software development.
[featured-image single_newwindow=”false”]GeePaw Hill[/featured-image]
is the internet moniker for Michael Hill. He is a professional software coach for agile teams. GeePaw blogs at geepawhill.org and is a must follow on Twitter. GeePaw is a proud grandfather of 9 and finds that to be his most important role yet.GeePaw
Amitai is a software development coach, speaker, legacy code wrestler, non-award-winning musician...
2017-04-101h 01