In this episode, host Conor Bronsdon talks with Melissa DePuydt, Sr. Director of Engineering at Upstatement. Melissa discusses how her background in journalism has uniquely positioned her to excel in engineering leadership roles. She highlights how thinking like a journalist has enhanced her ability to lead engineering teams effectively, particularly in planning, risk management, and decision-making.
The conversation covers the importance of preparing for disruptions, conducting pre-mortems to anticipate challenges, and incorporating broad perspectives for effective problem solving. Melissa also shares insights on continuously learning and adapting by embracing one's unique background and experiences.
"When I became a product engineer at The Post, I felt like I really had to hide my background. There's definitely imposter syndrome and kind of shame of not having a technical background. But the longer I'm in engineering leadership roles, the more I'm really grateful for my background as a reporter. Because it allows me to make decisions really quickly and gather information and look across context, in ways that I think a lot of engineering leaders often don't.”
Episode Highlights:
00:20 Why do engineering leaders need to think like journalists?
04:46 Preparing for disruptions as an engineering leader
08:44 How pre-mortems work in practice: an example from the Atlantic
12:47 How to get buy in from other leaders when changing processes
17:59 Eliciting buy-in from team members on pre-mortems
22:15 How do we train engineers to think in a team sport mentality?
26:51 Why is career switching a superpower?
Show Notes:
Transcript
Melissa DePudyt: 0:00
When I became a product engineer at The Post, I felt like I really had to hide kind of my background. There's definitely imposter syndrome and kind of shame of like not having a technical background. But, the longer I'm in engineering leadership roles, the more I'm really grateful for my background as a reporter. Because it allows me to make decisions really quickly and gather information and look across context, in ways that I think a lot of engineering leaders often don't.
Advert: 0:29
How do the best software engineering organizations in the world set and track goals. LinearB worked with more than 3000 org staff, effectively track their KPIs and set goals. And March 26th and 28th LinearB CTO. Yishai Berry is hosting a workshop to share those best practices with our fellow engineering leaders. This workshop will delve into the data behind the fact of goal setting strategies elite engineering organizations use successful companies that are using goal setting. Plus provide a free how to guide and reporting slide deck for you to leverage. You can register today at the link in the description. Hope to see you there.
Conor Bronsdon: 1:08
Hey everyone. Welcome back to Dev Interrupted. I'm your host Connor Bronston, and I'm delighted to be joined today by Melissa DePudyt. Melissa is the Senior Director of Engineering at Up Statement. Melissa, great to have you on Dev Interrupted.
Melissa DePudyt: 1:19
Thanks for having me. I'm so excited.
Conor Bronsdon: 1:21
Uh, it's a pleasure having you here. I'm, I'm very excited to talk about what you are diving into as well. Yeah, because you have a background as a reporter and editor, and you've also been a leader of engineering teams at both the Atlantic and the Washington Post, which is a really unique background, I think. Most folks don't work in media, and, it's led you to have this perspective on, like, How engineering leaders need to learn how to think like journalists. Can you unpack that a bit?
Melissa DePudyt: 1:49
I'm a career switcher. I started out as a journalist and reporter. As long as I can remember, I've been writing. I, when I became an engineer, I found out that like a lot of the things that I enjoyed about reporting, and journalism. You still do them as software engineers. And, um, you know, so writing code is a lot like writing a news story. Editing and reviewing PRs is a lot like, editing and reviewing story drafts. Um, so it was very natural for me. With the exception that, you don't have to talk to strangers. And, like, chase down an angry congressman for a quote as a software engineer. So I was like, sign me up. And the longer I have been in product engineering, the more I have become really proud of my background as a journalist. Because at first, when I became a product engineer at The Post, I felt like I really had to hide kind of my background. There's definitely imposter syndrome and kind of shame of like not having a technical background. But, the longer I'm in engineering leadership roles, the more I'm really grateful for my background as a reporter. Because it allows me to make decisions really quickly and gather information and look across context, in ways that I think a lot of engineering leaders often don't. So for me, I think that my background as a reporter helps me, think about situations differently, um, and try to discern the essential context for something versus just trying to wait for more information when I make a decision.
Conor Bronsdon: 3:21
This is really interesting for me in part also because I share a similar background, so I didn't actually tell you this before we came on the podcast to start chatting, but um, my background's in political organizing and communications, so kind of the other end of the journalism spectrum. So it's interesting for you to bring this up because I agree with this. I couldn't see my career unfolding differently because of the unique skills and challenges that were brought to me. And it definitely has informed my perspective on software engineering and software engineering leadership. So I'd love to go a bit deeper into the areas where you particularly see these needs for changes. What would you say are the keys to bring over from your background that you are now leveraging in the software engineering space? Yeah,
Melissa DePudyt: 4:04
I think the first kind of mistake that I see a lot of engineering leaders make is not preparing for the risks and disruptions that you're just going to encounter. It's all gonna be great. This is finally gonna be the quarter where like our roadmap doesn't shift.
Conor Bronsdon: 4:25
Oh man. I have a surprise for you if that's what you
Melissa DePudyt: 4:30
think. Exactly. And the truth is that no matter how well we plan, no matter how well we roadmap, there are always be disruptions. Um, and I think accepting that is kind of a journalistic, the first step in adopting a journalistic mindset, uh, because a news reporter knows that news is going to happen and they expect breaking news to happen at like the most inconvenient times. And a journalist doesn't get a choice in delaying how, how they're going to respond. They just have to respond well. And so I think that's where engineering leaders can, can learn a little bit and, you know, just, you know, Start to plan and prepare for what we're going to encounter in the course of our daily work.
Conor Bronsdon: 5:15
So that high degree of comfort with change and the ability to adapt to it.
Melissa DePudyt: 5:19
Yeah. And knowing that you know, it's not, a journalist's job to prevent the news from occurring Yeah. Um, it's their job to respond well, and I think the same is true for engineering leaders, although obviously we want to be mitigating risks where we can, right. Our job is to respond well and to hopefully create clarity for our teams. And so there are several things that I think that engineering leaders can do specifically to both prepare to respond well and then to respond well in the moment.
Conor Bronsdon: 5:49
I think that preparation piece is really crucial, right?
Melissa DePudyt: 5:51
Yeah, it's, to me, it's, it's like an iceberg. What you see is C is someone who is really good under pressure and good at making decisions, and what's underneath the surface is just this wealth of preparation and mindset management, and yeah, just putting yourself in the position to anticipate curveballs, and when you are better prepared for like any one type of curveball, you're actually priming your brain to be able to handle all types of curveballs.
Conor Bronsdon: 6:20
Yeah, a mentor of mine, kind of referred to it as looking around corners and developing that skill. Yep. And I think that's something that is, is really important. Um, you know, regardless of the type of leadership, uh, challenge you're taking on. But it's also true for individual devs, I would even say, where it's like, you are, really, what you're doing is you're being an excellent problem solver with unique skillset. Yeah. And so like that ability to see what's the potential problem coming down the line, how will this impact other things we need to do is really important.
Melissa DePudyt: 6:47
Yeah, so a lot of newsrooms will have, multiple kind of, like, processes for managing different types of news, because most journalists don't just roll up to the office on Tuesday And they're like, well, we'll see what happens today. Hope I have something to write about. A lot of news organizations are kind of extensively planning for news coverage and trying to really remove the number of things or reduce it. The number of things that are, um, truly breaking news moments, um, and when those things do occur, they have plans that they activate and processes specifically for breaking news. And I think that's, um, where. Engineering leaders can start to think like journalists by saying what are the disruptions that are likely to occur? How can I start to monitor for those things now? And how can I prepare for how I will respond when those things happen?
Conor Bronsdon: 7:45
Can you maybe share an example and talk through how, that would be implemented if you were an engineering leader?
Melissa DePudyt: 7:51
Yeah, I personally am very anxious. I've never had a problem, um, asking myself what could go wrong and coming up with Uh, with answers. To put it into practice, I really like running pre mortems with my team. Um, and so a pre mortem, um, is similar to a retro, but the opposite. In that you are asking your team to kind of, reflect on a period of time and kind of say what went wrong, what could have gone better. But with a pre mortem you're doing it before you, before anything catastrophic happens.
Conor Bronsdon: 8:21
So, can you dive a bit more into that? How would I actually go about that?
Melissa DePudyt: 8:25
You assemble your team and you ask them, put yourself in the perspective of we're in the future and we're looking back and assume our project has catastrophically failed. What went wrong? And you essentially ask the team to generate plausible reasons for failure, and then come together as a team and start to identify, all right, what are the things that are likely to occur and how can we mitigate them? And so when you do this, you are using what research calls prospective hindsight, which is like deeply an oxymoron. Prospective hindsight, um, the research shows it actually makes you 30 percent more likely, to correctly identify the causes of failure, before they occur. And so in starting to think about those things before they happen, you can put together the plans and monitor and say, what are the signs that we're going to, that we're going to look at that will signal, that production is down or will signal that we need to shift, um, our, our roadmap. And so you can start to, put plans in place that you can activate when you notice those risks occurring and respond faster.
Conor Bronsdon: 9:37
So, for example, would you look at this of, okay, we have a major feature rollout we're doing, and, you know, it's coming out from under feature flag if you're using it, and we still have concerns. Let's do a pre mortem to evaluate where there might be challenges and maybe we make additional fixes before we're rolling it out, or how would you do that?
Melissa DePudyt: 9:55
Yeah, so, um, when I was at the Atlantic, during the kind of first few months of the pandemic, we were embarking on a front end redesign and re architecture project.
Conor Bronsdon: 10:04
Major project?
Melissa DePudyt: 10:05
Major project. Huge modernization effort. It was a huge win that we, uh, got to do this project, during, um, an election year as well. Cause it was back in 2020. And so before we began on this like massive project, I got together with my team and said, all right, our deadline for launching this is like right after the election in November. It's a really tight timeline. This was maybe in April or May of 2020. So we had six months. Let's assume that we do not, that we haven't hit our goal. Like we get to November and things have gone wrong. What caused us to slip our deadline? And so what the team came up with was like a number of things that were, production like goes down and we have to like change our focus or, A new mandate from the leadership came and we have to
Conor Bronsdon: 10:59
That's never happened.
Melissa DePudyt: 11:00
That's never happened, no. You want to identify those things in advance. Because really, I think the engineering manager's job is not to, like, prevent everything from happening. But to be able to respond well when those things do happen. And so a lot of those things did happen, um, in the course of that project. But because I was in the position to be able to say, no, I was anticipating production going down. I was able to build in a couple of weeks for like extra time. Like if that happened, I added that as kind of buffer in our timeline when I was planning. What we could like feasibly implement. Um, so another example of the things that we identified was like, yeah, QA. We're, what if we're just like behind and we're not, um, you know, we're not as far as we want to be when we're like testing things. Um, and so I worked with our QA team to say like, what are the ways that we can incorporate the QA team much earlier in the process so that it's not just kind of relegated to this final two weeks right before launch. Um, and so in identifying those things, I was able to more effectively manage them. And we got to launch, um, it was one of the best launches I've ever had the pleasure of like doing, just because we were so prepared, for the unexpected to happen.
Conor Bronsdon: 12:27
Is there a correlation with increased planning accuracy on what you're actually delivering?
Melissa DePudyt: 12:31
Totally, because what a premortem lets you do is say like, what are all of the possible reasons? And so there are those very big kind of like catastrophic things, like again, production goes down, that kind of thing. But it also led us to say, like, what if we overcommit to, uh, to what we think we can deliver? And that caused us to, uh, kind of step back, in a separate planning session and say, all right, we know that we are worried and we have a tendency to overcommit. How do we need to scale back what we're telling our product leaders we will be able to deliver. Um, and so that led us to have this strategy of like, let's under promise, and obviously this is always the goal, under promise and over deliver. Um, but we were really careful about what we committed to, and only committing to the things that we could really confidently deliver.
Conor Bronsdon: 13:27
And that's so great. becomes a situation where you can start to have more predictable, project delivery. And realistically, that's what all businesses want.
Melissa DePudyt: 13:36
Exactly. And that, yeah, that's exactly your role as the engineering manager, is to create the conditions for your team to reliably deliver.
Conor Bronsdon: 13:44
So you're a senior director now, but it sounds like you've been doing this since you were an engineering manager, a senior engineering manager. How do you make sure that you get buy in from other leaders on how you're changing your processes and leveraging these postmortems, or premortems, I should say? Yeah.
Melissa DePudyt: 13:58
I think that it's so unusual to, to have this kind of like intense, Planning for things to go wrong that, um, honestly, it's really easy to get buy in because business leaders, I think, are much more accustomed to like, things are going to go wrong. Engineering leaders, we think it's our job a lot of the time to, um, mitigate and prevent things from going wrong. Um, and so it's really uncomfortable when we're in those situations. Um, So when it comes to like being more proactive and being better prepared, I found that other leaders in the business are like, we want to do that as well. Yeah. Yeah.
Conor Bronsdon: 14:37
I think this is a great example of leveraging the skill sets and approaches taken from other industries to improve how you are functioning as a mentoring leader and how your teams are functioning. But it sounds like there are other insights that you've brought over from your time at journalism as well. What are the other insights that you would leverage for other engineering leaders? Yeah,
Melissa DePudyt: 14:56
So, I think that a lot of what I've mentioned so far, like the premortems, preparing, accepting the reality of unexpected disruptions, um, those are all things you do in advance of something happening. And so when journalists are actually in a breaking news situation, it's It's their responsibility to not just gather all of the information about the event, that's happening, but to really filter through it and in covering the news to, tell readers what the essential context is. So in a lot of news stories, um, they leverage what's called the inverted pyramid. And the inverted pyramid is a very common and classic story form in news that focuses on putting the broadest, like, most essential information up top in like the first paragraph and then gradually layering in more important details. And what happens is that, you know, as a reader reads the story, they get the extra context and so it's not just, um, to use, you know, I guess what's been in the news cycle lately, it's not just that there are attacks, it's that there are attacks in a certain place, and that place has context, and at a certain time, and that has context. And so when we're trying to make decisions as engineering leaders, I think what we can do is, start to layer in additional context that help us make our decision. And so what that looks like is, asking yourself not just like what's happening, what are all of my possible options, but going a level deeper and saying like, what team resources do I have available? What, what are their skill sets? Layering in organizational context and saying what are the, the broader business goals? What are the stories that our company tells ourselves about? Who we are and what matters. And then finally, like the, the personal context of like, what is a decision that you can live with and what matters to you in how you're responding. And so, leveraging this kind of thinking helps us narrow down options, and find a narrative for ourselves. And that way we can make faster decisions because we've narrowed down, based on kind of like these other contexts. Um, what are like feasible options are, and we end up with a short list of approaches that are all good because they're all informed by context, and when we take this other context into account about the team and the business, we also, um, are identifying kind of the factors that can allow us to change our minds, um, because it's okay to be wrong in making a fast decision. If the context changes, uh, we can also change our approach and start to, again, like, leverage kind of that journalistic thinking of, if I am presented with new information, what do I need to update about my thinking about the context of this story?
Conor Bronsdon: 17:55
The thread that I'm hearing throughout what you're saying is limiting of cognitive load under crisis.
Melissa DePudyt: 18:01
Absolutely, yes.
Conor Bronsdon: 18:03
Yeah, and I think that, I mean we pointed to how that can improve your planning accuracy and predictability of delivery earlier, but it's also going to likely improve the quality of your decision making in the moment, and your ability to, to your point, rectify some of these challenges you may have otherwise.
Melissa DePudyt: 18:19
Yeah, I think, you know, a lot of us, I'm totally guilty of this, we get focused on looking at the event that's happening. When we're in a moment of crisis, we're like, what is happening? Production is down. And we're like, but we don't know why. And so our tendency is to wait for more information, and that can actually delay our team's ability to get production back up. So I might not know why production is down, but I might have, like, additional team context that is, that it's in the middle of the night for the team, and so there's not a lot of resources. Like, that narrows down my possible, potential paths of action to be something that is much more manageable.
Conor Bronsdon: 19:02
What's your experience been like when you leverage these techniques, whether it's the pre mortems or other ones you're talking about, to try, like, what's been the feeling from the team members themselves about, you know, these additional meetings, these additional things they're having to do?
Melissa DePudyt: 19:17
I think that, you know, every engineer wants to, like, write good code and have a stable environment where things are not on fire. And I think that they are willing to participate in those meetings because they are directly in service of more focus time, more flow, flow time. And so there's less of, um, kind of like pushback I've experienced because these are really targeted conversations.
Conor Bronsdon: 19:47
So, how are you getting your team to buy in on this, I mean, additional work that's being done in advance?
Melissa DePudyt: 19:54
I think that I get buy in by, um, starting to persuade the team that, if we are more prepared, we will be, um, less stressed. Disrupted in the future when we are under pressure and so wanting in having those proactive conversations, really a lot of the work coming out of it is for the manager to be able to monitor, But it also puts the engineers in the mindset of being prepared for disruptions and knowing that our goal ultimately is not to, to ship exactly what's on our roadmap. It's to build and maintain a really great product experience for our users. And so the most important thing is not necessarily executing exactly the roadmap, but responding well. And it's really stressful for engineers too, when those fire drills happen. And. And so I get buy in by saying, like, you know how stressful, those crisis situations are. If we meet now for 60 minutes, we can possibly prevent a two week, disaster recovery situation.
Conor Bronsdon: 21:03
That makes total sense, and It's interesting to hear you talk about this and how you're kind of adjusting your team's perspectives or at least having them expand their perspectives in some ways. Yeah.'cause you know, we talked about this earlier, but I think we both think that this ability to look forward and and consider potential challenges is a key trait to develop as a leader. And I would pause it that this may also be helping develop your team members as leaders and having them be more of them as mindset of like, how is my individual work affecting. Customers affecting the company. Are you finding that to be the case?
Melissa DePudyt: 21:37
Yeah, absolutely. I think that a lot of engineers think that their job is just to write code, but when we want to think about growing people and stretching and putting ourselves into uncomfortable positions so that we can grow, involves bringing in kind of bigger business context that a lot of engineers don't, like, naturally gravitate toward. And so, again, it's like, it's being proactive about saying, like, how will you respond in, in a moment of crisis? And I think helping people shift from, like, oh, we just have to react to something, to whatever happens, to a more thoughtful approach of like, No, we can actually be deliberate. We can have processes to handle unexpected things. That actually makes people feel a lot more confident knowing that that we have plans in place and it's not just going to be a mad scramble.
Conor Bronsdon: 22:39
Do you think that part of this need to bring in these concepts is a problem with how we train engineers to be kind of individualistic thinkers? Whereas once you actually get out into I'll call it engineering world, usually it's a team sport.
Melissa DePudyt: 22:54
Totally, yeah. And newsrooms are a team sport too. Like, you get a lot of journalists who are like, I'm just a reporter, I just want to go out and cover my thing. But, in reality, it's cross functional work. You know, there are not just reporters, but also photographers, videographers, social producers, editors. And so it's a very similar kind of mentality.
Conor Bronsdon: 23:18
How should we adjust training for engineers to enable this forward thinking about, hey, this is a team sport, we should be kind of thinking around corners.
Melissa DePudyt: 23:27
I mean, I think that a lot of the skills that we, kind of naturally gain as we, you know, move through our careers as engineering, as engineers, as ICs, are the exact scrappy kind of skills. That we have to still leverage as managers. And so I think it's less about training ICs and more about, um, helping ICs understand as you progress, the types of situations you're going to be in. Most of the time you're going to be trying to like, Be in this like scale mode of having an impact at scale, but when unexpected situations occur, we can shift into this other mode that, um, we're actually more familiar with because that's like a lot of engineering.
Conor Bronsdon: 24:16
Yeah, this is a really interesting look at preparation, and the approach you're taking here. Are there any other insights around, preparation or, or, uh, mindset that you're bringing from journalism that you want to highlight.
Melissa DePudyt: 24:28
I think what I just mentioned about kind of having a scrappy mode and a scale mode is something that a lot of journalists, cultivate. The journalists are people too. They don't always enjoy being on deadline. And so a lot of reporters will kind of have, this one set of skills that's much more kind of like investigative and, It's really kind of when you need to tell a story that is deeper and you're digging deep, you're kind of asking questions to get more context. That is in stark contrast to a breaking news situation. When you're on deadline, you have to act swiftly. You have to, focus on just the key details and not like everything about, uh, like the past situations. Um, and so I think that's another thing that engineering leaders can adopt as well and give ourselves permission honestly, to switch modes and make decisions differently when we're in a moment of uncertainty or a moment of crisis. Because at least I've certainly been told that like as a manager, I always have to be focused on growing people scaling and like process. And it's really important when moments of crisis occur. To be able to break from that and to shift into this like scrappy breaking news kind of mindset. And so the way that I use this is, when I'm in the normal course of work, I'm in scale mode. I like to make decisions by building consensus on my team and getting everyone's input, making sure that everyone is aligned. And when I'm in a moment of like, I give myself permission to kind of abandon that. Everyone doesn't need to be involved in giving like their opinion. I need to commit to an approach. And so I give myself permission to shift into that other mode where, it's not where I spend the most of my time, uh, but it allows me to act faster and that then creates more clarity for the team. And that's what they need in those moments.
Conor Bronsdon: 26:27
This is really interesting too in a cultural context because, um, this is It's egalitarian leadership style that you described versus kind of the more authoritative under pressure is something that is, very, it's often seen in a lot of Western countries. So, um, the U. S., Denmark, the Netherlands, for example, very egalitarian approaches. Uh, whereas if you look even at like Spain and Italy, they're, they're more on the authoritative side, or hierarchical might be a better phrase here, let alone like Japan and Korea, where you get this kind of more hierarchical approach to leadership. And so it's interesting to see how. that is to flex at times, depending on the circumstances.
Melissa DePudyt: 27:05
Yeah, exactly. It's a sliding scale. And what I do is like, I apply this in any given situation by saying like, What mode do I need to be in? Because often when you're making decisions as a leader, Um, it is decisions, plural. It's not just one decision, it's often a series of decisions in quick succession. And, and so I will put myself in a mindset and just take a beat and say, What mode do I need to be in? Is this a situation where I need to focus on, um, creating opportunities for my direct? and empowering them? Or is this a situation where I need to be super scrappy and do it myself? Or I need to be super scrappy and make a decision on behalf of the team and guide what they're doing?
Conor Bronsdon: 27:54
Do you have any thoughts that you would share for other career switchers who are So, I'm thinking about how to leverage the knowledge that they have, uh, or how to adjust to the kind of new track they're on in engineering.
Melissa DePudyt: 28:06
I think that being a career switcher is actually kind of a superpower. Especially as we move into leadership roles where, our deliverables are not necessarily primarily code. Um, they are often interpersonal. They are often written. I do a lot of writing as an engineering leader, just like writing documentation, writing briefs and memos, um, and so I think that for other people who have come into engineering from a non technical background, whether it's a boot camp or you're self taught, um, really think critically about what the other skills you have are and how you can leverage them in the context of your current team. And I think that you'll find that those things actually, yeah, end up being advantages because they're skills that, that you don't learn as, as engineers necessarily. And so a lot of that is working in teams or, like I said, writing. Um, and so I would really encourage all career switchers to be proud of their backgrounds. And to really try and bring those skills to the forefront have a conversation with your manager about what other skills you have and how you can leverage them. And in, in the spirit of planning and being proactive, you know, to Spend some time reflecting, um, sit down with yourself and say like, Who do I want to be, um, as an engineer? And how do I leverage my background, um, in a really positive way?
Conor Bronsdon: 29:34
I've really enjoyed this conversation, Melissa. Where else can our audience listen to you or kind of learn more about your work?
Melissa DePudyt: 29:41
Well, so I work for a company called Up Statement. We are a, we call ourselves a digital product studio with an editorial mindset, which is a very fancy way of saying that we are an agency, that tries to leverage a lot of journalistic and editorial techniques, in the course of our project work. Um, so we take on, um, clients that need big transformative strategies and visions, both in terms of the product and the, the technical, like, needs of the team. So that's where a lot of my work is currently. I am working on getting set up with, a blog for kind of like talking more about a lot of these things. Things because I, I have started to realize that my perspective is really different. Um, because I'm a career switcher and I have that background.
Conor Bronsdon: 30:28
And I'll say as someone who also loves to write, I think there's a lot of value for me, and I think many other writers. It, when you start to put pen to paper, so to speak or type, let's be real uh, and kind of say, okay, here is how my mindset works here.'cause it, I'll say it helps me codify and clarify my thoughts. Yeah. And can hopefully help make, us both better leaders by taking on action.
Melissa DePudyt: 30:49
Yeah, exactly. I think, I get caught in my head a lot, and I'm like, oh, I have this idea, and I need to, I need to like, really think about it, until
Conor Bronsdon: 30:57
Write it down.
Melissa DePudyt: 30:57
Yeah. Yeah, and, and so just like, yeah, putting the, the virtual pen to paper, and like, getting it out, you're like, oh, no, that's actually like a real A real thought that, that is valuable to other people, um, so I've definitely gotten in my head lately about being like, no, people don't need my perspective.
Conor Bronsdon: 31:15
I, I wrote about this recently on my personal sub stack, which is like the problem with perfectionism. I think a lot of folks, myself included, um, get wrapped up in this idea that, we need to be perfect on our first draft. We don't need perfect before we put it out in the world. And yes, that's true in some cases, like. Okay. Like if I'm a reporter, I need to check my sources. I need to make sure what I'm saying is real. Yeah. But for many of us, if I'm, you know, writing my little substack to my several hundred people who might read it like, it's okay for me to like, think through my thoughts Yeah. And talk through it. And it's actually really valuable part of that process to say, you know, let's put pen to paper or virtual paper. Yeah. And maybe publish it, get feedback, keep going, like write a new thing. And there's so much value in that, whether it's, you know, starting a project and putting code out in the world, writing. Creating videos. Whatever it is you want to do that, like, building in public and the act of just creation can create such a virtuous feedback loop and help prepare you to, to think through, uh, situations and prepare under crisis.
Melissa DePudyt: 32:12
Yeah, totally. And I think that, like, it's very easy, obviously, in today's society. culture to become isolated and to be like, um, either, no, this idea isn't good or this idea is the best and I'm the best for having it. And working in the open and publishing that, and putting your work out there to me has really reduced my, my fear of making mistakes. I am also a chronic perfectionist and overachiever and want to be as perfect as possible. And I think that mindset for me came a lot from journalism. You have to be fast and you have to be right. And I think that's where we can actually give ourselves a little slack in decision making. The stakes are much lower for us. And if we're working in public, then we get feedback can learn constantly. You can learn. Yeah. And you can learn and you can adjust. And it's like you reduce, reduce the impact. Continuous learning, continuous
Conor Bronsdon: 33:04
iteration. I'm seeing software concepts here, so it's, oh yeah. It's interesting to close on this note about, we've talked a lot about things that we can learn from how journalists approach their work and bring into software engineering. And here's, I think, the opposite perspective, where it's like, hey, here's, here's how we can, you know, learn from concepts that are already in software engineering and make sure that we're not overdoing on the mindset. So Melissa, I have to say I've really enjoyed this conversation. Uh, if you ever decide to, we'd love to have you write an article for our, our substack.
Melissa DePudyt: 33:30
Oh, absolutely.
Conor Bronsdon: 33:30
Yeah, I think that'd be great. And, uh, thanks for coming on the show. It's been wonderful.
Melissa DePudyt: 33:33
Cool. Thanks for having me.
Conor Bronsdon: 33:34
Uh, our pleasure. If you're listening to this, uh, make sure, check it out on YouTube as well. We're sitting here in the middle of, uh, a big plastic dome. Uh, it looks really fun. And, uh, yeah, check out on. Dev Interrupted, where that's who we are across all socials. And, uh, Melissa, thanks again. It's been a fantastic time.
Melissa DePudyt: 33:51
Thanks for having me.