So, for those following along, the other day I had to decide whether to roll my own parser for boolean expressions involving tags, like "(stinky & doofus) | (ugly)". Very standard stuff. In the end, I rolled my own, and I have to tell you, I just had a really wonderful time. A parser for […]
Parsing Expressions, TDD, and the Big Why Read More »
So, in recent muses, i’ve tried to establish that our next step is a) restructuring economy to b) grow & keep geeks. How? What changes do I make in my org, assuming that I have restructured the economy to give me space to do so, to increase the org’s ability to grow and keep geeks?
How to Grow and Keep Geeks Read More »
From yesterday’s dark muse, this: i need stronger geeks. But I can't *get* stronger geeks without attending first and foremost to *growing* them and *keeping* them. — Michael D. Hill (@GeePawHill) August 12, 2018 #### Let’s go there. I believe we are consistently failing in the geek trade. By failing, I mean that we who
Growing and Keeping Geeks Read More »
It seems to me that a very great deal of "agile" advice has an implicit prefix, "assuming your team is close to healthy," you should … The assumption of reasonable health just — to put it as gently as I can manage — doesn’t seem like the sort of assumption we should be making. The
Restructuring the Debts In The Geek Trade Read More »
Coaches, let’s talk about fear and — not the team — fear and the coach. I get to meet and speak with a lot of coaches, which pleases me. Because i’m an introvert with a taste for authenticity, I am also lucky enough to quite often get them in small groups or one-on-one where folks
Fear, Coaches, and the Will To Fail Read More »
Yesterday’s irritated blurt was a matter of feels, not an attempt to offer insight or ideas. I got some queries about it, so let me wipe that slate and be a little less irritated. For now, anyway. 🙂 In geekery — in all tool use beyond a certain point, but my focus here is on
Decomposition Rage Tweet Explained Read More »
Let’s talk a little bit about showing your working code to your product person. A basic recommendation, which will seem strange and likely freak you out the first time you hear it. Look to show your new stuff every day or two. I want to address here both the how and the why. The why
Showing Code Every Day Or Two Read More »
If we’re living now and always have been in the Age of Blurgs, then our strategy might change accordingly. Before I go to some ideas from the modern we got "The Age of Blurgs", and we got "Blurgs: Try Harder Won’t Work". We need some better ideas, and the modern synthesis has some. Today I
How The Modern Synthesis Tackles Blurgs Read More »
If we’re living now and always have been in the Age of Blurgs, then our strategy might change accordingly. Before I go to some ideas from the modern synthesis that are targeted at blurgs & blurging, tho, I want to point at one thing that won’t work, and why. What won’t work is "try harder",
Blurgs: Try Harder Won’t Work Read More »
Let’s define blurgs. A ‘blurg’ is an event where a programmer understanding of "what my code does" is not "what my code does". Blurgs are an everyday part of programming, of course. We are more often "interim" than at a sign-off point. But I mean to restrict for this conversation the idea of a blurg
