justin․searls․co

Did you come to my blog looking for blog posts? Here they are, I guess. This is where I post traditional, long-form text that isn't primarily a link to someplace else, doesn't revolve around audiovisual media, and isn't published on any particular cadence. Just words about ideas and experiences.

What's Wrong With Ruby's Test Doubles

 Prologue First things first: let’s square up terminology. For the sake of facilitating sane discussion on this topic, I’ve adopted the terms used in Gerard Meszaros’ XUnitPatterns book. He drew a complex table for this, but I’ll quickly summarize here: Test Double — a generic term to describe an artifical stand-in for code (usually an object) upon which the subject code you’re specifying depends. Mocks, spies, stubs, fakes, etc. are all specific subtypes of test doubles.

And before you knew it…

The Power of Prompts

 This post is partly in response to to this tweet, and partly a follow-up to a teaser I tweeted earlier this week. We humans are suckers for suggestion. If you need evidence of this, consider something as seemingly innocuous as the order in which we ask people questions. If I were to ask you: 1. Does the following web site load properly in your browser? Make sure all the pictures load: cuteoverload.

You'll never guess what happens next…

Open source interviewing

 When someone applies to Pillar, we invite them to submit a code example that solves a particular problem. We review the code as an input early in the interview process. It’s a helpful component of getting acquainted with a candidate, but a few things aren’t ideal: For any toy project, the domain is going to be trivial enough that it isn’t likely to be very representative of a larger “real” project As I review more and more submissions which solve the same handful of problems, I’m finding it harder to evaluate each with a fresh set of eyes Ultimately, the code doesn’t have any utility—its lifecycle ends as soon as it has been reviewed and discussed.

Keep reading…

Succeeding with clients that don't want to change

 Hypothetical: you find what seems to be the perfect prospective client. You’ve collaborated to develop an idea with the potential to realize outstanding value. They’ve decided they trust you to capitalize on the opportunity and achieve that value via some new software system. *But!* But the prospect makes a point to tell you they don’t want to be trained or changed (and that you can forget about “transformed”). They compensate by emphasizing that their only objective is to produce that set of value-creating widgets the two of you dreamed up in the (much cozier, in hindsight) first paragraph.

Let's dive in and find out…

Rushing to Forget Clean Code

 Ron Jeffries just posted a terrific case for clean code, and decoupled a recently-emerged “code can be too clean” meme from a question that has actual merit, “can we spend too much time making code clean?” Upon discussing the post with Kevin Baribeau this evening, an anecdotal correlation was identified between folks who’ve said things akin to “code can be too clean” and folks who tend to succumb to the pressure to rush development of features.

Content warning: more content…

How I Write Java These Days

 Over the last year, I’ve made an effort to better identify the styles, idioms, and smells I encounter when reading and writing new Java code. [And, already, a takeaway point! To some of my more successfully sheltered rubyist friends, it may be sorry news to hear that there continues to be new Java code written.] In any case, I’ve made a concerted effort to internalize habits that I find valuable and to develop a reflex to resist those which I do not.

And then what happened?…

1
2
3
4