The personal is scientific

Reflections on the direction of this newsletter

I want to write better. In our industry, we write mostly personal opinions. What passes for a good argument or explanation is such a low bar. I'm no better at it than average, but I want to improve. Specifically, I want to write more personally and more scientifically. In this essay, I want to discuss how that affects you, my newsletter reader.

These two sound strange together, like they directly contradict each other. The personal is the most subjective, while the scientific is the most objective. But they're not at odds at all. Science builds on personal experience. What one does and sees in the laboratory is a kind of personal experience. "I added 10ml of X and 20ml of Y and got 30ml of Z." Science is personal experience minus cognitive biases.

When I say more personal, I don't mean more personal opinions. I like to share personal opinions, but that's not what I want to increase. I want to share more intimate experiences–communicating the ups and downs, doubts, and joys. There's something magical about how an individual's experience, skillfully retold, takes on a universal quality.

Someone I admire a lot for his personal writing is Kent Beck. In his newsletter, he shares a lot of the fears and anxieties that he faces. And he does it with style, grace, and courage. For example, Beck doesn't say we should do TDD because it's the best/only way to write software, as some people do, regardless of the lack of evidence. He says he does TDD because it makes him feel safer. That's the kind of personal experience I'm talking about. He doesn't need to convince anyone why they should practice it. It’s a very personal argument based on what he feels. I’ve always argued that REPL-Driven Development is better because it gives you faster feedback. But Beck inspires me to say I use it because it makes me feel confident.

At the same time, I want more rigor in my writing. I shouldn't say something that I don't know to be true. I should research what others have found. And I should cite my sources. These are obvious and basic practices, but I don't do them enough. I often will repeat something I read one time 20 years ago but I don’t remember it accurately. Or I'll say something and use words without clear definitions, which lets me get away with too much.

I appreciate that people have mentioned these things to me during my years of writing online. They've pointed out that I omitted evidence on the other side of my argument (I needed more research) or that I'm using a word in two different ways to further a line of reasoning (unclear definitions). I'm thankful every time. 

I used to believe sloppiness was justified as part of the discussion. There's a back-and-forth online, similar to in-person conversations, where we work out and refine ideas. In short, I believed it was okay to be sloppy and wrong as long as I was converging on the truth. But things live forever on the internet. Readers might take my sloppy statements as truth. Being wrong is always possible, but sloppiness is not acceptable to me anymore.

Also, by Science, I don't mean the most extreme version where we can measure and predict with minute accuracy. "If I do TDD, my maintenance cost will decrease by 20%." That's sometimes known as physics envy. It's a pipe dream in our industry. No, I mean the broader definition where we try to make sense of the world by applying meta-reasoning. In Science, we develop better processes for understanding. So, while the DORA study can't pinpoint the best deployment frequency for a given team, they found that more frequent deployments lead to higher performance, and their process for finding that is rigorous enough to believe for the kind of work we do. DORA is Science.

And, of course, I will share my opinions. But the idea must be accompanied by skepticism and very clearly marked. "Here is my opinion, but I don't have any real evidence." The person I look to the most for this is Martin Fowler. He is so good at explaining terms, capturing the nuances and the different usages, and stating his opinion while being fair and clear about what is what. It takes a lot of maturity to write this:

I call this a hypothesis because it is a conjecture, there is no objective proof that this phenomenon actually occurs. In scientific terms it's not a very good hypothesis because it's hard to test. We CannotMeasureProductivity nor can we measure design quality.

But despite it being only a hypothesis, it's also an axiom for many people, including myself. We may not have objective proof that this effect occurs but many of us feel that this explains what we see we see qualitatively in the field. It's an axiom for me as it's the assumption that underpins my entire career as a writer about software design. If design doesn't actually improve productivity in some way, most of my writings are worthless.

He outright states there is no proof for the hypothesis, says it's not very good because we can't test it, and then tells why he still believes it.

This newsletter, which comes out every Monday and will always be free, is about a search for understanding. I write to explore ideas and then share them with people who want to hear them. It's a gift.

Because some people told me they wanted to support my work, I've opened up paid subscriptions. It's an experiment. I hypothesize that people who pay care a little more about me, my work, and my struggles. They would be more forgiving if I emailed about a conference talk I liked or how it's hard to write a book when you're sleep-deprived. The Monday emails are the primary writing of the newsletter, and any financial support is to help with that. But if you pay, you'll get a peek into the process. Also, no one should expect that the good stuff is behind a paywall. It's the opposite. I won't make much money with this strategy, but that has never been my intention with my newsletter.

I don’t want to bombard either group with “upgrade” buttons or “free previews”. Just know that there are some more emails, mostly about me, that you will receive if you become a supporter.

So, thank you for reading. If you’re a supporter, also, thank you.

Rock on!
Eric