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? In no particular order, then, here are a bunch of ideas about this. 1: Stop hiring people whose chief attribute is their capacious memory for […]
How to Grow and Keep Geeks See Full Post
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 do the work do not broadly satisfy those for whom we do it. If we were selling some service or commodity that could be substituted
Growing and Keeping Geeks See Full Post
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 industry — agile & otherwise — is in terrible shape. The demand for geekery seems to rise year after year, and it brings with it
Restructuring the Debts In The Geek Trade See Full Post
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 stop marketing and start sharing. For years, i’ve noticed that a great many of them live daily with the belief that they are not good
Fear, Coaches, and the Will To Fail See Full Post
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 the modern software development synthesis — we confront problems that have a size that is "too big to eat all at once". This is hardly
Decomposition Rage Tweet Explained See Full Post
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 has three parts: 1) just-in-time tuning, 2) food-pellets. 3) cross-specialty connection. Just-in-time tuning is just feedback. But I used an odd word, as i’m wont
Showing Code Every Day Or Two See Full Post
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 want to focus tightly on "just the coding". Coding’s not all the work doing software for money requires, not even most of it at the
How The Modern Synthesis Tackles Blurgs See Full Post
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", and why it won’t work is "because humans". What I mean about just trying harder not to blurg being ineffective as a plan: blurging is
Blurgs: Try Harder Won’t Work See Full Post
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 to being a programmer-program disconnect that occurs at a sign-off point. (a sign-off point is different for different teams. Most of the folks I work
The Age Of Blurgs See Full Post
I’ve said in a bunch of different ways how skeptical I am of method. In software-for-money, applying method — structure, process, technique, algorithm, recipe, formula — seems to me to be so rarely successful across contexts as to be, idunno, the great collapsed souffle of the entire geek trade. By the time our abstraction-level has gotten high enough to incorporate the successes we’ve seen, it is also so high as to incorporate many or most of the failures we’ve seen.
Skeptical About Method: Another Stab See Full Post
