Get some stats

I’m doing a weekly micropodcast. It’s difficult to count listeners, but by a conservative accounting, as of this writing, there have been 2593 total downloads of 18 total episodes, for an average of 144 per episode. How do I know? My web server logs and this shell script:

#!/bin/sh

LOGFILES='logs/access logs/access-ssl'
LATEST_EPISODE=$(ls src/*.mp3 | sed -e 's|src/ai3m||' -e 's|\.mp3||' | sort -n | tail -1)
HTTP_STATUS_THAT_COUNTS=200
TOTAL_DOWNLOADS=0

main() {
        for i in $(jot ${LATEST_EPISODE} 1); do
                downloads=$(grep "GET /.*ai3m${i}\.mp3" ${LOGFILES} | grep " ${HTTP_STATUS_THAT_COUNTS} " | wc -l)
                downloads=$(echo $downloads)
                TOTAL_DOWNLOADS=$(expr ${TOTAL_DOWNLOADS} + ${downloads})
                echo "$i: $downloads"
        done

        echo "total: ${TOTAL_DOWNLOADS}"
        echo "average:" $(expr ${TOTAL_DOWNLOADS} / ${LATEST_EPISODE})
}

main "$@"

There are thousands more HTTP status 206es in the logs, which are excluded on the assumption that they represent partial downloads and shouldn’t count toward the total. If you can suggest how I might more accurately and/or standardly count podcast downloads without relying on external services, I’m interested.

Attract more listeners

One way I’ve been trying to expand my audience is by announcing each week’s episode via social media. As a heavy Twitter user, I’ve noticed that certain kinds of media — such as YouTube videos and animated GIFs — can be played directly within tweets, without needing to leave an app or click a link. I wanted Twitter to be presenting my podcast in this way, on the hypothesis that the easier it is to listen, the more folks will try listening.

Twitter calls this multimedia feature the Player Card, one of several types of “Cards”, and gives developers a way to implement it for their sites. As I was changing my episode template, I noticed a bug in the CMS’s expansion of some of the directives. For instance, when I gave ikiwiki this input:

[[!meta  name="twitter:card" content="player"]]

I expected it to generate this output, which is what Twitter would want:

<meta name="twitter:card" content="player" />

But it did this instead:

<meta name="twitter:cardcontent="player" />

Fix a bug

Ikiwiki has lots of tests, but I didn’t see any for the plugin that processes these directives. So I reviewed the docs and the code and wrote some tests (warning: Perl (warning: hey, I like Perl!)) for a bunch of the other variants of the meta directive — partly in case there were more bugs lurking, partly to make the neighborhood safer for future contributors, and mainly to avoid creating new bugs when I fixed mine. Between the time I’d invested in reading and exercising other code in the same plugin, the bug being pretty obvious to begin with, and tests that told me whether I was done yet, it was a quick fix.

Great success (?)

Now that my Player Card validates, when I (or anyone) tweets a new episode of Agile in 3 Minutes, some browsers and Twitter clients display a nice little widget for playing the audio. In Safari on OS X:

twitter-player-card.png

Give it a try. How’s it work? How’s it look? Bug reports gratefully accepted.

Posted Thu Aug 27 02:34:46 2015 Tags:

When I started recovering from perfectionism, I noticed I’d been trying to carry around an “effectively infinite” set of thoughts to make sure to think. Trying and failing, that is, and wasting cognitive energy in the attempt. When TDD began to poke through my thick skull, I observed the existence of at least one context in which I didn’t have to carry that inventory. Run the tests, know where I am; write a red test, know where I am; make it green, know where I am.

Being able to instantly know where I was obviated my need to think all the thoughts, at least during the act of writing code. I had become test-infected. It was a first step toward a better life.

Test-Driven Development, as opposed to test-first, means we drop the premise that we can be pretty sure where we’re going to end up, and replace it with the premise that we can be pretty sure we’ll figure out how to get there. We keep the part where we write tests before doing things. We drop the part where we write a whole bunch of tests before doing a whole bunch of things. Instead, we write one test, do one thing, and listen for hints about what needs to happen next.

Doing one thing at a time requires, as you might imagine, the ability to delay some gratification. I happen to think a frequent green bar more than makes up for it. Even so, patience can be hard to come by when my brain, without my invitation, has begun loading up the problem and throwing off sparks about what all might be important later. And when it occurs to me that some of those ideas might well be right, and I might not think of them again, it’s hard to let them go. Hence our first hack.

The Test List Trick

The goal of this hack is to:

  1. Quickly record those ideas somewhere I know they won’t get lost, and thereby
  2. Restore my brain to a patience-capable state.

Here’s the spec:

Feature: Test-drive efficiently while being a talented worrier

  Scenario: Initialize focused brain
    Given I'm working on code with tests
    And I'm trying to test-drive
    When my head is full of all the things to make sure to worry about
    Then empty it into a block comment in the tests

  Scenario: Maintain focused brain
    Given I'm test-driving
    When my head invents a new thing to worry about later
    Then append it to the block comment in the tests

  Scenario: Convert good ideas to tests
    Given I'm test-driving
    When the right thing to do next is one of my commented ideas
    Then convert the idea to a test

  Scenario: Discard leftovers
    Given I'm test-driving
    When we're green and there's nothing left to do
    And the block comment still has ideas in it
    Then delete the block comment before committing

The Red-Test Breadcrumb Trick

In case the rationale for the previous hack didn’t make it clear, I’m forgetful. (I had to go back and check that I wrote something that implies forgetfulness.) I’m also a recovering procrastinator, in addition to the perfectionist bit. Really just a lovely person with fine character traits. I confess these things because while context switches are known to be expensive for everyone, I’d be willing to bet they’re extra expensive for me. So I evolved another hack, which is only barely anything to do with TDD, but only works if — and might not even make sense until — test-driving is part of you.

The goal of this hack is to:

  1. Quickly, before I forget, record my next action somewhere I know I’ll find it, and thereby
  2. Restore my brain to its previous context when I return.

The spec:

Feature: Come back efficiently from a context switch

  Scenario: Save mental state
    Given I'm trying to test-drive
    And I can write simple tests very quickly
    When I need to step away for any reason
    Then first write a test that says fail("yo, do X next")

  Scenario: Restore mental state
    Given I'm trying to test-drive
    And I test-drive as a matter of course
    When I'm trying to remember what the hell was going on here
    Then run the tests and be reminded

  Scenario: Get rolling again
    Given I'm trying to test-drive
    When I have a failing test
    Then I'm on solid ground
    And I know exactly what to do next

Got hacks?

I rely on a whole bunch of tricks to be effective. I’m quite sure I’ve got more than two, and I’m quite sure I’m not the first to introduce these two to the world, but as I said, I’m forgetful. (Hey, this time I didn’t have to check!) When I remember some more of my survival tactics, I’ll write another post.

What do you do to arrange yourself to get the right things done right?

Posted Fri Aug 21 22:59:31 2015 Tags:

I have a problem

I’m a perfectionist. For any given task, in the absence of evidence to the contrary — and sometimes despite the presence of said evidence — I’ll often feel the need to perform it no less than very well, and preferably superlatively.

I say “often” and not “always” because I’m a recovering perfectionist. Before my recovery began, when I could stand to feel how I felt, I’d be disappointed with my behavior, the way my life seemed to be going, and my seeming lack of agency about any of it. I’d wonder how much of my disappointment stemmed from the selfsame perfectionist judgment I was disappointed with. I’d wonder whether I’d ever have the option to think without always going in circles. I’d wonder whether I’d ever stop criticizing myself for how I criticized myself. I’d wonder about circles again, and try to stop.

I had an insight

With my brain throwing off so much waste heat, concentrating was difficult. I dropped out of college and got my first job, where I discovered the brilliantly clarifying experience of being very slightly useful to others. It became my organizing principle, my yardstick. Am I being at all useful? How can I be making myself more useful?

I’m also a procrastinator, probably because I’m a perfectionist, and vice versa, and so on. To make myself maximally more useful, the most useful change I could’ve made would’ve been to procrastinate less. But I had not, as yet, hit upon a self-engineering trick to that end.

I’ve got some tricks now

The To-Do List Trick, for example, has four steps:

  1. Write down a bunch of possible tasks.
  2. Pick the most important task, the easiest one, and one more.
  3. Put the easiest task first.
  4. Don’t worry about the order of the other two.

Step 1 eases my fear of spending precious productive minutes on the wrong thing. Step 2 limits today’s scope to tasks that I can expect to complete and are worth completing. Step 3 helps me spend less time not starting, and leaves me with much-needed momentum.

You might think Step 4 looks like a microoptimization. It’s not. It’s weirdly important.

When I get to the second task, I sometimes exercise the option to defer it until after the third one. Leaving myself that choice lets me indulge my procrastinatory tendencies when I really want to, so I can spend less cognitive energy on controlling myself. Knowing that I’ll be procrastinating productively, I also don’t spend energy second-guessing my choice to procrastinate. Since I start sooner and throw off less waste heat, I find myself getting more done, so I feel better about myself, so I keep getting more done.

That’s why I mustn’t worry about the order of the second and third to-dos. If I’d put any thought whatsoever into the ordering, then I either feel less free to reorder, or I reorder anyway despite knowing I’m going to second-guess. Either way, I find myself getting less done, so I feel worse about myself, so I keep getting less done. I feel a tinge of annoyance and fatigue just putting this vicious spiral into words. To favor the virtuous spiral, Step 4 is crucial.

I’m in recovery

I still think in circles sometimes, but much less often, and mostly in ways that serve me, so it bothers me less. I still seek perfection more often than I and others need, and I still get off to slow starts more often than I and others want, but much less more often than I used to. I’ve got a small bag of tricks for exerting greater agency over my behavior. I try not to let any fall out. Occasionally I pick up a new one.

The very first trick I found, the one that started my recovery, was Test-Driven Development.

TDD saved my brain

For any given problem, I never quite totally believe I’ll be able to solve it. If I start at a whiteboard, I have to think, so I have to be smart, and I’m not sure when I’ll be done thinking, so it’s really hard to start. Instead, I make a to-do list: an even simpler one, with a single dumb-as-rocks failing test that points vaguely in a direction of some sort, possibly the wrong one, who knows. I don’t have to be smart to make it pass, so I can just do it, so I do do it. This helps me spend less time not starting, and leaves me with much-needed momentum.

Because I know I won’t have to be smart later to remember to test that thing again, I don’t spend cognitive energy second-guessing each code change. And because I generally don’t have to be smart all the time, I can afford to spend cognitive energy to load a subproblem into my head, and make careful decisions and meta-decisions about it, when I really need to.

Since I start sooner and throw off less waste heat, I find myself getting more done, so I feel better about myself, so I keep getting more done. Recognize the pattern? This is where I discovered it.

TDD not only helps me sidestep procrastination, it helps me directly address perfectionism. By overriding my default vague, implicit self-expectations with specific, explicit system expectations, TDD reduces my brain’s WIP from “effectively infinite” to “approximately 1”. Test-driving provides a bounded context in which my code frequently is perfect: when green, it’s perfect at doing everything it’s ever been asked to do. And the tests that accumulate inhibit the growth of new imperfections. With TDD, I trust myself later, so I can confidently stop sooner.

Conclusion

I will always be a procrastinator and perfectionist. The thinking behind TDD started me on the path to getting better, in software development and in life. I’ve acquired enough support, tools, and habits to do timely and effective work.

Still, I can always improve. And sometimes there’s no more perfect way to procrastinate than to seek self-improvement.

Posted Fri Aug 14 22:28:20 2015 Tags:

Feel sorry for me

It’s been a tough week to keep up with Twitter.

Okay, don’t

I realize this claim, as stated, may not arouse your sympathies. Most folks don’t care about Twitter; of those who do, most probably don’t feel any obligation to keep up with their timeline; of those who do, most probably see themselves somewhere along a continuum describing how frequently they take sips from the firehose. I admire those people. When I say “keep up”, I mean sealing my mouth around the firehose so that the whole of the flow (at the time of writing, 992 people) goes through me.

Being a fairly fast reader is a prerequisite. Still, the firehose is always faster. When I’ve caught up recently and am not very far behind, I tend to evaluate each new tweet with more attention; if I’m hours behind, I have to do a lot more skimming. Either way, when I see links to papers, articles, blog posts, and the like, I mostly save them for later.

Psychological self-trickery

Save-for-later is among the most effective self-manipulation hacks I’ve yet found. I want to feel like I’ve read everything I need to have read. If I can barely keep up with tweets, then I definitely can’t keep up with all the follow-up reading material they link to. When I save an article for later, that almost always means I’ll never see it again. But occasionally (mostly on planes) I do leaf through my read-it-later pile. And when I encounter a situation in which I vaguely recall having saved material that might be helpful, lo and behold, Past Me has made it easy for Present Me. All told, “save-for-later” lets me feel like I’ve read everything I need to have read right now, because I’ve taken action to minimize my unawareness of things I might need to read in the future. Evidently I suffer from a kind of time-shifted FOMO for knowledge.

Keeping up with Twitter this week might have been a bit easier had I attended either CAST or Agile 2015, rather than being at work trying to do work. But I couldn’t just mute #agile2015 and #cast2015 from my timeline. I missed all those conference talks about my livelihood, all those hallway conversations with my tribemates. Twitter is one of the few ways I can still perhaps learn from them. See, there’s that knowledge-FOMO again. I know my personality contains a strong element of compulsiveness. So when I observe my impressive dedication to rationalizing being a Twitter completist, I’m obliged to wonder whether I ought to continue to indulge my default preference, or maybe devote some energy and arrange myself to behave differently.

Still no?

If this question doesn’t arouse your sympathies either, consider how long it takes to read the entire newspaper in one sitting. Now imagine that you

  • Spend the same total amount of time reading, but as the sum of many smaller intervals,
  • Follow up elsewhere on half the smaller articles to avoid leaving your mind dangling,
  • Don’t know how long the newspaper you’re trying to finish is going to be today, and
  • Read this unrelaxing, variable-length paper every day.

Switching to Twitter for your news might require more total coffee. Even if it doesn’t, the frequent attention switches will leave you jittery. When I force the entire flow to go through me, some of it inevitably comes out my ears. And when I go on vacation, I feel relieved to be excused from firehose duty.

Nobody was making me do it

If that’s so, then besides my compulsions, what compels me to return to duty? Unlike the convoluted “reasoning” I’ve subjected you to in this post, this one’s simple. A year ago, I was struggling to make a career change. My strategy eventually worked, just before my budget ran out. Without Twitter, I could not have succeeded.

Twitter? Really? Yes. I used it to find people who were doing what I wanted to be doing and listen directly to them. How did they talk about their work? Build my vocabulary. What questions did they find worth consideration? Consider them. How did they seek growth? Seek mine. What interested them in conversation? Try, if and when I felt I could, to offer it. Thanks to Twitter, I formed needed connections outside my brain that led me to form needed connections inside it, so that by the time the right opportunity came knocking, I was the right opportunist to open the door.

Conclusion

I still use Twitter this way, and intend to continue. But I know enough now (and maybe knew enough all along) that the constraint on my being helpful to teams and organizations isn’t how much I know. It’s how effectively I pay attention. That’s one thing Twitter can’t help me with — unless one of you posts a link to an article about paying attention at a time when I’m sufficiently caught up to read it on the spot.

Posted Sun Aug 9 13:07:00 2015 Tags:

I’m not smart enough to have ideas before I need them

Last week an attentive colleague heard something potentially self-contradictory in my reasoning and reflected it back to me. His question was too precisely unexpected for me to remember it precisely well, but it elicited an immediate response that was memorably clarifying for both of us: “As a developer, I expect to be surprised often by what the business needs from the software we’re building, so I want to be surprised as little as possible by our software.” He asked if I’d ever said those words in that order before. I had not, and perhaps never would have, but for his careful observation and question.

I’m just smart enough to cope

An observation by Pat Maddox a few months back induced me to formulate:

”If you want to want to X, then arrange for whatever helps you want it. Enthusiasm engineering.”

I have lots of values of X I want (for varying degrees of “want”) to be handling differently. Most of them aren’t, at any given time, my most pressing concern. So they tumble around at the back of my brain, taking up a bit of space, and seeming more and more difficult the longer I’ve evidently failed to address them.

The downside is that no matter what doesn’t work about my current behavior, it’s relatively easy for me to make a habit of it. The upside is that as soon as I notice the problem — usually when it’s more biggish — it’s relatively easy for me to change my habit. I wasn’t doing it that way for any particular reason, so if I’ve got a reason to do it another way, I can arrange myself to do that until it sticks.

I can sometimes evaluate more eagerishly

If a future habit-induced difficulty would be sufficiently biggish that I’d rather not wait for it to get that far, I can try to arrange myself to address it sooner. This is considerably less of a sure thing. My main strategy is to change my scenery.

Changing which desk/office/coffeeshop/city I’m working from today, what I’m working on today, and/or whether I’m working today induces temporary changes in what I notice and attend to. As such, I can rely on changing my scenery to be temporarily useful. Among the Temporary Usefuls are invitations to consider making more lasting changes to one or two of my default settings. If I’m a complex adaptive system, and I want to be making different choices, then I need to arrange conditions that are likely to encourage me to make those choices. I’m willing to make the effort for one or two things at a time, if they seem likely to be worth it.

I default to comfort

When I’m not paying attention, I seek comfort above all else, which places me in familiar vantage points, where I stop noticing things I’d otherwise want to notice. That’s why, as a general rule, when someone invites me to do something I wouldn’t choose to do on my own, I try to accept: art museums, concerts of music that isn’t my absolute favorite, vacations through tropical locales, etc. It’s a good rule, if I ever want to expand beyond my self-imposed horizons.

Eine kleine Enthusiasmusingenieurwesen

I want to want that, so I arrange for others’ invitations to help me want it.

Posted Mon Aug 3 07:55:08 2015 Tags: