Stories about Software


Modularity on My Honeymoon

If you hadn’t noticed, I’ve been gone for the last couple of weeks.  I got married and went on a honeymoon and left the blog on auto-pilot, with scheduled cross posts of things I’d written for other blogs.  I figured this was better than providing no content and hopefully the posts and social media announcements synced up closely enough that I didn’t look ridiculous.

During the trip, I didn’t think a whole lot about software, per se, but I gave occasional thought to what I might say upon my return.  I think really good bloggers make cool segues out of trips and experiences.  You know, like  “I was gazing up at the Eiffel Tower and I couldn’t help but think of Liskov’s Substitution Principle.”  I’m not that good, so I didn’t come up with anything like that.  I was in France and Monte Carlo, and I ate a lot of cheese, saw a lot of sites, drank a lot of wine and spent a lot of time reading.  None of that reminded me of code or software, really.

An Idiot (Me) Abroad

In fact, the only technical lessons I could relate were birthed from my own stupidity.  I brought my Mac Book pro along, but, incredibly, managed to forget its charger.  Upon arrival at our hotel in Paris, jet lagged, I dug the laptop out of the bag to charge and discovered that this would be quite impossible.  Suddenly, the Mac’s 90% charge was an ominous harbinger of computing scarcity.  I’d have to ration, what, like 3 or 4 hours of latpop usage for the entire trip? Read More


Code Kata? How About Product Kata?

When I was a kid, I spent a bunch of years doing karate. As best I can recall, there were three main types of activities around which we’d focus: kihon, kata, and kumite. I listed these roughly in order of sophistication. Kihon translates to something like “basics” and it involved executing the same punches, blocks, or kicks repeatedly, going for correct technique. Kata was something like “form” and this involved stringing together moves into more complex sequences and practicing those, presumably to emphasize rote practice of sequential movements. Kumite was sparring, and this was meant to be in-situ, improvisational practice, using the first two activities as building blocks.

There’s a lot of spiritual type stuff that goes on around martial arts, and it’s not my intention to rag on that in any way. You get out of things what you put into them and you find value that makes sense to you. But, at its core, these activities are really all about learning how to punch and kick other people and win fights. So you practice the basics, string those together into sequential movements and then have dress rehearsal sparring matches. This is all done so that when the time comes to actually punch and kick people in real life, you’re good at it. You don’t flinch when someone throws a punch because your countless hours of practice have made stepping into the blow, deflecting it and countering as second nature to you as cringing and protecting the head are for most people.

Learning to Punch People with Our Code

When I first heard of the martial arts concept of “kata” being applied to software development, I found it sort of interesting and weird. There’s intense marketing power in appropriation of this nature, and it can really make a concept take off. And, there are parallels between the two beyond the simple notion that deliberate practice improves technique. One of the main benefits to code katas is the practice of techniques like refactoring, TDD, etc. when the pressure is off. When in coaching/mentoring roles, it’s pretty common to see people try new techniques, only to abandon them when delivery pressure is perceived. To have “stickiness” for a software development technique, it’s essential that it hit a tipping point where the practitioner finds it less efficient to skip it than to do it. And doing a lot of code katas is a way to work toward that tipping point.


Of course, as with any cross-disciplinary metaphor, there are gaps and those gaps can be problematic. Again, putting aside the spiritual overtones, karate is about learning to punch and kick people effectively. This is pursuit heavy on instinct and muscle memory and relatively light on cerebral cortex activity. A fight also spans seconds or, at most, minutes, where programming is a pursuit of hours, days, weeks, months, or years. I believe it was this sort of information gap that led John Sonmez to post about code katas. He heard the term “code kata” and mapped the martial art version onto it — one where you practice precisely executing the exact same movements until you can do them in your sleep. That’s not the intent of the code kata, but recall that we’ve been over what happens when you recycle terms with baggage for marketing purposes.

Read More


Delegating is Not Just for Managers

I remember most the tiredness that would come and stick around through the next day. After late nights where the effort had been successful, the tiredness was kind of a companion that had accompanied me through battle. After late nights of futility, it was a taunting adversary that wouldn’t go away. But whatever came, there was always tiredness.

I have a personality quirk that probably explains whatever success I’ve enjoyed as well as my frequent tiredness. I am a relentless DIY-er and inveterate tinkerer. In my life I’ve figured out and become serviceable at things ranging from home improvement to cooking to technology. This relentless quest toward complete understanding back to first principles has given me a lot of knowledge, practice, and drive; staying up late re-assembling a garbage disposal when others might have called a handyman is the sort of behavior that’s helped me advance myself and my career. On a long timeline, I’ll figure the problem out, whatever it is, out of a stubborn refusal to be defeated and/or a desire to know and understand more.


And so, throughout my career, I’ve labored on things long after I should have gone to bed. I’ve gotten 3 hours of sleep because I refused to go to bed before hacking some Linux driver to work with a wireless networking USB dongle that I had. I’ve stayed up late doing passion projects, tracking down bugs, and everything in between. And wheels, oh, how I’ve re-invented them. It’s not so much that I suffered from “Not Invented Here” syndrome, but that I wanted the practice, satisfaction, and knowledge that accompanied doing it myself. I did these things for the same reason that I learned to cook or fix things around the house: I could pay someone else, but why do that when I’m sure I could figure it out myself?

Read More


Are You Changing the Rules of the Road?

Happy Friday, all.  A while back, I announced some changes to the blog, including a partnership with Infragistics, who sponsors me.  Part of my arrangement with them and with a few other outfits (stay tuned for those announcements) is that I now write blog posts for them.  Between writing posts for this blog, writing posts for those blogs, and now writing a book, I’m doing a lot of writing.  So instead of writing Friday’s post late Thursday evening, I’m going to do some work on my book instead and link you to one of my Infragistics posts.

The title is, “Are You Changing the Rules of the Road?”  Please go check it out.  Because they didn’t initially have my headshot and bio, it’s posted under the account “DevToolsGuy,” but it’s clearly me, right down to one of Amanda’s signature drawings there in the post.  I may do this here and there going forward to free up a bit of my time to work on the book.  But wherever the posts reside, they’re still me, and they’re still me writing for the same audience that I always do.






What Story Does Your Code Tell?

I’ve found that as the timeline of my life becomes longer, my capacity for surprise at my situation diminishes. And so my recent combination of types of work and engagements, rather than being strange in any way to me, is simply ammo for genuineness when I offer up the cliche, “variety is the spice of life.” Of late, I’ve been reviewing a lot of code in a coaching capacity as well as creating and giving workshops on story telling and creative writing. And given how much practice I’ve had over the last several years at multi-purposing my work, I’m quite vigilant for opportunities to merge story-telling and software advice. This post is one such opportunity, if a small one.

A little under a year ago, I offered up a post in which I suggested some visualization mnemonics to help make important software design principles more memorable. It was a relatively popular post, so I assume that people found it helpful. And the reason, I believe, that people found it helpful is that stories engage your brain far more than simple conveyance of information. When you read a white-paper explaining the Law of Demeter, the part of your brain that processes natural language activates and decodes the words. But when I tell you a story about a customer in a convenience store removing his pants to pay for a soda, your brain processes this text as if it were experiencing the event. Stories really engage the brain.

One of the most difficult aspects of writing code is to find ways to build abstraction and make your code readable so that others (or you, months later) can read the code as easily as prose. The idea is that code is read far more often than written or modified, so readability is important. But it isn’t just that the code should be readable — it should be understandable and, in some way, even memorable. Usually, understandability is achieved through simplicity and crisp, clear abstractions. Memorability, if achieved at all, is usually created via Principle of Least Surprise. It’s a cheat — your code is memorable not because it captivates the reader, but because the reader knows that mapping what she’s used to will probably work. (Of course, I recognize that atrocious code will be memorable in the vivid, conversational sense, but I’m talking about it being memorable in terms of its function and exact behavior).

It’s therefore worth asking what story your code is telling. Look at this code. What story is it telling?

Read More