Sooooooo. I’m gonna write a little bit about geekery. But I do want to frame it for you a little. Geekery is not very important right now. My country is in the throes of facing down a violent uprising by uniformed militia, spurred on by parts of the government. So, geekery, no. Not important. But, to me, and to many of my followers, thinking and talking about geekery is a kind of comfort food. Comfort doesn’t eliminate problems. But the […]
The 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
Microtest TDD: Economics See Full Post
I 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. There are a lot of arguments that sound like they’re either neutral to or in favor of this behavior. They are wrong, in detail, in logic, and in toto. Let’s take a look.
Hitting on Speakers (Rant-y) See Full Post
I 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,
Microtest TDD: The Big Picture See Full Post
More 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
The Jump to Microservices See Full Post
I 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 are spikes? 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
An Intro to Spikes See Full Post
Let’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
Steps, Value, and Change-Harvesting See Full Post
Lotta 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
Juniors And Seniors See Full Post
The 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
Using the Strategy Pattern See Full Post
Another 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
Dealing with Nulls See Full Post
