Lou: This is episode 52 of Write While True. Write While True is an infinite loop, and that’s because we think of writing as an infinite game, a game we’re playing for fun and to get better at, like a game of catch.
So in each episode, we’ll tell you something we learned about writing, and then we’ll throw you the ball with a writing challenge or a prompt.
I’m Lou Franco.
Brian: And I’m Brian Hall.
Lou: Hey, Brian. I wanted to start this episode by doing a little bit of a follow up to episode 48, where we talked about starting a collaboration. One of the things we ended with was doing a simple collaboration by just getting feedback on something you’re writing. And I wanted to talk to you about your thoughts on what to do with feedback.
Brian: Yeah, let’s do it, for sure. And to begin, the assumptions here are that you’re working on a piece of writing that you intend to iterate on. You’re going to revise this writing, you’re going to improve it. It might be a book, newsletter, blog post, something you care enough about to spend time on after you first put it out into the world for feedback.
So I would think of this in terms of, I’m going to guess you’re familiar with the expression, make it work, make it right, make it fast.
Lou: Yeah.
Brian: Okay. Doesn’t fully map over to the realm of writing, but I think it largely does. You might reframe it as make it work, make it right, make it polished. When we’re talking about writing.
And in that construction, we’re very much in the make it work phase, early feedback.
So the biggest challenge is knowing what to ignore and resisting the temptation to fix everything. You might have shared your writing with a few people and gotten dozens, even hundreds of comments and responses to what you wrote. And if that’s the case, that’s great. That means people are really engaged with your topic.
And you already have something of an audience or support system. Good for you. You cannot go through and just address one by one, every single comment. You kind of have to prioritize. To triage. And so the question is, does it work? This is where you start.
Does the writing actually help people make a change that they’re trying to make. If you’re writing about a new way to debug something, did they try it and did it work? Did they actually go from reading what you wrote to taking action in the real world?
That’s the biggest and hardest thing to achieve. And so you want to focus on the feedback that gives you a signal on that question before you worry about cleaning it up, making the prose nice and flowery, et cetera.
So the kind of feedback that is most useful in this phase is when people flag something that they really liked, that they found helpful, that positive. Oh, perfect. This explains it just right. Oh, I’m going to try this. That kind of feedback is really good.
Don’t touch that part. Keep that stuff. So the feedback is telling you this is precious. I must guard it. And then the other kind of feedback that’s arguably more useful is when people express confusion or doubt. When they flag something and they’re like, this didn’t make sense. I’m not sure what you mean. I don’t know how to do that. This doesn’t quite get me where I need to go.
So all the rest of the comments that you probably got about, you know, nice turn of phrase, this was funny, stuff like that. Let them wash over you and feel good about what you’ve written. But you really need to laser in on, is there stuff that people are getting confused about or stuck on, misunderstanding? And is there a point in what I wrote where people just stop reading?
Do the comments extend up through a certain chapter or paragraph and then fall off a cliff? That’s a thing to fix because it’s not working because they’re not reading the whole thing. So if you see that little cliff, you want to back up a few steps and say, what’s happening before the people fall off? I’m asking them to do something really hard. Are there a bunch of little, this is confusing notes right before the cliff?
So that’s the thing to fix and then iterate. And it can feel a little weird to let all the rest of those comments go and not address them. But the people who’ve left the comments are helping you and you have to sift through a bit to get to the important stuff.
So that’s all theoretical, but I wonder if you can help bring us into the realm of practical. You wrote a book, you did beta reading on your book.
Lou: I did, yeah.
Brian: Can you think of any examples of where you employed this type of approach to identify, here’s the biggest problem I need to fix based on this feedback?
Lou: One thing that happened to me in my beta reading is one of my beta readers happened to be the author of a very popular software engineering newsletter. It goes out to like a million software engineers and managers, and they’re totally my audience. Like they’re people who I want to reach.
So he gave me some really, let’s just say hard to hear feedback. In a kind way, but, but hard to hear feedback.
It essentially really struck at the core of what I was doing, like made me think that possibly the entire thing needed to be rethought, which I did.
And so, and, and what the, what the feedback was, was that he didn’t care what I thought about generalities. Engineers do this. Engineers should do that. This is a thing, in the industry, things like that, where maybe I’m not the leading expert on and don’t have enough authority to say.
But what I am the leading authority on and what I do have enough authority to say is my experience. I did this. This is what happened. This is what my team did. This is what didn’t work. This was a big learning.
And he wanted it more couched in that first person perspective on the things I was suggesting to do based on evidence from, even though that evidence was, you know, an N of one evidence, it was still a narrative from my point of view.
And people wanted to hear that. They wanted to hear like case studies of real world effects rather than me then drawing a conclusion about what everybody should do.
So I restructured the book around that and backed up each suggestion I gave with multiple times in my career where that suggestion would have worked and how I got to it over time.
And then sometimes I would have like very famous industry stories that people would understand and believe also apply that there is a lot of material out there where people have shared similar types of things.
And I could also draw on research by people and, you know, people who have won touring awards or written books that are very popular.
So I could bring all of that in, but the structure changed quite a bit based on that feedback.
Brian: This is a great example because it highlights the issue was not with the writing and the issue was not with the actual advice you were giving in the book either. It doesn’t strike me as something you could have figured out yourself without getting feedback from someone else.
And the issue was about the structure and the framing, I suppose, for what it’s worth. I restructured my book, too, based on beta reader feedback when somebody told me very helpfully that it was a bit overwhelming because there wasn’t a clear prioritization.
I have a bunch of do this, do this, do this, do this, and they seem to be in random order. Seems obvious in retrospect, but I needed somebody to tell me that that was an issue and that that was the biggest issue, at least for that round of revision.
So you don’t know, you don’t know what’s wrong with your book until you see people try to get use of it.
And in this case, the advice, it sounds like the advice was good, the writing was fine, but people weren’t going to implement the advice until you gave them enough credibility and vivid example to them really to trust that it was going to work.
That was the thing that you had to address more than anything else.
Lou: Yeah, and I have to say, honestly, when I heard that, I almost gave up on the book completely because I wasn’t even sure I could do that because it was a little bit of, I’m going to say, imposter syndrome, but more like, you know, genuinely, you know, I’m not some well-known software developer whose advice you should just believe.
I worked at companies that you might believe do good work and I had exposure to interesting code bases and so forth, but I was very resistant of it.
And then I happened to have a conversation about this with a friend of mine who, a tech person, but she also writes. And I told her this whole conundrum that I was having, like, you know, telling personal stories.
And she says to me, if you don’t write the book that only you can write, then what’s the point?
And it really made me think like, yeah, the book I was thinking of writing was going to be a little boring. With not a lot of storytelling with just like a list of things to do.
And, and even if those are good ideas, it’s like, well, you know, that could have been a blog post, you know, like it was really eyeopening that there’s more to, there’s more to a book, even a useful book than just, you know, a list of things to do.
There needs to be some motivation, some buildup of what happens when you do things wrong.
And even say upfront in the, in the first chapter, like give a really rundown of like, I work in B2B software. I work on things like this, you know, if you’re in gaming, if you’re in, you know, embedded software, this might not apply to you.
Brian: It seems counterintuitive that getting feedback from others early on and addressing it can actually lead to you writing a book that is more you, but I think that’s actually the way it usually goes.
Lou: Yeah. I agree. I think people like it, if they resonate with anything, I think that’s the parts that they’re going to pull out as like the parts that resonate like, oh yeah, me too. Or maybe, maybe, you know, I, I see, I see myself in that story or I had a similar story. I got a lot of feedback like that early on where people will tell me their stories.
Brian: So given all that, what’s the takeaway then? Assuming that you’ve written something and you’ve have solicited feedback and you frame that request, not as look at this masterpiece, but Hey, it’s early. It’s rough. I know it needs improvement.
Lou: Yeah. What is it, Brian? Tell me.
Brian: I’m going to say that the takeaway is go figure out the single biggest thing that you need to change based on the feedback and push yourself to ignore the little nitpicks and the little possible chances for improvement.
Really look at are people getting through it and are they getting something out of it? And if not, what’s got them stuck? It’s usually one big thing, one big part where they drop off or one big point of confusion where they just missed the point. Go fix that. And then get some more feedback.
Lou: Yeah. In my case, my, my reader didn’t get past the first chapter.
Brian: It’s usually the first chapter.
Lou: Yeah. And so, yeah, that definitely would have helped. Well, thank you, Brian. This has been episode 52 of Write While True, a podcast where we love infinite loops as long as they’re fun.