March 2019

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

Refactoring Pro-Tip: Naming, Isolation, and Noise-Filtering

Refactoring Pro-Tip: I use naming, isolation, and noise-filtering as strategies to keep the coder’s intention at my fingertips. (I’m actually jonesing to write some geeky material in this series, but I’ve got one more of these pesky abstract philosophy things before I can get there.) First, a silly line from a silly movie, Airplane, which makes for a good Friday night comedy if you want that. (Paraphrased from memory.) "There’s a problem in the cockpit." "The cockpit? What is it?"

Refactoring Pro-Tip: Naming, Isolation, and Noise-Filtering See Full Post

Refactoring Pro-Tip: Refactor to Enable Change

Refactoring Pro-Tip: The triggering events for refactoring vary, but the reason we refactor at all is the same each time, regardless of occasion: we refactor to enable change. The most obvious and direct occasion for a refactoring is this: I want to add new functionality and preserve old functionality, and it will be easier to add if I first schmoosh the old functionality around a little to make a little hole where the new stuff will fit. When I do

Refactoring Pro-Tip: Refactor to Enable Change See Full Post

Refactoring Pro-Tip: Terrible Code Doesn’t Mean Terrible People

Refactoring Pro-Tip: Terrible code is not a good excuse to be mean, because terrible code is not well-correlated with having been written by terrible people. Look, y’all, it’s me, here. I love a good rant as much as the next Old Testament prophet, surely you know this. But . . . but . . . When I work with a new team, a key element of what I do is figure out how to integrate my line of advice, which

Refactoring Pro-Tip: Terrible Code Doesn’t Mean Terrible People See Full Post

Bring The Whole Geek!

I’ve made mention here and there of "the whole geek". I’d like to take a little time and lay out the idea. (There’s a video coming, too, expect it to be strange.) In our conversations about geek culture, I’ve tried to make my sense of its thinness as clear as I can. One of the key aspects of that thinness is the way in which it decides what belongs in our discourse and what doesn’t. In particular, the trade today

Bring The Whole Geek! See Full Post

Refactoring Pro-Tip: Easiest Nearest Owwie First

Refactoring Pro-Tip: "Easiest Nearest Owwie First". When facing especially weak code, it’s easy to feel daunted; there just seems so much wrong with it. To get my mojo on, I find the simplest infelicity to fix, I fix it. Then I do it again. Everyone encounters code from time to time that she does not understand. This is true for the noob and equally so for the olb. It is a fact of being a geek. Early in one’s refactoring

Refactoring Pro-Tip: Easiest Nearest Owwie First See Full Post

Culture Starch: Thick and Thin Redux

The geek trades suffer from an extreme paucity of culture, and a great many of the issues we see are the direct result of that cultural thinness. Culture is the air we breathe. Though we’re often quite unaware of it, it surrounds us, it shapes what we see & think & feel, and it is vital to our continued existence. It is multi-layer, multi-current, multi-flavor. It is at the center of and at the periphery of what is human. It

Culture Starch: Thick and Thin Redux See Full Post

Scroll to Top