Change Pro-Tip: All The Knobs A Little, All The Knobs A Little

Change Pro-Tip: All the knobs a little, all the knobs a little, over and over again, is how I’ve make my most successful changes, in code and organizations alike. A while back, I mused first about "Always Small, Always Improve" and I later elaborated "Always Small, Always Better, Always Wrong". Lo these two decades ago, we characterized eXtreme Programming as turning all the knobs to 11. I’ve always loved that metaphor, and I still believe in it. But my strategy […]

Change Pro-Tip: All The Knobs A Little, All The Knobs A Little See Full Post

Geekery Pro-Tip: Think Less, Sense More

Geekery Pro-Tip: I frequently remind myself: Think Less, Sense More. It’s advice I give to me all over the place, from the most technical parts of the sociotechnical fractal to the most social parts of it. It’s an odd thing to say, so we better dig in to it a little. I’ve recently come from a conference. This was a good one for me, full of old friends and new, smart crazy passionate people coming together to figure out what

Geekery Pro-Tip: Think Less, Sense More See Full Post

TDD Pro-Tip: Design Until Nervous Optimism

TDD Pro-Tip: Before I write the first test in a new context, I usually design until I get to a state of "Nervous Optimism". A couple of days ago, I was party to some drinking geekery with my colleagues at a hookah bar restaurant dance club. It was the end of a long day, and we were unwinding and being pretty silly. My three partners in crime mobbed on "Evil Hangman", a fun little game. And I sat off to

TDD Pro-Tip: Design Until Nervous Optimism See Full Post

Culture Starch: We Haven’t Grasped Complexity Yet

Sitting here, listenin’ to my playlist, thinking about temporality and how it relates to the kind of geekery I want to write and talk and teach and geek about. Over the last 10 years or so, the topics deriving from systems theory, from complexity theory, and so on, have wormed their way slowly into our mental frame. Just a little, just a little, but that’s how change works. And as I read the popular accounts, as well as the folk-theory

Culture Starch: We Haven’t Grasped Complexity Yet See Full Post

Plenty Of Guilt To Go Around

Who’s to blame? I notice how many folks seem to believe geeks are in charge of what software gets written in the world. When software is revealed to be immoral, I notice how reluctant they are to blame folks who are senior executives, boardmembers, or majority shareholders. The majority of working software developers who are adding code to projects are < 30yo. An actual current programmer is uncommon on the third floor and almost unheard of above that level. I

Plenty Of Guilt To Go Around See Full Post

TDD Pro-Tip: Stay Aware Of Testing Data

TDD Pro-Tip: I stay very aware of my testing context’s data, and specifically of what data is opaque and what data is transparent. Those terms, transparent and opaque, need a little explanation. Sometimes the code I’m testing doesn’t vary based on the entirety of its input. A trivial example, the function that validates the date of an order DOES NOT CARE what any other field in that order is or does. It only cares about the date field. I would

TDD Pro-Tip: Stay Aware Of Testing Data See Full Post

Refactoring Pro-Tip: Scanning Isn’t Just Fast Reading

Refactoring Pro-Tip: When I’m scanning, I’m not just reading fast, I’m feature-detecting, something the unconscious part of me is very good at doing, especially when the code helps. Part of the made, the making, and the maker as a guiding theme for me is the idea of "leaning in" to the strengths of my maker body and "leaning out" from its weaknesses. A trivial case: one reason TDD works so well for me is that the microtests give me a

Refactoring Pro-Tip: Scanning Isn’t Just Fast Reading See Full Post

Refactoring Pro-Tip: I Optimize Scannability, Then Readability, Then Writability

Refactoring Pro-Tip: I optimize my code for scannability, readability, and writeability in that order. I won’t argue my case in detail, there’s a video if you’d rather watch me make it instead of reading it, and I’ll just sketch the case briefly here in the muse. http://geepawhill.org/optimizing-a-program-and-programming/ When I’m coding, I notice that I spend significantly more time scanning the code than I do reading it, and significantly more time reading the code than I do writing it. So when

Refactoring Pro-Tip: I Optimize Scannability, Then Readability, Then Writability See Full Post

The Whole Geek: Geekery Is Just The Tip Of The Iceberg

A thing that happens to me a lot. I want to say, "Yeah, that’s not how that works," about some over-simple explanation, usually something around using inorganic reasoning about humans. But when I go there, I know we’re gonna go instantly to vast areas of study & insight that most folks aren’t comfortable with. And it’s exhausting, and I’ve limited energy. They see the exchange — they see all of human discourse as far as I can make out —

The Whole Geek: Geekery Is Just The Tip Of The Iceberg See Full Post

Refactoring Pro-Tip: Making Local Variables Maximally Local

Refactoring Pro-Tip: When I tackle a long method, the first thing I do is make my local variables maximally local. Consider this psuedo-code. It’s basic stuff, I’m betting virtually any geek can read it, but if not, lemme know. longMethod( int y ) { int x; x = 0; // … // IRRELEVANCY #0: 87 lines that neither read nor write x // … if( y == 17 ) { x = 1; } // … // IRRELEVANCY #1: 87

Refactoring Pro-Tip: Making Local Variables Maximally Local See Full Post

Scroll to Top