Oxide and Friends

Oxide and Friends Twitter Space: October 25th, 2021

Coder’s Block
We’ve been holding a Twitter Space weekly on Mondays at 5p for about an hour. Even though it’s not (yet?) a feature of Twitter Spaces, we have been recording them all; here is the recording for our Twitter Space for October 25th, 2021.
In addition to Bryan Cantrill and Adam Leventhal, speakers on October 25th included Brigid Gaffikin, Tom Lyon, MattSci, Simeon Miteff, Edwin Peer, Ian, Nima Johari, Matt Campbell, Joshua Hoeflich, Bill, Ariel Machado, and Kendall Morgan. (Did we miss your name and/or get it wrong? Drop a PR!)
Some of the topics we hit on, in the order that we hit them:
  • BattleTris stories
  • [@10:15](https://youtu.be/QGs5hlH6cLk?t=615) Writer’s block, flow (instigating tweet)
  • National Novel Writing Month NaNoWriMo
  • Flow wiki
  • [@16:54](https://youtu.be/QGs5hlH6cLk?t=1014) “If you’re just problem solving, you can’t have writers block” 
    • Many degrees of freedom
    • Shiny new object
  • [@20:39](https://youtu.be/QGs5hlH6cLk?t=1239) Remedies for writer’s block? 
    • Decide if you’re looking for tactics or strategy; is it small technical issues or not?
    • Tactics: Hone in on ‘the craft’ – work on the language
    • Strategy: Is this going to reach an audience/get an agent?
    • Write a scene from a different character’s PoV; write a vignette
    • This sounds like prototyping in software
    • If you’re stuck on debugging, write some debug infrastructure
  • [@24:16](https://youtu.be/QGs5hlH6cLk?t=1456) Doing something else entirely 
    • Brigid: ceramics, sound walks
  • [@27:43](https://youtu.be/QGs5hlH6cLk?t=1663) Not everything is burnout
  • [@34:13](https://youtu.be/QGs5hlH6cLk?t=2053) Software analogies to writer’s techniques
  • [@36:04](https://youtu.be/QGs5hlH6cLk?t=2164) Personal productivity obsession 
    • Writer Emergency Pack by John August, site
    • “You’ve got to get back to the coal face. You’ve got to finish it.”
  • [@41:00](https://youtu.be/QGs5hlH6cLk?t=2460) Does Rust make this indecision worse? 
    • Pressure to find the “right” way
  • [@43:56](https://youtu.be/QGs5hlH6cLk?t=2636) Arthur Whitney (wiki) > The best analog for software is poetry
  • Pandemic life, collaboration and conferences
  • [@51:51](https://youtu.be/QGs5hlH6cLk?t=3111) Hallway track. Software is collaborative but ultimately programming is a solitary act 
    • Nimo’s experience, it’s all collaborative. Code review, art
  • [@59:36](https://youtu.be/QGs5hlH6cLk?t=3576) Cliff code reviews, how to do good reviews 
    • Lack of code reviewers for Rust at Google
  • [@1:04:16](https://youtu.be/QGs5hlH6cLk?t=3856) Writer’s groups, different focuses
  • [@1:08:04](https://youtu.be/QGs5hlH6cLk?t=4084) Grad school during pandemic, gather.town - video chat platform for virtual interactions
  • [@1:11:54](https://youtu.be/QGs5hlH6cLk?t=4314) Goals, take the wins that you can, boundaries between work life and home life
  • Kendall Morgan “Thoughts on Code Reviews” blog post
  • [@1:17:38](https://youtu.be/QGs5hlH6cLk?t=4658) Bill’s experience switching things up, and enjoying computing again
  • Wrap up tweet
If we got something wrong or missed something, please file a PR! Our next Twitter space will likely be on Monday at 5p Pacific Time; stay tuned to our Twitter feeds for details. We’d love to have you join us, as we always love to hear from new speakers!

Creators & Guests

Host
Adam Leventhal
Host
Bryan Cantrill

What is Oxide and Friends?

Oxide hosts a weekly Discord show where we discuss a wide range of topics: computer history, startups, Oxide hardware bringup, and other topics du jour. These are the recordings in podcast form.
Join us live (usually Mondays at 5pm PT) https://discord.gg/gcQxNHAKCB
Subscribe to our calendar: https://sesh.fyi/api/calendar/v2/iMdFbuFRupMwuTiwvXswNU.ics

Speaker 1:

Alright. Tweet was sent. It's 5 o'clock Pacific. Ridiculously in the middle of the night in Europe. So, yeah, we, in addition to, usual cast of suspects, we also have, the editor of my tweets among other things.

Speaker 1:

So, Brigitte, you actually saw this tweet before I tweeted it, the tweet that we're gonna be talking about today.

Speaker 2:

I did. It didn't need any edits. So, Brian, it's excellent writing.

Speaker 1:

So, yeah, if it's not quick if it's if it's not obvious, Bridget and I are my wife, I've been wanting to say that. Oh, you're being you've got that in right away. I think we're done. I we're done. You know, I have you seen that video going around of the the woman just saying that to her wife, then her wife leaves her.

Speaker 1:

So but it was very funny. It was a very funny video. So, anyway, I'm looking forward to saying that. So just to be to to get the subject at the top, we are, about a week ago, I would say apropos of nothing, something that's been on my mind a little bit. I talked about writer's block for software engineers.

Speaker 1:

That's I I believe that software engineers get writer's block. I actually didn't think this is a very controversial observation, But, Bridget, I did have you look at it before I tweet. Is there a pattern from your perspective of the tweets I have you look at before I tweet them?

Speaker 2:

Perhaps well, firstly, things that I will understand. Not industry specific, but maybe that's because also the things that I would understand that aren't industry specific have bleed over into the, you know, quote, unquote, rest of the world. And maybe you're touching on things that aren't talked about much or like this, things that, are not taken for granted.

Speaker 1:

Okay. I think you're speaking a little euphemistically. I really have you look at the stuff. I think it's gonna get get me in a lot

Speaker 3:

of trouble.

Speaker 4:

That's where I'm record breaking. That's that's kinda

Speaker 1:

what I assume. Yeah. Absolutely. Yeah.

Speaker 4:

Most most of the time

Speaker 3:

Yeah.

Speaker 2:

But I'm trying to narrow. I'm

Speaker 1:

Most of

Speaker 4:

the time, it's dialing for no. Right? Be like, well, we can do that, but we can send these kids to school again.

Speaker 1:

Pretty much. And and, I have I've been you know, and I take that super seriously. Like, anytime Bridget's like, no. Do not send that. I'm like, delete it.

Speaker 1:

Not gonna absolutely not gonna send that. Thank you.

Speaker 2:

What about the times I say don't tweet that before you've even thought of tweeting it?

Speaker 1:

Okay. I would like to say that many of the times you say don't tweet that before I thought of tweeting it, I was not going to tweet it. I know this is, like, not verifiable and not to the the but but when you looked at the the reason and the reason I wanted to aside from the I wasn't necessarily worried about this one getting me into trouble, but I did want your take as a writer. And I just what if it felt reasonable, but that was a reasonable portrayal of writer's block or not. And I I think your reaction was just like, yeah.

Speaker 1:

Why would like, you there are certain tweets that you look at where you're like, why am I looking at this? Is this is this tweet, like, deeply offensive in some way that I don't realize? And I feel like this is one of those. Do you agree with that?

Speaker 2:

Yeah. I mean, absolutely. Yeah. And I think part of what made it one of those is that and Brian and I have known each other for 20 years, is that you have, Brian, have always described yourself, or software engineers as well as writers. And I'm assuming that the kitten caboodle goes without including writer's block even if you're not writing the same way I or someone else who, you know, writes stories also might be writing.

Speaker 1:

Just because you mentioned how long we've been together, can I I've got a stray? I'd like to get off my chest. Do you mind if then we're gonna go into this? Can I

Speaker 2:

As long as it won't bore everyone, and this is my, equivalent of saying don't tweak that?

Speaker 1:

No. Yeah. Exactly. To your judgment. Right.

Speaker 1:

Exactly. You're I I don't have the opportunity to run this by you to tell me not to tweet it so I can just, like, say what I'm about to say. So I wrote a game in college. And the so Adam knows where this is going. Right.

Speaker 1:

Adam knows where this is going. So I wrote a a a game in college, a a, a game in which 2 players would play Tetris against one another. They would use their prowess in Tetris to buy weapons to screw up the other person's game. And, 2 people who I just called Battletress. I I dare say I, Adam, you discovered this after I left school and became it kills me to say this, but became a better battlecruiser than I am, which really it's do you know how many years it's taken me to really process it?

Speaker 4:

Tough tough but fair. Tough but fair.

Speaker 1:

So you and I would have these absolute, like, huge battle trust matchups. And, Bridget, at some point, when you were working on your dissertation, I introduced you to this game. And you and Matt Arons would do you remember these games with Matt Arons?

Speaker 2:

I do. I do. Yeah. Do you

Speaker 1:

wanna describe your games with Matt Arons, your battlecruised games with Matt Arons?

Speaker 2:

Okay. Having emphatically said I do, I don't remember the detail that maybe you remember. I mean, they were focused and tense. I was very into this. Is something I'm missing?

Speaker 1:

Well, it's really interesting to get your take on it. Adam, what is your take on Bridgette? I've been I feel like

Speaker 4:

I was gonna be thrown into the bus on this one to to to say what cannot be said. But, you know, I think it was kind of like watching the kids' soccer game.

Speaker 1:

Like, that's sort of that. Like Oh, god. That's exactly it. Wait.

Speaker 2:

Who's the who's the angry parent here?

Speaker 1:

We're in the parent's decision to

Speaker 4:

take this. Brian's sort of the supportive parent.

Speaker 1:

A supportive parent, but, like, talking on the sidelines about something else. Talk like, work conversation on the sidelines.

Speaker 4:

Yeah. Hey. It's you're there. Right? You're there.

Speaker 1:

You're there.

Speaker 3:

You're there.

Speaker 4:

Life is just showing up.

Speaker 1:

But it's like a kid's soccer game, but no time limit.

Speaker 4:

Right. Right. It's just sort of, like it's nice that the kids are having fun.

Speaker 1:

So, Matt, Aaron so Bridget's working on her dissertation. Matt is working on ZFS. And they're both, like, in a little bit of a geldrums, I think. Not not a writer's block, but just like you're both at like, he's at the top part of ZFS. You're at the top part of your dissertation.

Speaker 1:

Andy, I think you both welcomed the distraction, and you both were not very good at battle trust. Like

Speaker 2:

I guess I blocked that one out.

Speaker 1:

Okay. So you were both this is why the youth soccer analogy is so good because this is not, like, high level youth soccer. This is like watching 6 year olds play soccer. And it just like the Adam Irish would've they just neither one of them was good enough to off the other.

Speaker 4:

No. No. Every game was 0 to 0. It was just sort of like, just just kind of in effect couldn't push the other one over, but nor could they be pushed over.

Speaker 3:

And

Speaker 1:

so they would they

Speaker 5:

They're the first one, Brian. Like, does it still compile, and can we get it?

Speaker 1:

Okay. So we'll get to that later. No and no, unfortunately, is the answer to both of those questions. But, yeah, if if if Oxide ever does a hard pivot, it's definitely gonna be into battle, Chris. The so these 2 are are not enough to off one another.

Speaker 1:

They would have games that would go on. Bridget, I don't think I'm exaggerating. I think it's, like, 4 hours. But, I mean, they were these were not Wow. I I I

Speaker 4:

think for the sake of this conversation, they were cricket like. Absolutely.

Speaker 1:

But I mean Oh, god. They had cricket like multidaped out of this test.

Speaker 2:

Okay. So That doesn't sound like praise, Adam.

Speaker 1:

I think that's actually So I think, Adam, you are, like, just split in the middle here in a really impressive way, I gotta say. You are just nailing it with, like, metaphors that are both accurate and, like, yeah. They kind of are what you think. They're they're great. So and then, Bridget, you and I would play together.

Speaker 1:

So we'll play against one another somewhat frequently.

Speaker 2:

Right. But you and I playing together was sort of like the parent teaching the kid chess where you patiently pretended that you only had pawns or something.

Speaker 6:

I

Speaker 2:

I knew I was being coddled.

Speaker 1:

Okay. Well, sadly, you were not being coddled. I was definitely, like, the psychotic parent that feels they're gonna teach their children chess by by by whooping them. I definitely was like I I mean, I my belief is like, look, I'm always gonna play to win. And, at one point, you and the game would you know, there were there were some quality problems in the game, not too many.

Speaker 1:

But you and I were playing.

Speaker 2:

Ah, yes. Okay.

Speaker 1:

Would you would I I think you should have this right from your perspective.

Speaker 2:

You could carry on. You've you've got the thread.

Speaker 1:

You don't that that that that's a masterstroke because this this shows you in such a positive light. So you come into the next room saying, hey. The game crashed. And he said, did you hear me? I said, the game crashed.

Speaker 1:

And I got, like, no I get I must have had no reaction. And she said, the game crashed. I said, no. The game didn't crash. You won.

Speaker 1:

And you're like, wait a minute. I beat you? And I'm like, you you did beat me. Do you remember your victory parade around the apartment?

Speaker 2:

Oh, yeah. Definitely. I think I was pretty quick to tell Adam as well.

Speaker 4:

Yeah. I think I think it was like, there was like a tattoo of the date, if I remember correctly. Some some really commemorated that moment.

Speaker 1:

I commemorated the moment. And Oh, off my side. And you did not tell Adam. I told Adam because I know this. Because Adam, do you remember this?

Speaker 4:

Indelibly.

Speaker 1:

So I am like, Adam, you're not gonna believe what happened. She, she took a game off me. And I was like, wait. Wait. Wait.

Speaker 1:

Who? I'm like, Bridgette. Like, Bridgette what? What happened?

Speaker 7:

And I kinda outlined a little

Speaker 1:

bit of what happened. Like, I can't believe she took a game off me. And Adam's like, you know what this means? She's the one. You gotta you gotta marry this girl.

Speaker 1:

So there you go. Did you all know that, Britney?

Speaker 2:

I do. It's all coming back.

Speaker 1:

Okay. You bet. You know, you left yourself muted for, like, a heartbeat too long, and I was just like, shit.

Speaker 2:

I, yeah. No. That was purely offspring related.

Speaker 1:

Speaking alright. So to get us back on topic and a little bit offspring related, one of our offspring, I'm not sure if it was the one that was bothering you or not, but the 14 year old, I explained, hey. Mom's gonna be on the space with me. He's like, oh, okay. Well, what are you talking about?

Speaker 1:

I said, well, we're gonna talk about writer's block for software engineers. He said, wait a minute. Does that happen? I was like, yeah. We think it does, and that's what we're gonna talk about.

Speaker 1:

So, Bridget, get I'm so sorry sorry for the long I just could not resist telling the, the story that involves the 2 of you.

Speaker 2:

That's great context.

Speaker 4:

Were you were you actively kind of suffering from writer's block or code? And and as as someone also who writes a lot of pros and a lot of code, you know, how do you think about writer's block?

Speaker 1:

So I think and this is why and then, Bridget, love your take on this. I think of this as part of the challenge is when you are doing something that is creative and really unstructured, it can be that you have these moments where you know exactly what you're doing. And, you know, we in software I don't know if if, Richard, you got the same term in the writing world, but this has been called flow in software. Probably probably borrowed from some other domain. But where you are, where you're in this kind of this flow state where it's just coming right out of you, which is great.

Speaker 1:

And then there are these other periods of time where everything feels daunting or you feel like you're taking the wrong approach, I feel, is when this happens to me a lot, where I'm not convinced that, like, is am I going down the right direction or the wrong direction? I was not suffering at that moment that I tweeted that. But I feel that this is something that has happened to me a lot in my career. And I do feel that we don't talk about it enough. So, Bridget, does that make sense for yourself from a a writer's writer's block perspective?

Speaker 1:

Is that does that sound similar?

Speaker 2:

Yeah. It does. Without sort of stating too many caveats, it's different for everyone, obviously. The flow thing is interesting. I didn't realize that was such a broadly used term.

Speaker 2:

I certainly get into the zone whether I, you know, put some music on or just I'm able to block out everything around me and write what I'm planning to write or let the words flow or whatever it is. But, write I I think, you know, writing is also writing I write, but to be clear to everyone, I, I write fiction, novel length fiction. I am unpublished, which is what we say instead or pre published. Instead of aspiring, which is a silly term. But I take it seriously.

Speaker 2:

It's obviously not a day job. I've been doing it for, oh, gosh. I don't know, a a while now. And, so back to your question, Brian, yes. I I I do think that makes sense, but I think there's also an aspect to always having an ear or an eye on on industry and audience and, genre requirements and all this other stuff that maybe keeps one eye open as it were rather than being totally totally absorbed by it.

Speaker 1:

It it it it the it being the writer's block in that sentence or the it being

Speaker 2:

Oh, yeah. I'm I'm talking about the flow.

Speaker 1:

The the flow. I got you saying. The the the where you are kind of constantly when you're writing for an audience, you've got this kind of other thing that you've got your eye on, which I feel we've got in software too. There's there's there's absolutely an analogy for that in software. Where you I mean, definitely an analogy.

Speaker 1:

Where you like, am I building this in a way that the user of the software is gonna actually like? Is it am I doing the right thing?

Speaker 2:

To be clear, because I could be not everyone is like this. Some people are underwriters. I am an override. I could write forever. I could

Speaker 8:

write words and words.

Speaker 2:

I don't have a problem spewing out flow. That that's fine. So as an aside, I don't know if anyone here has heard of NaNoWriMo. It stands for National Novel Writing Month. And, hey, if you are not an aspiring, but a pre published writer, of any sort and you want to start putting long form down on paper or on the screen, National Novel Writing Month takes place in November each year, and it's run by a non profit organization that does great work promoting, and supporting people who are getting into writing.

Speaker 2:

And I started writing long fiction by doing a a stint at NaNoWriMo, which is where you commit to writing 50,000 words of whatever. But ideally, this is something that will make sense when you get to the end of it. 50,000 words of a novel in that month. And I mean, I I got the manuscript somewhere. I I I can't quite bring myself to look at it, but the the writing the content was not an issue.

Speaker 2:

So, yeah.

Speaker 5:

So my definition of of what I understand flow to be, it's not just about the quantity of words coming out. Right? It's about the focus, and it's about the the right stuff coming out. Right? It's like the being being absolutely focused in what you're doing and and, you know, no other interruptions or, you know, the the other stuff melts away, and and you're getting good progress.

Speaker 5:

It's not just volume. It's it's correctness too that that that sort of an aspect of it.

Speaker 1:

Yeah. And I would say it's even stronger than that. I feel it. Adam, I wanna get your take on this too. I feel that when I'm in that state, I feel that there is something that needs to get out of me, and I'm just, like, the vessel to get it into the editor.

Speaker 1:

Like, I I've got such a clear idea of the thing I wanna go add or the thing I wanna go build. I I I know exactly what it is, and I'm just, like, just absolutely banging it out because I've got that clear vision for what it is.

Speaker 4:

Yeah. I I totally agree on that. It's it's it's sort of the story that tells itself. And I think that what what you said at the top, Ryan, of of the the aspect of both creative and many ways to do it. That's what kinda gets me stuck.

Speaker 4:

It's it's when I'm sort of what both for, like, writing blog posts or longer form things or writing software where I kinda, you know, have a false start and then I kinda unwind because I'm not really happy with that. And I'm kinda paralyzed by indecision between these different paths. And so, you know, without without those kind of multiple paths, hard to see around the corner about which one it is, you know, that that's what really kinda trips me up at times.

Speaker 2:

Adam, is this because there are problems that you are facing that you don't know how to solve or you don't know how to solve them or you're not sure which problems to solve to make progress?

Speaker 4:

You know, it's it's it's a it's a little different than that because I think often it's not knowing the the right way or the best way, or kind of the right way to tell the story. Like, the right way to structure things.

Speaker 2:

Okay.

Speaker 4:

More you know, because I saw, you know, Brian, I went, I thought your your tweet was great. And I I saw it kinda right when it came out and didn't notice how how many people also liked it. And I saw a bunch of people responding saying, you know, that that it didn't feel familiar with with kind of a, you know, outside of, like, a more creative realm that is to say, if you're just problem solving, you can't have writer's block. And I think that sort of under underscored this idea where, like, it doesn't necessarily mean we don't know how to solve the problem, but rather we don't know how to, again, tell that story the right way, structure things the right way. Absolutely.

Speaker 1:

And I feel like so I also feel that in looking at those replies, Adam, I feel like there is a correlation on age that the longer you've been in software engineering, the more I feel you know that there are multiple ways of doing things, and I feel that that can be crippling where you're like, actually, I don't wanna incur technical debt. I actually want to measure twice and cut once. And but sometimes, like, actually, I'm actually measuring a 1000 times at this point. Or that's actually a poor analogy because it is you're you're trying to pick between different paths, and that's when I I feel that I I get stuck. And I I I'm not sure if it it but does that make sense from the writing perspective?

Speaker 1:

Is that is that a is is there Yeah. Knowledge of the other

Speaker 2:

Technical issues here. Can you hear me?

Speaker 1:

Yes. We could hear you. Did I did I mute everyone accidentally? We could hear Yes.

Speaker 9:

You did.

Speaker 1:

Yeah. Sorry, Bridget. I muted you. You should be unmuted now.

Speaker 2:

Yeah. I I think that

Speaker 1:

Oops. And now Oh, dear. Oh, dear. Oh, no. Alright.

Speaker 1:

I well, I I can I can hear her talking in the next room? So I know she's I know. Unlike with most of our technical issues, I actually know that Alright. Like, we can hear you

Speaker 2:

on speaker. Good now. Yeah. That that's that's a headphone issue. Brian, could you recap briefly?

Speaker 1:

I the they're just asking you if this this, like, not knowing which path to take. Like, I can see doing this path, and I can see the kind of I'm seeing around the corners on this path and the consequences there. I'm seeing this other path. I'm seeing a 3rd path. I'm seeing a 4th path.

Speaker 1:

I'm seeing a 5th path. I'm seeing 12 other paths. And becoming crippled by the the amount the degrees of freedom that we have in software are often this is where there is a parallel with writing, where we have this tremendous many, many, many degrees of freedom, much more so than you have in a more rote discipline. But those degrees of freedom can be overwhelming and can result in us being paralyzed, I feel.

Speaker 2:

Oh, that's definitely I mean, that's definitely an issue with writing. I mean, that is that's the issue on so many different levels. It's whether you're writing something in science fiction and you're like, God, this is ridiculous. This should be, you know, contemporary realistic. Or I'm writing this in 1st person and this is this absolutely must be in 3rd person I have to rewrite or just the whole, you know, you talked about flow being something that, you talk about in your field.

Speaker 2:

People often talk about writers often talk about the shiny new object. And that's, well, this idea is so much better than the current idea. I'm gonna put the current idea aside and just chase those shiny new objects forever.

Speaker 1:

Wait a minute. Okay. There's we don't we talk about shiny new object in software. Who who invented the shiny new object? Maybe we stole it.

Speaker 1:

Is full

Speaker 10:

of that. Right? Like, software is full of second guessing yourself. I mean, it that to me is, like, the equivalent of our writer's block is getting stuck in that analysis paralysis. And, like, yeah.

Speaker 10:

This is gonna go wrong, so rewrite it again, like, the 7th time.

Speaker 1:

Right. Okay. So and so here's my and this is what I really wanna get to is what are the remedies for writer's block? Because I think that if you are as a software engineer, if you're suffering some of some of those writer's blocks, I feel that the remedies that writers use have an analog in the in what can work for us too. So, Bridget, what have you found in terms of, like, when you've been stuck?

Speaker 1:

What have what some of the remedies have been for that?

Speaker 2:

Okay. So I think Brian and I were talking about this, offline a little bit earlier. I try to think, am I looking for tactics or strategies? And I don't wanna overwork that metaphor, because I'll probably overwork it on the wrong way. But are these small issues that I can address, technical issues with what I'm writing?

Speaker 2:

So for example, am I stuck in a certain chapter or section of the writing, finding it boring and unconvincing? Then I'll sort of hone in on the craft and look at the way I'm using language. And so that's sort of that's a a craft technical solution to the problem, hopefully. But then there's also the sort of strategic bigger picture stuff. It's just like, is this gonna reach an audience?

Speaker 2:

And is this gonna get an agent? Or will a publisher buy this? And that stuff is harder, to solve. And I think when it comes to those sort of more existential questions, that drive the writer's block, I would say putting words any words on the paper is good. Taking a break, writing, I'm talking totally writing here.

Speaker 2:

I assume that you 2 will be able to think of analogies to writing software, but say take a scene, write it from a different character's point of view. Write a vignette or a short story or a flash fiction about a character, that doesn't make its way into the into the actual novel, but is useful for exploring something, and that will maybe spark a solution to the problem. Yeah, I think identifying the problem is also like, what what is what is wrong here, is a huge part of it, and that's not always easy because sometimes those problems exist outside my my

Speaker 4:

This is beautiful, Bridget. Beautiful, Bridget. Just because what I mean, what I'm hearing is prototyping.

Speaker 11:

And I

Speaker 4:

think it's it's Totally. It's it's so beautiful that you have this in the writing discipline. And it's such sage advice and and I think probably like writing, prose as well. It can feel like a diversion. It can feel like the opposite of progress.

Speaker 4:

But to your point, often, it it gives you the the kind of mouthfeel of the problem and and the texture of the problem and is in helpful in ways that are surprising.

Speaker 2:

That's a really lovely way to put it. Yeah. Yeah.

Speaker 1:

Yeah. And, actually, you know, it reminds me of advice that, Adam, I know that I certainly dispense and use myself when stuck on a single bug. If you get a you know, you get these bugs that are just, like, absolutely psychotic, and it can be really, dispiriting when you feel like you're not making progress on a single bug. I always advise people to spend some time writing debugging infrastructure. Write the, write the d commands in the mdp parlance or write part of the debugger effectively that you wish you had anyway.

Speaker 1:

And then you're actually, like, writing software at least, and you feel like you are moving forward. And then that debugging infrastructure will come in useful in the next problem. And then in in the the process of doing that, you're often likely to to to resolve your actual

Speaker 4:

issue. Yeah. No. Totally. And

Speaker 9:

to what degree is, you know, at least in the writing world, is it about just going off and doing something else, that may or may not even be related to it versus, you know, doing something that is specifically related?

Speaker 2:

Ah, my opportunity to talk about these ceramics I took up during COVID, which I did take up initially as a Zoom class, because I wanted to do something with my hands that was not writing. And I wanted to think creatively and have to think several steps ahead, which you have to do with ceramics, like making anything, and hopefully sort of get myself back into a writing mindset. So yeah. Absolutely. I'm throwing around a few of the things I've done.

Speaker 2:

I'm thinking about kind of an excuse to get outside, but I used to say, I'm gonna take myself on a sound walk. And this was when I was early drafting something. I went on a walk by the, Alameda Shore, beautiful part of the Bay Area, and listened for sounds and tried to describe them and wrote notes about them. And just like gathering, a toolkit or sort of an inventory of things I could use later on. I have no purpose for them.

Speaker 2:

You know, it was purely just observing, writing, listening. And, yeah, that getting out of getting off the path of what I thought I should be doing was often a good way to get back on that path and feel refreshed.

Speaker 11:

You know, you know,

Speaker 4:

Bridget, one one of the least helpful comments, I think, on Brian's tweet, someone someone saying, you know, I like to get out and walk, which I thought quick great advice. You know, change change scenery, you know, step away from the problem. Someone else responded, well, you know, I've got a treadmill built into my house

Speaker 1:

problem solved. I bet you. Yeah.

Speaker 6:

I mean, the the value of both of those activities. Right? Both, pottery as a fellow potter myself and, and going for wolves, both have forms of meditation. Right? Yes.

Speaker 6:

It's meditation aspect to it.

Speaker 2:

Yeah. That that's yeah. Absolutely. I mean and not to sort of go on about the the pottery ceramics too much. But the more I got into it I mean, let I've been doing this literally 6 months.

Speaker 2:

But the more I got into it, the more I realized the complexity of steps that you, that you need to get to that product. I I'm making it sound like some industry thing, but to to get to, you know, whatever you want. So it really became a sort of meditation on, on the creative process as well for me and being comfortable with being a few steps behind or sort of planning at a bigger scale in a different medium.

Speaker 6:

Yeah. That resonates hard with me. I I when I took up pottery a few years ago now, I saw very strong overlaps between pottery, and and software production. And, I found there was a lot of parallels between between the 2, and it was also really refreshing to go back to being a beginner or something and, accepting that you're not going to be good at it for some time and and, taking pleasure in that process.

Speaker 2:

Definitely. Yeah. Having a sense of wonder at something as, that's rare

Speaker 1:

when you think about that. I mean, god, so many good points in in there from both of you of the but I love in your point about being the a beginner at something and how you know, on the one hand, we kind of romanticize this kind of growth mindset. And on the other hand, we slay ourselves when we feel like we are something's taking longer than we think it should. But, of course, in software, everything takes longer than it should. I I feel that things are rarely done faster than you think that they will be done.

Speaker 1:

And I I also feel that we are and I love getting your point about and and, Bridget, you too about about using this as a way to to, do to go through the creative process in a different kind of medium and how that is helpful when you get back to your actual craft. And I feel in software, we kind of falsely dichotomize the world, and I think it's a mistake, a huge mistake, to think of what is effectively a a block in our creative process as burnout. I mean, it's it's kinda like our one word for everything. Like, everything is burnout. And burnout obviously very much exists, but not everything is burnout.

Speaker 1:

And you, like, you may have struggle connecting for something that's not burnout. And by the way, if you're burned out, there's a different thing that you probably wanna do versus you're stuck. Right? I don't know, Adam. What what would you think?

Speaker 1:

I mean, I I feel those are really, really different.

Speaker 4:

I think I think that's spot on because if you're sort of, like, misdiagnosing an illness and they're and taking the wrong kind of remedy, and I think if you're if you're kind of if everything looks like burnout to you, then you're misapplying, you know, the solutions where, you know, writer's block or somebody's more ephemeral, I don't know, like sticking points, you know, have maybe simpler resolutions or or less radical solutions.

Speaker 2:

Burnout in writing is when you don't write. I mean, you you stopped. You can't. You're not interested. No new idea.

Speaker 2:

No no shiny new idea will will be alluring or interesting in any way. I mean, it's it's it's over.

Speaker 1:

And so Right. Yeah. And you you've completely lost the joy of the craft. And I think that, like, software engineers that think that they've lost I I I and maybe this is just my fundamental optimist, but I think that there is such a profound joy for so many of us in this craft. And it it's sad to me when people lose that joy and then don't go through work to rediscover it.

Speaker 1:

I mean, I think that that is like I think it's really, really important that people have joy in the domain and joy in what

Speaker 2:

people doing this, it's also what puts bread on the table. I mean, there are things that you just have to do versus things that you're doing purely. Well, I'm dichotomizing here, maybe a way I shouldn't, but versus things that primarily bring joy.

Speaker 1:

Yeah. Adam, I saw you unmuting on that one. You wanna take that one?

Speaker 4:

Oh, no. No. It's it's an interesting point, Bridget, because you're right. That that necessity, exacerbates it. Right?

Speaker 4:

When you when, or at least for me, you know, when it's like I've I've set a deadline. I have to get it done. And that is not that can be clarifying, but also can be even more stifling. Now I've really got it done do it. Now I'm already a week late, so I've gotta somehow get it done in half the time or something.

Speaker 4:

And and you can kinda talk yourself in circles and make even less progress.

Speaker 1:

Or you can I think in terms of, like, talking yourself in circles and your brain wrapping itself around the axle, I also find that, you know, we have such a privileged existence in software? There's kind of this idea of, like, what the fuck am I complaining about? Like, I am you you know, yes. We have to do things that, to your point, virtually, we've gotta do things that are, you know, not great, but or are, or have some, some kind of road element to them. But by and large, like, we have pretty great existences.

Speaker 1:

We get to solve interesting problems, express our craft. We get we it's ridiculously lucrative. And then but I feel, Adam I don't know about you, but I feel that, like, that can almost work against us where you're just like, well, now I'm actually, like, upset at myself and I'm upset at myself. I you know what I mean?

Speaker 4:

You get very very meta. Yes.

Speaker 1:

Well and I you know, we had someone working at a company that will remain nameless who was getting a, an outsized reward for working at that company. Absolutely wanted to come to Oxide, but what felt guilty that he was staying for a very large amount of money, and then guilty that he felt guilty. And he was having panic attacks making a ridiculous amount of money. And I feel that, like, in in some ways in software, there's an analog for that where, like, why am I having a panic attack? Or not quite not bad in my case, but, like, why am I wrapping myself around the axle when we are so lucky when we are actually getting paid to express our craft?

Speaker 1:

And then, of course, you get back to the, you know it does not help. It it turns into a bit of a loop. Right. So so Brian's psycho. Well, I mean,

Speaker 9:

you to some degree you also reap what you sow right I mean if you go to Amazon on the basis that they pay you know the highest number and not because it's something you actually feel any level of intrinsic motivation to work on. I can very easily see that being more conducive to burnout than say, you know, going to work for a somewhere like Oxide where the problems look far more interesting.

Speaker 1:

Yeah. And I think that you especially, you know, some of the most miserable people I know are people that have taken a very, that that took a handsome pay package and then kind of some of that. And they have them, but they're kinda reaping what they they saw there. I mean, I think you're you're exactly right.

Speaker 6:

Yeah.

Speaker 9:

I mean, that's that's the junior lawyer package. Right?

Speaker 1:

You Totally.

Speaker 9:

You make sure they buy the Cadillac so they they can buy the new

Speaker 1:

That is true. If you really wanna get a a demographic that feels that they are grossly underpaid and impoverished at, like, 600 k a year. That's the, the corporate attorneys are definitely good. But you're right. And and I think that, like, you want to, like I I I do think that, you know, there's a degree to which people are kind of going in their eyes open and they're kind of creating their unhappiness for themselves.

Speaker 1:

But But I think it's like to to unwind from all that, I I think to, I I wanna get back to some of these software analogs. Adam, because when when Bridget was talking about, like, doing these things that are kinda off to the side, a bunch of things in software came to my head. I don't know if you had some similar kind of ideas.

Speaker 4:

Oh, yeah. I mean, but between, I think your your analog your discussion of debugging infrastructure, I thought was so spot on in part because some sometimes those are the areas where I suffer personally from writer's block the most where it can it can feel like, is this the right thing to be working on? Because it's not necessarily contributing to the customer experience. You know, it's it's several degrees removed from that. But but to your I mean, to your point earlier, it's almost always the right move.

Speaker 1:

Well, and and, I mean, the right time to plan debugging infrastructure is definitely 20 years ago, but the, the second best time to plan debugging infrastructure is today. And there are there are so many times when I feel like that but I feel like there are other analogs run out, like around CICD. Right? Or there are kind of there's operational stuff that we have to do as software engineers that is if you feel stuck, like, go off and write some of that software that is it's, you know, lower consequence software. You don't have to worry about whether and you know that you're making your own world better, But just do that in with with the eye of like, but you gotta get back to the cold base.

Speaker 1:

I think that's gonna be

Speaker 12:

a challenge.

Speaker 4:

It's it's a great point because it's also it's it's sort of straight ahead. It it it takes away the the messy field and it some of it's also lower stakes where you but you can get that, that that feeling of being productive and then kind of nurture that flame back to the proximate problem, the the one that's that's getting you stuck.

Speaker 1:

Okay. You brought up a very good point and a keyword in terms of productivity. Are Bridget, do are there are do writers have the same problem that we we in software engineering have become strung out on our own need to be personally productive in a way that I I feel can be really harmful, Adam. I don't know what they what what you I mean, I feel like we want to be I mean, it's great to wanna be productive every day. Like, that's terrific, and we shall aspire to that.

Speaker 1:

But I feel like so often, at least for me personally, that ends up working against itself. I don't know.

Speaker 2:

Yeah. Definitely. I mean, there's all sorts of must have advice. Like, you must write every day. You must write every morning.

Speaker 2:

You must write a 1000 words a day, and that doesn't help people who can't do that for whatever reason, whether it's, you know, job or whatever else. And it can exacerbate a feeling of writer's block because you're not meeting this bare minimum to then develop your craft or your work or whatever you're doing. So absolutely.

Speaker 1:

So the other thing that again, I'm cheating a little bit because you happen to have left us in the or this for this is in the bedroom, not the office where you are, Bridget. But the you got a rider emergency pack. That's kind of interesting.

Speaker 2:

Probably I've got 2. I've got one in front of me as well.

Speaker 1:

Oh, there you go. Okay. Well, I've been I put plugged in.

Speaker 3:

A little

Speaker 1:

bit of a

Speaker 2:

made it, but I can't see the name on here. It was I mean, it's a bit silly, but it's also I bought it. Right? I think it might have been a Kickstarter. It was developed by it's a set of cards with instructions on them.

Speaker 2:

It was developed by a guy called John someone or other. I'm sorry, John, who is a screenwriter in LA. And you grab this deck of 52 or whatever it is, and it gives you instructions. So, you then have to it's a writing prompt, basically. Right?

Speaker 2:

So I'm put looking at one here, travel. A change of scenery can do wonders. Take your hero somewhere new. That doesn't mean that is the thing that's prototyping. Right?

Speaker 2:

What Adam was mentioning before, that doesn't mean that's Yeah. Magnify, up close, everything looks different. Zoom in to focus on a moment, a detail, or an emotion. And I hopefully that yeah. That's kind of what I was getting at earlier on by talking about craft and really just narrowing in on something to try and see what the problem is.

Speaker 2:

What what are you seeing there, Brett?

Speaker 1:

Oh, I can just imagine a software engineer emergency pack that has got these, like, tests always need to be written. What are some tests that you could write? You know, I I know.

Speaker 4:

I love this idea. My mind is racing on this of the, like, stuck on a problem. Like, how would you dump out those structures, like, in ways that were human readable or ways that you could, you know, pump into JQ.

Speaker 2:

You have to do this now. You know that.

Speaker 4:

Oh, I'm I'm kind of worried about, you know, Brian's productivity now. Yeah.

Speaker 1:

Exactly. Don't yeah. Don't worry. I lost all of my personal productivity on my software engineering emergency pack.

Speaker 4:

Kickstarter.

Speaker 1:

Kickstarter. Exactly. But, yeah, I feel like there's all sorts of things we can kinda go do to get the juices and I think the challenge is, like, how do you get the juices flowing with that it, but still with getting you back again kinda to that cold phase? Because that's I mean, obviously, the idea is, like, you you you can't, you know, use the writing prompts forever. You need to get back to you said, Patricia, how do you kinda get tack yourself kinda back in to where you're ultimately going?

Speaker 1:

Or do you do you have any kind of words of wisdom

Speaker 2:

there? Yeah. It's gotta end. You can't, I mean, you can't just tinker away at the one thing forever. You can't.

Speaker 2:

You've gotta finish it. It. And, you know, whether that's you've got a if it's software, you've got a deadline, you know, external to you or writing might be a deadline external to you in form of a publisher editor waiting for something or just you wanting to move on to the next thing. You have to see the whole. I started my most recent work in progress, my most recent WIP at the end.

Speaker 2:

I wrote the ending. And then I worked backwards, so I could see the end while I was working on it.

Speaker 4:

Don't say test driven development. Don't say

Speaker 1:

test driven development.

Speaker 2:

Some of these analogies don't work.

Speaker 1:

No. No. No. Some of these analogies work so well that actually, I wasn't gonna say there's a whole

Speaker 4:

there's a whole industry there. Yeah. And when

Speaker 1:

you said don't say test driven development, weren't she saying test driven development that entire time? I mean, just for the I this is where it's, like, was that Adam was not actually talking to us. Adam was talking to Adam when he said, don't say did you did you know that you were a good Was I not muted, though? This is embarrassing. I but I do think no.

Speaker 1:

Bridget, there are definitely analogs for us. And I feel like one of the things that I've actually done that I've that I I would say I've done more in the last, like, year or so is writing kind of, like, what is the output that I actually wanna see? And then using that to, like, cut through, cut through decisions I need to go make. Because the other question that that I'm dying to ask you, Adam, and other, other Rust folks that may be on the call, Does Rust make this indecision worse? Because you feel that, like, when you it is such a great feeling when you get to that beautiful way of expressing something in Rust.

Speaker 1:

But sometimes, like, on the way there, I find I can, and this happened to me more earlier than it does now. But I even still, I find that now I find that I wanna churn on the right way to go do it, which I think is broadly a good

Speaker 4:

thing. Yeah. I I mean, I think there's a there's a piece of that, like, ownership in particular, being able to be having to be really crisp about that or or having that kinda influence your design early. Like, it's easy to just unwrap your way to something that works and then fix that later. But but when you oh, you know, for it is in my mind, sometimes I have designs where I've gotten too far along before I discovered that there were some kind of more fundamentally misthought out notions around ownership, and that's where I it kinda get tires spiked, by Rust at times.

Speaker 4:

Yeah.

Speaker 1:

And I think and what I like about Rust, but also what makes it challenging in this regard, I like the fact that Rust is encouraging you to really think about your problem a lot upfront. And it's gonna reward you for thinking about your problem upfront. That you're gonna be rewarded for shifting that cognitive load to when you're first writing software. But then you do wonder, like, can that exacerbate writer's block for software engineers?

Speaker 4:

Hey, Brian. Another part of your tweet that that really resonated for me was you said the pandemic has made this much more acute and and absolutely that's been the case. I I felt that, but how have you you

Speaker 1:

felt that?

Speaker 13:

Just before we leave the, the Rust thread behind, I I just wanna say that, as a, still a relative newcomer to Rust myself, working on my access kit, accessibility library project in Rust. I can I can, totally relate to, Rust making making the the writer's block problem worse because Rust sets the standard where of of we can have nice things where we don't

Speaker 4:

have to compromise

Speaker 13:

on on either, you know, robustness or efficiency, or or, you know, or we can have an elegant abstraction that's also efficient? So I I feel like I have to meet that bar. So

Speaker 1:

Yeah. I feel like it's kinda like, alright. Like, we're actually not gonna be writing prose. You're actually gonna be writing poetry. You're like, oh, god.

Speaker 1:

Poetry. Like, I felt like I was I was struggling with prose, and now I gotta write write poetry. Which actually does bring to mind the and I many years ago, I interviewed Arthur Whitney. Have you met Arthur, Adam? No.

Speaker 1:

I haven't. Oh, god. Arthur's amazing. So Arthur is learned APL from Ken Iverson, developed has developed several of his own APL derivatives, developed a, a language called K. Really interesting guy.

Speaker 1:

But for Arthur is very into the aesthetic beauty of software. And, I was asking him what he felt the best analog for software was.

Speaker 3:

So it's a good kind of

Speaker 1:

a question. It's coming it's kind of interesting to ask. I you know, I'm not even sure what my answer would be, but, you know, people talk about a biological system or, you know, people talk about mathematical system or an engineered system like a bridge or I don't know, something like that. And Arthur says, best analog for software? It is poetry.

Speaker 1:

And I my my brain literally detonated. Like, unfortunately, the recording of that interview has not yet has never been made available. But there's, like, a 45 second pause as I, like, seized up. I was not waiting. I was not expecting to get poetry.

Speaker 1:

But now I'm, like, realizing, like, actually, maybe Arthur really understood something very deep that I of course he did. That, that I was missing. But yeah. I mean, that to your I think that, Rust, because you feel that you've got a great way to express things and that I like what you said about, like, Rust says we can have nice things. So I want I it's now incumbent upon me to develop one of the nice things.

Speaker 1:

But Adam, I wanna get to your question because I thought it was a really good one about why I think the pandemic has made this more acute. I mean, I'd love to get your take on it too. To me, it's pretty clear that the you know, we are we've got a lot more opportunity to be in our own heads in the the during the I mean, we don't have any of the the accoutrements of the workplace. We don't have you know, we're not walking the lunch together or we don't have the commute. We don't have these these little kinda doodads that on the one hand were not, like, directly related to work, but on the other hand, it served to break up the day, served to get us moving in a different direction, served to get us thinking in a different way.

Speaker 1:

We don't have any of that. Like, we are just, like, by our lonesome in a room, in a room shared with our spouse in some cases. I feel Bridgette and I had this idea that we were gonna share the office that she is currently in.

Speaker 2:

That would have been insane.

Speaker 1:

That yeah. We've realized very shortly. And also, like, Bridget accuses me of being loud, which

Speaker 2:

I didn't accuse you.

Speaker 1:

Fair enough.

Speaker 4:

It's the statement effect. Hey. Wait.

Speaker 1:

It's an observation that I'm loud. And I, Steve Tuck, Oxide CEO also, maybe a little bit loud. And Steve and I, when we speak together, are are probably a little bit loud. Anyway, we it's very hard to share a house with anybody with me. So I'm so sorry that you had the what you had to endure.

Speaker 1:

But we're all, like, you know, we are in this environment where it's it's this kind of this raw environment where I feel it's easier to get wrapped around the axle mentally now than it ever has been. I mean, do you disagree,

Speaker 4:

Adam? I think it's absolutely the case. This it's easier that you don't have these moments of of kind of forced quiet, forced meditation where I mean, not that like taking BART or the N train in San Francisco is that meditative, but it's still kind of separating you from your screen. And then, the courses you're you're also separated from. Right?

Speaker 4:

Like, I I think you mentioned lunch or walking to lunch or just the, you know, we're surrounded by great colleagues at least, you know, I'm I'm fortunate enough to. But, I don't know when they're idle. I don't wanna bug them. But if I Yeah. If I see someone walking to go get a cup of coffee, I'll I'll go tag along.

Speaker 4:

I know that they're not busy. And, it's tough to recreate that. And I I I'd also love to hear from folks who are sort of remote by choice, how they get through this. Because they they must have figured out something I'm I'm still working to figure out.

Speaker 10:

So I have a question about the okay. Sorry about this, but this is kinda like getting to the core of what what do we mean by writer's block. So I have this idea that if you are working on software and you have requirements, like, you know where you're going and maybe you get and maybe you get stuck, then it's like, so do we, you know, like, I need I need something to bump me out of my local minimum. I need something to, like, agitate. And and I feel like that's what Adam is talking about.

Speaker 10:

Like, the the pandemic took away those those things that could agitate your mind out of being stuck. But something, and I'm I'm really curious to get Brigitte's take on this is, if there is no requirement, if it's like you're staring at the blank page and your requirement is write an engaging novel, then I think that the pandemic may have had the opposite effect. I certainly found myself stuck in my head, like you said, Brian, You're kinda like you. It's just you in silence. And and the result was, oh, these are the million things I could be doing and, you know, pick 1 and just do it.

Speaker 2:

Yeah. I, I I have to add 3 children and 2 cats to the mix. So, I was unfortunately, I mean, I'm being a being a bit facetious there, but being yeah. Okay. I'll backtrack.

Speaker 2:

I create those moments. Yes. There is no deadline. But that's only for any writer's unpublished work as soon as you're published and you wanna keep publishing, you have a lot of deadlines, and you have to, you know, write a lot at a lot faster pace. So I have always created those, agitating sort of agitates agitations.

Speaker 2:

Excuse me. I'll go to conferences whether they're online or in person. Ideally, in person. I'll go to writers, groups, talks. When writers do school visits, if they're writing for children, that's a huge part of connecting with why they're doing the work.

Speaker 2:

So, yes, there isn't always the same sort of external deadline. But if there isn't, I, for 1, absolutely have to create that to feel a purpose in what I'm doing. So I don't know that I'm really answering your question, but I did find being in the pandemic and not having the ability I'd I'd actually just got back from a conference when the pandemic started. Started. Not being able to do those things that fuel the tank was really difficult as well because even though writing's pretty solitary, it's ultimately a shared product.

Speaker 14:

I I gotta echo the conference thing. I love going to conferences. And I'll often have breakthroughs and completely unrelated stuff while I'm at a conference.

Speaker 2:

Absolutely. Yeah. Yeah.

Speaker 1:

Totally. Honestly, it's Yeah. And Sorry. Go ahead, Matt.

Speaker 9:

Yeah. And just, you know, to add to that, like, when I'm writing software or hardware or anything, the times when I find I'm most productive are the times when I've got, you know, a large variety of different things to task switch to. And so if in the morning you're you're writing software and you get stuck and then you're designing a circuit board in the afternoon and then somehow there's you know people are lighting things on fire in the parking lot for the evening or something. Right?

Speaker 1:

You

Speaker 9:

know, you like, it's a very broad ranging set of things, but, you know, when you're in the office, at the very least, you know, you get things which tend to feel like they're producing wins, and during the pandemic most of those agitations are things like oh go walk the dog which while you might be able to consider that a bit of a win isn't

Speaker 1:

Totally. And I think that I very good point about kind of needing the, these different ways of kind of pulling your brain and how we have have missed those. I mean, I feel, Tom, just to your point, about missing the conferences, this is part of the appeal of Twitter spaces for me. This I mean, this is does kind of approximate some aspects of a hallway track that I really miss. Like, I really miss some of that I mean, at at conference, it's always the hallway track that is what's most compelling.

Speaker 1:

And I do miss that. And I think it is important because we get some of our greatest ideas from from being kinda pulled in that direction or different directions. And then you gotta flip it in the I think this is kind of the the the riddle of both software and writing is ultimately, it is a solitary act. And even software, as collaborative as it is, is ultimately a well, okay. I did boy.

Speaker 1:

Don't say pair programming. Don't say pair programming. Don't say pair programming. It's ultimately a solitary act. I've never personally, I I don't know.

Speaker 1:

Adam, have you been here programmed?

Speaker 4:

You know, I did a little bit with our with our former colleague, Eric Schrock, when we were building, the the facility that we referred to as BrainSlug where we would, slurp data from 1 system, slower to our storage product. Yeah.

Speaker 7:

Can I can I interject and sort of, like, push in a different perspective? I guess so we're talking about burnout, and we're making parallels to writing literature versus writing software. And I've definitely experienced burnout, and I've definitely experienced being in positions that I had to write literature in order to justify the software that I write. But I sort of, I mean, I wanted to, like, interject this a few minutes ago before Brian brought out this comment that software is ultimately a solitary act. I really I really disagree with that, but I think I think you're bringing up something really important about pair programming doesn't work or work or whatever.

Speaker 7:

But so let me let me let me let me give a little bit of context. So I feel like software ultimately, a lot of software development doesn't happen on in the code editor. A lot of software development happens in the Google Docs, in Quip, in Confluence where there is planning and trying to figure out how to do cross functional work and make sure you're on the same page with the person who's trying to manage you and whatever it is. But so that's one thing. So that's but but but the more important thing is that I feel like writer's blog if I wanna make parallels between writing software and writing literature, to me, it seems like the person who writes Game of Thrones or writes a really big novel or whatever, they always benefit from having an editor.

Speaker 7:

So they come up with a raw draft. They give it to other people. They review it. They chop some things down. They write some comments and so on.

Speaker 7:

And the parallel that we have to that in software engineering is not pure programming, which is very synchronous, but it's code review, which is asynchronous. And I'm trying to bring up this point that does code review bringing in somebody else who is who genuinely cares about the, pool request you're trying to submit, who has the bandwidth to care. Right? If you have somebody who cares and has the bandwidth to care and you involve them in the code review, does that sort of, like, push out of the boundary of software being an activity that is exclusively inside the head of 1 individual person, and, you know, the weight of it, you know, really overwhelms the individual person. And if you have it you know, the code review would give give it sort of, like, a iterative process so that then I don't feel like working on it, somebody else's reading what I wrote yesterday, and they're providing really good feedback.

Speaker 7:

That would keep me motivated in, like, pushing the next batch set. You know?

Speaker 4:

Yeah. I mean, I think what you're describing more broadly is is collaboration. And for me, at least, during the pandemic, it's taken me, you know, like, 12, 18 months to figure out that, like, I shouldn't be working on projects where where it is deeply solitary. I still agree with Brian that, like, the actual committing of characters to editor is a solitary activity. But, you know, I think that finding those those partners who you're working on, whether it's through code review or handing things back and forth or debugging problems together or even pair programming, I mean, I think that's a a good way to shake yourself out of those writer block moments.

Speaker 1:

Adam, can you hear me? I feel like you can

Speaker 4:

I can't out? Yeah. You're back now.

Speaker 9:

Yeah. Yeah.

Speaker 1:

Yeah. I'm not so the

Speaker 3:

what's going

Speaker 1:

on in those spaces.

Speaker 14:

This collaborative thing is an interesting, I don't know, contrast between artist and engineer. Because how many collaborative artists

Speaker 6:

do you know?

Speaker 14:

So it's it's it's writing code and I know a lot. I know a lot. Like, if you're a music producer,

Speaker 4:

and you have not brought

Speaker 1:

them into one of our spaces.

Speaker 7:

I only have a very limited bandwidth, so it's not like I also don't wanna, like, take too much space. But I don't think, if you're trying to make parallels between creative processes and what is known as art versus software engineering, which is not known as art, but it is a branch of art. It's just not being treated like that. Then there is a lot of things that we're missing. Yeah.

Speaker 7:

I don't think any of the things, like pieces of literature or pieces of music video or pieces of song. Just a film. You know? A film, you see the credits. If you put together a credit for, like, a software like w c, traditional, Unix utility, how long would that be?

Speaker 7:

Right? It's it's a collaborative activity. But, like, not not trying to, like there there's more immediate points to be made. I think right now, the software is so complex. And if you're trying to push forward in the ecosystem, whether it's completely new operating system, if it's a new platform like Fuchsia, if in a existing ecosystem like, Darvin or like Ubuntu or whatever it is, it's inherently collaborative.

Speaker 7:

Like, you're you're digging yourself in a hole if you're trying to pick up a domain to extend an ecosystem forward. Hardware and software, they're all

Speaker 1:

the same. So

Speaker 7:

If you're doing solo work, I I I never wanna sign up for that. I never wanna get paid doing solo work in some low level tool, whether it's compiler, whether it's kernel, whether it's PCB,

Speaker 5:

none of that.

Speaker 1:

So what I've so in sorry. Twitter Spaces has just been enjoying this absolute freak out for the last 3 minutes. You've had said so much that I wanted to contribute to, and I end up and I I can't even tell if Adam is here right now. It's it's Here.

Speaker 4:

I can hear you.

Speaker 1:

That's funny. And when you speak, my little icon shows that I'm speaking. So well, Twitter Spaces is showing us that software ultimately is collaborative. I so totally agree. What I mean when I said it's ultimately a solitary activity, what I meant is ultimately the what goes into an editor is gonna flow out of one person's fingertips.

Speaker 1:

And it is, of course, very collaborative. And I think you made a very good point too around code review and the importance of and, you know, we we're very lucky to have a colleague who I feel is extraordinarily gifted with respect to code review. And, Adam, I don't know how much how many, of your code that, like, Cliff has gone into, but it it

Speaker 4:

Not that much, but you're right that he is he'd I mean, I think it's very easy to do a bad code review. And he is someone who really breathes in the entirety of the problem and helps you boil down to the essence.

Speaker 1:

And he's just got ways of saying, hey, have you considered, you know, interesting use this. Have you considered appraising it this way? And or, you know, have you and questions that are not criticisms or kind of gotchas, but, like, actually, like, really helpful editing kind of remarks, you know, that are, it's me. I it's a collaboration that I've really valued. And I wish I could return the favor.

Speaker 1:

I don't feel I'm a very good code reviewer. I try. I just don't feel like I'm nowhere near that good as a code reviewer. I really admire, and have really benefit from it. I feel like my own software, I've I've benefited from that relationship.

Speaker 1:

So I just wanna make sure that I'm on the record emphatically and unequivocally that there is a there's a lot of collaboration to software. But, ultimately, each of us as individuals must ultimately write our own software. And that is part of the challenge is that that that that's the in that friction. So I think a lot of really interesting dynamics.

Speaker 7:

Yeah. I guess I would wanna interject another anecdote. Since not this summer, but the summer before that, one of the blockers for adoption of Rust at Google, as far as I remotely know, was lack of code triggers for Rust. Yeah. Because there's very strong code review calls for Google, whether it happens to whether it happens through Garrett or whether it happens through whatever other code review system they have.

Speaker 7:

And you know what? I really feel I I appreciate that.

Speaker 1:

I I appreciate that. Clint is an ex Googler, though. And as an ex Googler who had a lot of frustration, I don't think I'm speaking out of school to say that he had a lot of frustration getting Google to accept Rust. I think he would get a a deep belly laugh that Google's problem having now driven Rust stations out of Google is that they don't have enough people to review Rust.

Speaker 7:

So you gotta I guess, like, there's 2 things. One of them is the idea of celebrating the code review culture That's 2 2 separate problems. So at the time that they were internal docs about, not the internal, but many many projects, like internal and external within Google demand for us. You know? So at the time that it was documented that we need more code reviewers, there was this situation happening with Mozilla.

Speaker 7:

There were a lot of Rust people in the market. Everybody knew that. And I feel like I mean, I don't know how industry operates in terms of hiring and in terms of firing. But if I was if I was if I had the leverage to hire people and and if I had infinite budget, which I sort of assume Google has and subdivisions that Google, like different product areas, different products, they have that. So what happened when there were all these Rust people in the market, and there was it was internally documented that we need people who can give solid code review.

Speaker 7:

Like, forget about people who give bad code review. There are a lot of I yeah. If you're in a bad corporation, if you're

Speaker 3:

in b corporation and there's a lot of

Speaker 7:

people who and there's a lot of people who potentially can give you code review, yeah, you're gonna encounter a lot of people who are gonna, like, not give you detailed feedback about what you're trying to achieve, but they're gonna be, like, a soft formatting, like, not. Right?

Speaker 1:

Yeah. And I think I mean, to to kind of, I mean, I I you you can spend, all night reasoning about why Google makes the mistakes they make.

Speaker 3:

But I

Speaker 1:

do think that there there's an interesting kind of question to be had here about this role of the the the editor, or the code reviewer in terms of unsticking ourselves. Bridget, I know one of the things that that you do, you've got these writers groups where you edit one another. What role does that play in terms of of getting folks unstuck or kind of fluid? Because you have the same dynamic.

Speaker 2:

Yeah. I mean, it's fresh eyes. It's it's different. People, I I know people who have several different groups for several different functions. So someone might have a group to read the entire novel for, you know, just flow.

Speaker 2:

Someone might have another and they might have another group to work on character or plot or, you know, one aspect of writing only. But it essentially boils down to being fresh eyes. And also if you are writing to for a marketplace, is this, you know, is this marketable? Is this meeting the requirements according to the publishing industry of, say, you know, this is a young adult book. Is Is this hitting the targets in in various ways to be appealingly young adult to someone who's gonna buy it at a publishing house.

Speaker 1:

Yeah. And I feel that we do not have I feel that often code review is this kind of one channel that we put all review through. And I I don't know, Adam. I I I feel that assuming you're still here because

Speaker 3:

Twitter is just like it it Twitter I I wanna take a video of what I'm

Speaker 1:

seeing on my screen right now. I am seeing in a loop, Adam Leventhal, accept that your offer as a cohost. Just in a loop, the dialogue box post up and then it then it goes away, and I can't see

Speaker 4:

you.

Speaker 1:

So I assume you're here. I'm here. Thanks. Alright. So, I mean, what do you think about about the British comment in terms of having different writing groups focusing on different kind of elements?

Speaker 1:

I don't feel we really do that.

Speaker 4:

Oh, you know what? I think we do a little bit actually unintentionally. This gets back to, your anecdote about Brigid reviewing your tweets, which is to say, I definitely go to different people for different kinds of reviews. And I and I think back to a colleague of ours at Sun, Dave Powell, who was an exceptional code reviewer.

Speaker 1:

That's good. Yeah.

Speaker 4:

And in particular, because he would, again, really wrap his head around the entirety of the problem. And I'll tell you, when I didn't want someone to wrap their head around the entirety of the problem, I would not send it over to Dave.

Speaker 1:

That's right. He's he's like the, he's the building inspector that you know not to draw. Yeah. Yeah. Yeah.

Speaker 1:

Right.

Speaker 4:

When when I knew I was doing something a little bit fast and loose, you know, when I didn't when I didn't necessarily want deep collaboration or or I didn't wanna have to do this thing again because it was kind of a grind. And I I knew I had done it kind of the b plus way, not the a plus way. I wouldn't send it over Dave. Or people with different levels of ex different kind of areas of expertise or, you know, I'm sure there are some things that you send over to Cliff. Some things that Dave and I sent over to Cliff early on in the creation of drop shot, our our HTTP framework, you know, when we're running into really tricky, you know, Rust, trait issues, for example.

Speaker 4:

But then, you know, other people would call on for other expertise. I don't know if that speaks to what you're good at.

Speaker 1:

Well, yeah. And I will tell you that I think the mistake that I have made is not wanting to impose on anyone. Because you may kinda made this point earlier about the a challenge of the pandemic is not really knowing what someone is doing right now. So you don't know whether, am I bothering you while you're in this flow state, or are we both walk walking to lunch together? And not having that, I think, has deprived us of us I assume this kinda, like, looser conversation.

Speaker 1:

And I feel like I wish on a couple of things I had gone, say, in this case, to Cliff earlier and gotten his perspective earlier because I would have done it a different way sooner. And see, we can't even have a really good insight about a way to do it. My god. Of course, I should've done it that way. And we I I feel we've lost a bit of that in the pandemic.

Speaker 8:

I went to grad school during the pandemic, and so my professors came up with a whole bunch of really creative ways to try and solve this problem, hours, they would sort of just sit in one place and, like, you could go up to them and you could talk and they would be, like, writing their papers. But they would sort of wander around when they wanted other people to talk to us. So that was, like, a really great experience.

Speaker 1:

Did that work? Gather. Town? Did that work?

Speaker 2:

Yeah. For me,

Speaker 8:

like so I don't know if it worked for everyone, but for me, it was the thing that, like, got me into the programming languages community because

Speaker 1:

I was Interesting.

Speaker 8:

Joy to, like, nerd out about Lisp. So I think having that kind of community is so important when you're, like, trying to do something really hard. Like, this whole conversation makes me really excited as someone who, like, was doing research for a while because, like, we're writing code and writing all of the time. And one of the things that we would do is we would really frequently like, oh, I'm stuck in how to explain this. Well, let me try to write a little bit of code, like an example.

Speaker 8:

Oh, I'm stuck on the example. Let me go back to the, like, the paper that I'm writing, and being able to switch between those two things. I guess, an analogy when you're in industry might be documentation, but, like, I found that super helpful.

Speaker 1:

That I think is really good advice, and I think that's that's kind of persistent advice that we've heard a lot is, you know, switching it up. You know, Ryan Tazeski had a good reply to my tweet. I'm not sure if you saw that one, Adam, where he it's something that I definitely had had to do is sometimes you just have to say, like, hey. You know what? Today, like, today was not great, and I gotta get a good night's sleep and get back to tomorrow and not get too dispirited about it.

Speaker 4:

No. That that's definitely been, especially I mean, early on in the pandemic, you know, suddenly we're without childcare and a 3 year old on our hands. And, I mean, getting to flow state was very challenging, as you might imagine when Yeah. It wasn't even the constant interruptions, and they were constant, but it was the constant threat of interruption. Any any halfway through any thought, there might be a a 3 year old demanding one's attention.

Speaker 4:

And I think like Ryan, you know, you kinda say take the wins that you can. And, and also for me, you finding something I can do that that gives me a win. And it might not be the highest priority thing or the top 3, but it's in the top ten and maybe that's good enough.

Speaker 2:

Yeah, Adam. As a small aside, when I, was writing my PhD dissertation and heavily pregnant, I knew there were days when I would not be able to do anything. So I set aside a whole bunch of time for writing my bibliography, which was mind numbingly boring, but I could do it. And that really helped.

Speaker 1:

And I I I will say, and I don't think I would just say it because of current company, but, having a supportive life partner in this regard has been also really helpful. I think that, Richard, the what the endeavors that we have are similar similar enough that, like, I know that, like, if you're in a a state of flow that, you know, yeah, I'll go take the kids or it's certainly vice versa. The and, you know, seeing the value of doing something like the the clay studio and so on. I think that it really it helps to have someone around you who is and god knows it's not your toddler unless you've got a toddler. And I'm not talking about your toddler.

Speaker 1:

I'm I'm talking about just all toddlers. I I feel I have been during the pandemic, I have had to counsel you more than once. Like, it it definitely does get better. It does get better. It does get better.

Speaker 1:

I don't know you know that from your older son, but

Speaker 4:

Still waiting. But yeah.

Speaker 1:

Still waiting. I know. I know you're gonna hold me to it.

Speaker 7:

Who said take the wins that you can?

Speaker 1:

Yeah. Take the wins that you can. That's right. You gotta take the wins again.

Speaker 7:

Adam, was that you? Yeah. I'm gonna use that.

Speaker 1:

I think we got

Speaker 4:

yeah. Yeah. Go ahead, Brian. Sorry.

Speaker 1:

No. No. Go ahead. I I was just saying,

Speaker 4:

I I've counseled some some colleagues of mine just saying, you know, the mantra and it's sort of loser talk in one sense. But what I tell myself is like anything is something. Right? If I can have there were times during the pandemic when I'd be on childcare for 6 hours a day and working too and then trying to muster some energy at night to work a few more. And there, if I could go to bed just having done something, you know, it it it was and carry that even if it wasn't the most important thing.

Speaker 1:

And yeah. Sorry, Bridgette. I can see you're muting.

Speaker 2:

Yeah. I mean, just to, bounce off what Adam said, I had earlier criticized blanket advice. Like, you must write a 1,000 words a day. You must write it from 9 AM to 10 PM or whatever. But having parameters that you set or goals that you set for yourself can be hugely liberating because you can say, look.

Speaker 2:

I I did the thing. I achieved something. So

Speaker 1:

Yeah. And then, like, kind of giving yourself then permission. I think there's nothing the pandemic has made hard is that we have no boundary between our work life and our home life. Then, hey. I achieved this, and now I'm gonna give myself, you know, permission to go, you know, watch a game with the kids or whatever it is.

Speaker 1:

I'm gonna give myself kind of the I think that that's also important is to to time box yourself in that regard.

Speaker 7:

I guess I wanted to put in some call to action, but it's not like I'm gonna do it. Maybe I'm gonna do it too, but I don't have a blog. So here it is. So there's a lot of blog posts for, like, how to become a better hacker or how to become a better software engineer. I haven't seen any blog posts around how to be a better code reviewer.

Speaker 7:

Yeah. Because that's something that can push you out of the writer's block. I guess there is, like, a common acknowledgment that software is a collective thing even though in the end, you're gonna type in that 2, 3 lines that are gonna have, like, very big impact on the entire ecosystem. We all acknowledge that. But in the end, you gotta be a good code reviewer, and you wanna bring in other people who wanna be code reviewers up to speed faster than whatever it is right now.

Speaker 7:

If we wanted to write a blog post right like that, what would be the highlights? Or, I mean, I we probably kinda discussed this, like, in the Twitter spaces, but I really wish we could see some some blog post right there. Like, how to be a better code reviewer or, like, anecdotes around code review scenarios, hopefully, with links if they're open source around why this comment from this person was an opening towards this block that I had. Like, 10 items, 5 items from 5 people is already 25 good coach view practices. You know?

Speaker 3:

So I do have a blog post exactly like that up right now. It's linked on my Twitter profile if you wanna take look at it. I think I'm pretty good at code reviews. I don't know, but, I have

Speaker 7:

Let me try it.

Speaker 3:

What I think about code reviews and put it in a blog post. It's probably the only blog post on my blog, but I did a talk at

Speaker 1:

Kendall, that that sounds awesome. I really wanna go read that. I If Twitter space had made it easier for me to go to your blog entry right now, I'd love people to drop it as a tweet.

Speaker 4:

It's it's right there on the I I pinned it. I Thank you, Kendall. Mhmm. That's awesome.

Speaker 1:

I will tweet.

Speaker 12:

Well, when when you have several years frequent blocking problem, for example, to me, in the last few years or few days, is the this, sorry. The business business circle when you have, okay. When prevent to making decisions and move forward with your development, is when your code, you think your code could be better and you enter in a refractory loop of your code, you have rating in the last few days, multiple attempts to improve your what you do, and you can get out of this busy circle and so many. You create a class, you create a function, an absolute function and structure, make the process easy. This kind of coding and repeating code, and you make very difficult to move forward and give up from this attempt to continue to to to try to bet better.

Speaker 12:

In this writing blogs, I know how happy I was in the past when I less know about software engineering. The decisions was very easy. I I don't know. This just happened to me.

Speaker 1:

Well, I think if the and this is a point that I was making earlier too, that I feel like in some ways, the more you know, the more crippling it can be because you and, also, you've then you've seen some of these decisions end badly, which gives you then makes you reticent on some of these things. You don't wanna incur technical debt and so on. So, no, I totally agree. Kendall, I, I would love to pick up code review as a separate Twitter space topic. I think we should pick that up next week.

Speaker 1:

Adam, I don't know what you think about that.

Speaker 4:

I love it. Let's do it.

Speaker 1:

Yeah. So, Kendall, would you mind coming back next week to talk code review?

Speaker 3:

Yeah. Of course.

Speaker 1:

Alright. Yeah. Let's plan out plan on doing that. And, Bill, I noticed you what you're trying to get in here, and then I think we wanna wrap it up.

Speaker 11:

Yeah. I was I was just gonna say burnout. I mean, yes. Burnout does affect software engineers to the point where you have to do anything you can to train, fight your way back to flow. You know, I I wound up, deciding to learn Rust because I was not going, you know, my day job was all fortran.

Speaker 11:

So I was like, at least I had a side project that I didn't feel guilty about walking away from, but then I wound up rust wound up by inadvertently started sharpening my skill set as a result and then decided, you know, I was burned out on my last job to the point I needed I I needed a change of scenery, so I went from old school fortune and Python on Linux systems to doing dotnet on Windows Servers and it it it was like just taking a plunger to the block. It was gone. You know, 6 month, you know, like, 2 months in and I was just, you know, pushing code to production every day and it was glorious. And but now I'm back in c plus plus land, but, you know, sometimes you have to do what you have to do.

Speaker 1:

Oh, well, this is a really good point because I remember when, you know, when I I and actually right before I met Bridget, right before Bridget beat me about Altrais, I had moved up to San Francisco, and I didn't realize how unhappy I was living in a share house in Denla Park until I moved up to my own place in San Francisco and realized, like, wow. I was really sometimes you don't see how unhappy you are when you're kinda surrounded by it. And I do think you're right, Bill. Like, sometimes you gotta just change it up and make a big change and, and just have that confidence that you're gonna rediscover that joy, rediscover that competence, rediscover what brought you into the discipline.

Speaker 11:

Yeah. Rediscover why computers were fun. You know, I looked I found a photo of myself, as a truck, you know, being hand unwrapping the Commodore 64 under the tree, and I'm like, you know, it's like young me smiling, thinking this is a good thing. And then the other there were certainly times during my career where it's like, oh, my gosh, computers were a mistake. But now I think I'm back to enjoying computers.

Speaker 11:

And I, you know, I I I I have had more days of flow than I have without flow in the past week. And, yeah, I'll take it.

Speaker 1:

I'll take it. Absolutely. Celebrate the wins. Alright. Bridget, do you have any any final words for us now having heard a bunch of software engineers sound off on the the parallels?

Speaker 2:

I hate to say I don't. It's been a really interesting discussion, seeing the parallels, learning a bit about how yeah. I won't ramble. It's, no final words, but go get them.

Speaker 1:

That's really good. That's good. Hey, Doug. Those are good final words.

Speaker 7:

Writing is writing. If it's if it's software or if it's code.

Speaker 1:

Go get them. Writing is writing. Writing. Absolutely. Alright.

Speaker 1:

Hey. Thank you very much, everybody. Really appreciate it. And, Kendall, let's do next time Code review is a great topic. So we'll see you next week.

Speaker 4:

Thanks, everyone.

Speaker 1:

Bye, everybody. Bye, everyone.

Speaker 7:

Bye. Bye. Bye.