Listening to your code does not mean conducting a seance
I love having tricky conversations on Twitter. I know a lot of you don’t, because you can’t express yourself clearly in 140 characters or less, but I love it for precisely that reason. The constraint makes it easy to voice objections, which makes assumptions visible and encourages us to challenge them. You’d be amazed at the things that people object to – issues that you thought were settled a long time ago, which you take for granted, at least within certain of your social circles.
This Twitter conversation reminded me of one of my own, long-standing assumptions… the one upon which I based the name of this website.
@ecomba @jbrains The more I hear this notion expressed in summary, the harder it is for me to keep liking it.— Tracy Harms (@kaleidic) June 27, 2013
You owe it to yourself to read the entire conversation, so click on the Tweet’s timestamp and read further. Allow me to summarize: Letting your code tell you where it wants to go does not mean conducting a seance, speaking to the dead.
In case that conversation link has long-since died, let me state very clearly that when I write code, it might look like I use a Ouija board, except that I know that I’m controlling it. I’m looking for signals in my code to indicate design problems, then I decide which problems to address right now, then decide what to do about them. Some signals hit me more strongly than others. Over time I have developed an awareness of and a sensitivity to an ever-growing number of different signals that indicate potential design problems.
I just find it more fun to say that my code tells me where it wants to go. Please don’t interpret this too literally.