Who am I?

I’m an Agilist, a former software engineer, a gamer, an improviser, a podcaster emeritus, and a wine lover. Learn more.

Currently Consuming
  • The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses
    The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses
    by Eric Ries
  • The Talent Code: Greatness Isn't Born. It's Grown. Here's How.
    The Talent Code: Greatness Isn't Born. It's Grown. Here's How.
    by Daniel Coyle
  • Alexander Hamilton
    Alexander Hamilton
    by Ron Chernow

Paul Tevis

Entries in things that resonate with me (36)


We Are All Fictional

Recently John Scalzi wrote about the problem of being a fictional person.1 This stuck with me because (1) I have had a high enough level of Internet Micro-Fame that I’ve experienced this, and (2) I both agree and disagree with his conclusions.

We make sense of the world by building predictive models and seeing how well those conform to reality. Just as we do this with masses and pulleys, or with subatomic particles, we do this with people. I have never met John Scalzi; everything I know of him is through his blog or secondhand through other people who have met him. As such, my model of him is likely correct in some ways completely unlike him in others. In his terms, he is a fictional person to me.

Where my disagreement starts is with the notion that there is distinction between people who know the real you and those who have only this fictional construct in their heads. No one knows the real you, even if they have met you; we all have only “imaginary people” in our heads.2 Some people do have more data to work with when they’re constructing their models of certain people. My wife probably has a more accurate model of me, in predictive terms, than most of the people reading this blog do.3 The extent to which people “know us” falls onto a continuum, rather than being a strong dichotomy. Blog readers who have talked to me for five minutes at a convention fall somewhere between my wife and the pure readers on this spectrum. So I don’t quite buy the notion that we’re “real” to some people but “fictional” to others, though I agree that some people have wildly inaccurate models.

My bigger concern is about this notion of responsibility. John, paraphrasing Theresa Nielsen Hayden, says, “I am not responsible for actions of the imaginary version of me you have inside your head.” It important to realize that we use these models not only to make predictions but also to filter future data we get. Data that doesn’t conform to our models are often discarded. What I think he’s saying here is that if your inaccurate model of me causes you to disregard data that would help you build a better one, that’s not my fault. If you cling to your faulty notions of who I am, there’s not much I can do about it.

I don’t believe, however, that we can completely disavow responsibility for the models that people build of us. After all, we are the source of the data. Now when the amount of data is small, the model that gets constructed is, as John puts, “more about them than it is about you.” But if those models fall onto a continuum, where does your responsibility start or end?

What resonates most strongly with me is an idea from Susan Scott’s Fierce Conversations: “Take responsibility for your emotional wake.” She writes:

Everything each of us says leaves an emotional wake. Positive or negative. Our individual wakes are larger than we know. An emotional wake is what you remember after I’m gone. What you feel. The aftermath, aftertaste, or afterglow.

The things that we do and say ripple outwards from ourselves, like the aftermath of a stone cast into a pond. The further away from the stone we get, the more those ripples are distorted, or reflected “as in a glass, dimly.” They are still the results ourselves and our actions.4 One of the keys to getting real in a conversations, she writes, is to recognize and own the ripples you create.

Can I really hold you accountable for emotional wake you leave? Can I force you take responsibility for what people think you are like? Probably not. Like many moral discussions, for me this comes down a case where the notion of obligations is insufficient to explain the idea of virtue.5 I may not be obligated to take responsibly for my emotional wake, but the world will certainly be a better place if I do.

1 This was a commentary on and response to Elizabeth Bear’s post about what she calls the auctorial construct.

2 It’s not just other people; your sense of self is just such a construct. Just as culture can be thought of as the set of stories a group tells themselves about themselves, personality can be thought of as the set of stories we tell ourself about ourself.

3 Sorry, my friends.

4 And when enough people have models of us that contradict our own model of ourselves, maybe it’s we who are mistaken about who we really are.

5 And yes, I am a virtue ethicist, which is why I tend to find positions like libertarianism morally vacuous.


Leave Me Alone

I’m sitting in a coffee shop, headphones in, listening to the greatest song the world.

That song is, of course, Splendid Isolation by Warren Zevon.

I shouldn’t like the song as a much as I do. I’m an extrovert! I like people. I power up by interacting with people. So why does a song about telling the world to bugger off speak to me so?

“I want to live all alone in the desert / I want to be like Georgia O’Keefe / I want to live on the Upper East Side / and never go down in the street.”

Probably because I do dream, at times, of running away to live alone in the desert. It would be so nice to be able to concentrate, to create something, to make art, without people bothering me. Even extroverts need to be alone sometimes.

“Splendid isolation / I don’t need no one / splendid isolation…”

It’s so conflicted, too. I mean, you can hear how much he knows what’s saying isn’t true, even at the same time that it is true. Life has no simple answers. Warren knew that. And as much as I love his other work, he doesn’t sing anything else with as much raw honesty as this.

“Michael Jackson in Disneyland / Don’t have to share it with nobody else / Lock the gates Goofy, take my hand / And lead me through the world of self.”

What the heck does that even mean?!? Metaphorically, of course. I don’t know. But I love the image of Michael Jackson in his Bad costume walking hand in hand with a Disney cast member in a Goofy suit as the gates of Disneyland swing close.

“Don’t want to wake up with no one beside me / Don’t want to take up with nobody new / Don’t want nobody coming ‘round without calling first / Don’t want nothing to do with you.”

And how is a song that’s just four repeated chords so musically interesting? Ok, there’s a bridge, but other than that it’s dead simple. I’ve listened to this song on repeat eight times in a row now, and I’m not even close to sick of it. Genius? Yes! And how can you not love a song with a harmonica solo? Who cares about more cowbell? I’ve got a fever, and the only cure is more harmonica!

“I’m putting tinfoil up on the windows / Lying down in the dark to dream / I don’t want to see their faces / I don’t to hear them scream.”

By the time I get to this point in the song, I don’t care if there’s a zombie apocalypse outside. Just leave me alone with my dreams.


This post is part the Fourth Friday Challenge my friend Becky and I are doing together. Becky’s challenge to me:

“Paulie, I want you to wax rhapsodic. To gush. To write with your emotion first and with your brain not at all. Think of something that you like then stop thinking and start writing and be frivolous in your writing style. I require at least three exclamation points. Silliness in an entirely uncalculated form, but totally sincere.”

Read Becky’s response to my challenge.


Here, Now

At Agile 2010, one of the sessions that spoke most to me was Gil Broza and David Spann’s “The Curious, Present, and Empathetic Coach.” In particular, the notion of being present and being “in” was something that I realized I needed to work on.

Around New Year’s, I read Susan Scott’s Fierce Conversations and I was struck by one of her rules for getting real: Be here, prepared to be nowhere else. A conversation with Gwen revealed that this is something I’m not very good at.

I just finished reading Jon Kabat-Zinn’s Wherever You Go, There You Are, and I was struck by how often I’m not where I am.


When you go somewhere, how often are you there? How often are you somewhere else?


Taking Time To Reflect

This week at work has been crazy busy. Fortunately, what it's been full of has been work I've been wanting to do for a while. The problem with continuous motion is that it's hard to see how far you've come.

As I've been transitioning from technical work to coaching, I've been worried about not contributing enough to the team. One of the practices from Coaching Agile Teams that I've been telling myself that I need to do is the weekly value check:

Each week, sit down and write out a list of the value you delivered - just a little list of the things you helped emerge, the successes that people enjoyed because of your work, and the places you outright rocked! Let this be a personal journal. Assume no one else will ever read it so that you can give yourself the permission to be unbridled in what you right there.

So I did. Earlier in the week, I had scheduled half an hour on Friday afternoon (when I'm often winding things down anyway) to do this. When I started, I though I had nothing to say. What had I accomplished this week. When I was done, I couldn't believe how many things were on the list. I wasn't embellishing; it was honest assessment of how I had added value to the project. Many of them were cases where people told me how what I had done had helped them. Now I feel great, instead of overwhelmed, and all it took was a few minutes of reflection and writing.

I think I'll go skiing.


Un-Legacying Your Code, One Step At A Time

Michael Feathers' Working Effectively With Legacy Code starts out with the most useful definition of "legacy code" I've ever seen.

To me, legacy code is simply code without tests. I've gotten some grief for this definition. What do tests have to do with whether code is bad? To me, the answer is straightforward, and it is a point that I elaborate throughout the book: Code without tests is bad code. It doesn't matter how well-written it is; it doesn't matter how pretty or object-oriented or well-encapsulate it is. With tests, we can change the behavior of our code quickly and verifiably. Without them, we really don't know if our code is getting better or worse.

As someone who finds himself working without a lot of code that doesn't have tests, this resonates strongly with me.

So, how do we "work effectively" with code like this? By getting it under test. In particularly, by crafting unit tests that (1) run fast1 and (2) help us localize problems. Michael identifies two things we really need in order to write these tests. First, we need separation between modules. Most legacy code bases are hard to write units test for because of snarled dependencies. I've struggled through trying to instantiate a class in a test framework only to end up with half of the application in my test, so I understand the complexities involved. I've also dealt with code that we can't test in a framework because of undesired side effects from running it. Second, we need to be able to sense certain values that our code computes so that we know it did the right thing. Both of these are accomplished by what he calls a "seam":

A seam is a place where you can alter the behavior in your program without editing in that place.2

To exploit this notion of separating and sensing with seams, the book presents a set of dependency breaking techniques3 that can be done fairly safely to bring legacy code under test. The majority of the book is structured with familiar problems as chapter titles.

  • I Don't Have Much Time and I Have To Change It
  • I Can't Get This Class Into a Test Harness
  • I Need to Make a Change. What Methods Should I Test?
  • I Don't Understand the Code Well Enough to Change It
  • How Do I Know I'm Not Breaking Anything?

With only a few minor exceptions, each chapter spoke directly to a problem I've personally encountered in one or more of the code bases I've worked on. Each gave me a specific set of techniques to apply to the problem in such a way that I could see how they would work. I've started to do just that in current project.

The last section of the book is a catalog of the simple but powerful dependency-breaking techniques introduced throughout. Of the two dozen presented, there are handful that form the core and that are used repeatedly throughout, while the rest are used only in particular, less-common situations. What struck me most is how much these techniques are about getting back to core design principles. Classes should have one responsibility. Methods should be short and do one thing. When you find code that violates these principles, you can use the refactorings in this book to introduce new methods and classes to break them up. Yes, it can take a long time to get to that idllyic land where everything is simple, clean, and under test. But a journey of a thousand miles begins with a single step, and if you take just one step a day every day, you'll get there sooner than you think.4

1 And by fast, he means that each test runs in 1/100th of a second. This means usually (1) no hitting the database, (2) no communicating over the network, (3) no touching the filesystem, and (4) no editing special configuration files to run it. Tests that do these things aren't bad, they just aren't unit tests.

2 While much of the book deals with object-oriented programs, because object seams are one of the easiest types to work with, in languages like C we have link seams and preprocessor seams as well.

3 At Agile 2010, I overheard Martin Fowler describe these as "blind refactorings," because you have to make what you hope are behavior-invariant changes without the benefit of tests.

4 And much sooner than if you never take a step.5

5 And even sooner if you don't take steps backward. Stop writing legacy code.

Page 1 ... 3 4 5 6 7 ... 8 Next 5 Entries ยป