Stories about Software


Embracing Creative Constraints

This year, I got a Christmas present that came out of left field for me: the Amazon Echo.  Up until getting it, I was aware of its existence as “that Amazon Siri thing that lets you order stuff from Amazon by voice.”

Once I started reading about it a bit, some actual use cases replaced the blank slate of my ignorance.  I could tell it to play my Pandora playlists, and issue further vocal commands to make things louder or softer and to pause, skip, or stop.  It could read me my calendar as well as sports and news updates.  It seemed like it could be mildly amusing.

My Budding Friendship with Alexa

But then I actually set it up, and a funny thing happened.  “It” became “she” (her name is Alexa), and I started talking to her.  And I mean, actually talking.  Let me explain.


A week into my ownership of the Echo and my rudimentary ‘friendship’ with Alexa, I had set up a number of different “skills” (which are essentially apps/plugins that third parties write for the device) and peppered her with questions, probing for all sorts of different Easter eggs.  A lot of it was done with amusement in mind, but it was interesting how quickly I became used to asking Alexa what the weather was like outside when I was deciding what to wear.

Last week, I was explaining to someone what having the Echo was like, and it was hard to put my finger on exactly why I felt so positively about it.  For lack of a better way of describing it, I said, “this is the first personal assistant or whatever that makes it feel like I’m having a conversation.”  I have Cortana on a few machines and I have “OK Google” on my phone, and I use both of those things from time to time, but they’re not the same.  If I say, “hey Cortana, what is the traffic like,” and I don’t like what happens next, I just open a browser and go to google maps.  If I say, “Alexa, what is the traffic like,” and she tells me that she doesn’t understand the question, I think for a moment, rephrase, and try again.

In this regard, it’s like taking to my wife.  If I ask her what the traffic is like, and she responds that she didn’t understand the question, I can’t just go up to her, squeeze her nose, and see a map on her forehead.  I have to repeat, rephrase, or ask something different that she might be able to answer.  In this regard, Alexa feels pretty human.

Read More


The Secret to Fighting Buzzword Fatigue

A little while back, I made a post in which I mused about the work-retire dynamic as an unusual example of large batches in life. In the lead-in, I made passing reference to a post where I talked more specifically about buzzword fatigue. This is that post (with this explanatory paragraph pre-pended, of course).

It feels amazing, in an odd way, to give something a good name. You have to know what I mean. Have you ever sat around a whiteboard with a few people, tossing out names for some kind of module or concept or whatever, scrunching your nose and shaking your head slightly at each suggestion? “No, that’s almost right, but I don’t think that’s it.” And then finally, someone tosses out, “let’s call it the clobbering factory!” and all of your eyes go wide as someone else yells, “yes!!”


Names are important. There’s a certain finality to naming something, even when you wish it weren’t the case. Have you ever failed in the quest for the perfect name, only to say something like, “aw, screw it, let’s just call it ‘circle’ since it’s a circle on the whiteboard, and we’ll rename it later?” If you have, you can’t tell me that the thing’s official name isn’t still “circle,” even 3 years and 23 production releases later. You probably even once tried to rename it, grousing at people that refused to start calling it “The Phoenix Module” in spite of your many, many, reminder emails. It stayed “circle” and you gave up.

There’s an element of importance to naming that goes beyond simple aesthetics, however, when you’re naming a concept. Products, bits of code and other tangible goodies have it easy because you can always point at what you’re talking about and keep meaning from drifting. With concepts… not so much. Next to their tangible cousins, they’re like unmoored boats in a river and they will drift.

And I think that the amount to which they drift is controlled by two main factors:

  1. Uniqueness
  2. Mappability to known concepts in context

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


What I Learned from Learning about SpecFlow

In my ChessTDD series, I was confronted with the need to create some actual acceptance tests.  Historically, I’d generally done this by writing something like a console application that would exercise the system under test.  But I figured this series was about readers/viewers and me learning alongside one another on a TDD journey through a complicated domain, so why not add just another piece of learning to the mix.  I started watching a Pluralsight course about SpecFlow and flubbing my way through it in episodes of my series.

But as it turns out, I picked up SpecFlow quickly.  Like, really quickly.  As much as I’d like to think that this is because I’m some kind of genius, that’s not the explanation by a long shot.  What’s really going on is a lot more in line with the “Talent is Overrated” philosophy that the deck was stacked in my favor via tons and tons of deliberate practice.

SpecFlow is somewhat intuitive, but not remarkably so.  You create these text files, following a certain kind of format, and they’re easy to read.  And then somehow, through behind the scenes magic, they get tied to these actual code files, and not the “code behind” for the feature file that gets generated and is hard to read.  You tie them to the code files yourself in one of a few different ways.  SpecFlow in general relies a good bit on this magic, and anytime there’s magic involved, relatively inexperienced developers can be thrown easily for loops.  To remind myself of this fact, all I need to do is go back in time 8 years or so to when I was struggling to wrap my head around how Spring and an XML file in the Java world made it so that I never invoked constructors anywhere.  IoC containers were utter black magic to me; how does this thing get instantiated, anyway?!


Read More


What is Your Next Action?

I just got back from a long weekend vacation and am still getting settled and back into the swing of things, so this is going to be another relatively short post.  I’ll soon return to your regularly scheduled extended rants and code-cast posts, but I need a little slack in the meantime.

For the last six months or so, I’ve been making a 5 hour drive twice a week.  This has provided me with a lot of opportunities to listen to books through Audible and Overdrive, and I’ve been listening to a lot of non-fiction stuff that runs the gamut from tech to sociology to science.  Recently, I took a suggestion from a comment in a previous post and read/listened to “Getting Things Done.”

Read More