Professional Skills for Software Engineers

Intro

Trisha Gee: Hello and welcome to GOTO Book Club. Today I, Trisha Gee, will be interviewing Charles Humble about his “not-book”, which is book-ish. Hello and welcome, Charles.

Charles Humble: Thank you for having me on.

Non-Technical Skills That Drive Technical Careers

Trisha Gee: You're very welcome. I wanted to first caveat my whole thing about it not being...a not-book. So can you please describe the project to me?

Charles Humble: I did pitch it as a book. I had this idea for a long time that was kind of nascent and not very well thought through. The starting point was a talk I gave at GOTO and also at Devoxx UK about writing as an engineer—not writing for engineers, but being an engineer who writes. I imagined I'd have five people in the room, talking to a camera on my own or something. As it turned out, both times the room was full. I thought, that's interesting.

Looking over my career, what success I've had that wasn’t purely luck wasn’t due to my programming ability. It was mostly down to other things—being able to talk to executives, do presentations, understand systems thinking and critical thinking, communication patterns, and so on.

I had this half-formed idea that someone should do a book about things that aren’t programming but might be helpful for programmers. I pitched it to O’Reilly. They said, "We don’t think this is a book, but there’s something here." I worked with an editor who helped me develop the structure.

We ended up doing a series of O’Reilly shortcuts—connected articles grouped into topical areas: communication, critical thinking, documentation, and networking. Each group is like a chapter, and within each, there are three or four articles, about 1,500 words each. That’s how it came together.

Another input was that I learned to program in the 1980s on 8-bit computers like the Commodore 64. It was interesting because the machine was small enough to understand completely—every chip, buffer, everything. You could do fun things, like store compressed code in the tape buffer and explode it into main memory, giving you more than 64K of programm in a 64K machine.

The reason I knew all that was because people wrote magazine articles with actual listings you could type in, explaining what they were doing. That’s how I imagined the industry would be. I studied English literature—not computer science—mostly to annoy an English teacher who told me I shouldn’t. Then I gradually worked my way into professional software engineering.

One thing I found surprising was that code had become a secret thing we didn’t talk about or explain. Open source has helped, and reading or contributing to open source is valuable. But as an industry, we need to be much better at explaining what we're doing and why. We tend to think communication isn’t for us, but it’s never been more important. Our work has a massive impact, and we're bad at explaining it.

That’s another motivation—I think all of this is stuff you can learn. Maybe you won’t be the next Jeanette Winterson and write beautiful prose, but you can absolutely learn how to communicate factual information clearly, think critically, and synthesize information. If we don’t improve as an industry, we’re in trouble.

Trisha Gee:  Yes, I violently agree with all of that. You also answered my first five questions in one.

Charles Humble: Oh, I'm sorry.

Why Soft Skills Aren't Soft

Trisha Gee: I completely agree. I thought about writing a similar book. I was going to call it Politics for Programmers—again, about these non-technical skills. I should mention the name of the not-book: Professional Skills for Software Engineers. Like you said, it’s broken down into communication, critical thinking, documentation, and networking. I violently agree with all of this.

You mentioned the term “soft skills.” I had this as the last question I was going to ask you—how do you feel about the term? Do you love it, hate it?

Charles Humble: I loathe it. I loathe it with the passion of a thousand burning suns. It implies that programming is the hard part, and people and communication is the easy, soft, squidgy part. I think it’s the other way around. Programming isn’t a hard thing. Knowing what to build and how—that's difficult. That requires communication.

I really dislike the term. But we seem stuck with it. “People skills” doesn’t quite work. A lot of it falls under systems thinking, which might be better, but that also comes with baggage.

It’s a bit like “artificial intelligence” as a term—it’s neither artificial nor intelligent. It’s just an unfortunate choice of language. And that illustrates the point: we’re bad at words. We’re bad at naming things, because naming is hard. So we’re stuck with “soft skills,” which is like fingernails down the blackboard of my soul. I loathe it, but I don’t have a better term.

Trisha Gee: It tends to make engineers devalue these skills. At least it’s not called “easy skills and hard skills”.

Charles Humble: Yes, that’s true.

Recommended talk: Writing For Nerds - Blogging For Fun and (Not Much) Profit • Charles Humble • GOTO 2023

Trisha Gee: There’s this implication that it's somehow squishy, maybe not as important, and something you can get by without really investing time in. That’s why what you said at the beginning really resonated with me—the idea that these are all learnable skills. If we put in a bit of time and effort, we get better. Sure, we’ll naturally be better at some things than others, but like programming, if you invest in these skills, you will improve.

Charles Humble: Absolutely. And it will pay dividends. One of the unfortunate things is that because we undervalue these skills, we under-test them. When we interview engineers, we focus on coding challenges or whiteboard exercises. And that's a whole other rant I could go off on. But skipping that for now, it’s really hard to test critical thinking or communication skills on a whiteboard.

Because we don’t value those skills properly, we end up promoting people primarily for programming ability and efficiency. We don’t promote—or pay—people as much for the skills we undervalue. That has some major ramifications for the industry.

Trisha Gee: You already mentioned that being good at the skills in your not-book helps you build the right thing—which is huge. If you can communicate with people, understand what they want, apply critical thinking, and problem-solve effectively, you're more likely to build the right thing the first time. But we don’t really know how to measure what makes a good developer. We don’t define our jobs well or evaluate the right things.

So we end up overlooking people who quietly do the right thing the first time, because they make it look easy. Instead, we focus on more code, more commits, and lots of back-and-forth, rather than valuing someone who just gets it right upfront.

Charles Humble: Totally agree. It’s not universally true, which is good, but it’s very common. In fact, we often promote the worst people—the ones who work around the clock, hack away in a crisis, and make a lot of noise. They draw attention to themselves, and we treat them as heroes. But they’re not the ones we should be promoting.

The good news is that this is somewhat culture-specific. In the places where I’ve been happiest professionally, the culture values the people doing the job well—not just the ones doing it loudly.

Gaining Visibility Without Compromising Your Authenticity

Trisha Gee:  That makes sense. Actually—I was going to say—Reading the section on networking toward the end of the book really reminded me of this point. In my Career Advice for Programmers talk, I say it’s not enough to be good at your job—you also have to let people know you’re good at it. You have to show up, demonstrate your work, and present the best version of yourself. You need to make a bit of noise, or else you might not get promoted or recognized.

The hero programmers often get noticed more because they’re visible. They stay late, fix tricky bugs, and get credit. So I appreciated the networking section in your book—those are the kinds of skills that help you get noticed for the right things, not just the loud things. And that’s key.

Recommended talk: Career Advice for Programmers • Trisha Gee • GOTO 2013

Charles Humble: A hundred percent. Networking is a crucial piece, and all of these skills intersect. That’s why I ended up with 14 of them—you need them all, in different proportions.

Personally, I don’t like blowing my own trumpet. I’m uncomfortable saying, “Look how great I am.” But there are ways to do it that feel authentic and don't make me squirm. You do have to let people know what you’re doing.

The flip side is that a good manager should help you get noticed. They should say, “Here’s what I’m looking for. Here’s what I expect.” For example, if you're moving from a developer role into management, we’re often looking at whether you mentor others or raise the team’s overall skill level—not just whether you’re technically strong.

A good manager will tell you that. But ultimately, your career is your responsibility. If your manager isn’t having that conversation with you, maybe you should start it. Ask, “I want to grow—how do I get there?”

Trisha Gee: This is my key message in career advice for programmers: you're the one who has to live with your career and own it. Maybe you're fortunate and have a manager or career structure to help you level up. In my experience, and from speaking to others, many organizations—especially startups and smaller technical ones—don't have that. You need to take control of your own career. There are things you can do to improve it that management might not tell you about, and the things you've put in these articles are exactly the kinds of things that help. You don’t need to rely on a manager or structured path to supercharge your career.

Charles Humble: Yeah, I think that's right. I hope so.

How Communication Varies By Medium and Career Stage

Trisha Gee: One question I wanted to ask earlier is: who are these articles for? Who is this advice for?

Charles Humble: Great question. I spent a lot of time on this. It's for people thinking about moving from individual contributor to manager or senior engineer—around that junior to intermediate to senior point. The challenge is title inflation in our industry. Many have senior or manager titles without actually managing. A lot of this is stuff I wish someone told me before my first management position. It also comes from looking back at mistakes I made as a manager when I didn’t know what I was doing.

I had mostly good managers, which made it hard to learn—bad managers make their mistakes more visible. Someone who's really good can be invisible.

Trisha Gee: I learned from some of my management that—maybe not mistakes—but things I didn’t want to do as a manager because they made the team uncomfortable.

Charles Humble: Yes. That was part of my starting point. But everyone’s career path is different, and these things come up at different points. You don’t need to learn them all at once.

I got into systems and critical thinking while working on my first distributed system in the late '90s or early 2000s. I realized linear thinking wasn’t cutting it. I didn’t even know what linear thinking was—it was just how my brain worked. I stumbled across systems thinking at the right time. I had been a manager before, but at that point, I was an individual contributor again. So, these ideas are useful whenever you're in a new role—it doesn’t always require a promotion.

Trisha Gee: I'd like to "yes, and" your answer. Having skimmed the material and read parts that resonated, I think everyone should read all the articles. If you're just starting out, they can show you it's not just about technical skills. That might feel overwhelming, but it opens your eyes to other important skills. For example, if you’re better at asynchronous communication, you might handle conversations better. Read them at the start, again as an intermediate, and again as a senior—you’ll get something different out of them each time.

I think the communication section, the first one, everyone should read as soon as possible. People say "good communication skills" on their CVs like that summarizes what happens all day in a team. It's like saying "good technical skills"—what does that even mean? Programming? Picking up new tech? Databases? Systems?

Good communication skills are just as broad. Even in just the three articles you've written, you show that communication isn’t just “I can talk to people without them hating me.” There’s written, verbal, synchronous, asynchronous communication. Slack vs. email requires different approaches. Understanding that early can really help—it can supercharge your career.

Charles Humble: Yes, 100%. Absolutely agree. Pre-pandemic, I was a big advocate of remote work. During the pandemic, we all experienced it, but in a way that wasn’t ideal—it was forced. Intentional remote work requires a different kind of communication than in-person work.

Management style changes with remote work. Some people are better remote managers. That’s why some senior leaders push for return-to-office—they feel their power is being threatened.

But the real point is that written and in-person communication are completely different. There are similarities, but one thing I repeat often is the importance of intentionality—thinking through what you want to say and achieve.

One of my pet peeves is meetings where someone hasn’t prepared an agenda or outcome, wasting everyone’s time. Spending time thinking about why you're meeting and who needs to be there leads to more efficiency. Sometimes you can't prepare—like when there's a problem and you need to brainstorm—that's fine.

Trisha Gee: Right. If you're brainstorming or doing mob programming, then that is the agenda: "Let’s talk through this." But that’s a different expectation from, "I’m going to present and answer questions." Different types of meetings require different mindsets.

Charles Humble: Yes. And similarly, the communication channel matters. A Slack message isn’t the same as an email. Each has different expectations. You might expect a Slack reply in minutes or hours, but an email can wait 24 hours. Being explicit about those expectations helps new team members know what's expected.

Trisha Gee: Yes. They’re cultural. It depends on the organization or team. If you're expected to reply to Slack immediately, that implies you use Slack sparingly—for urgent stuff. You can’t use it for everything.

Charles Humble: Yes. I often reference a book called Deep Work by Cal Newport.

Trisha Gee: I’ve read two of his books. I love his work.

Charles Humble: He’s great. Deep Work resonated with me. His point is that distractions kill deep thinking. As programmers, we know that instinctively. That’s why open-plan offices can be a disaster—too many interruptions. People wear headphones to drown it out. Wouldn’t it be easier to just have private offices?

The general point: be intentional with how you communicate. That’s the key to making it all work.

Recommended talk: Navigating Complexity with Systems Thinking • Diana Montalion & Andrew Harmel-Law • GOTO 2024

Communication As A Core Engineering Competency

Trisha Gee: I agree. Because as a developer advocate, I do a lot more communicating than most normal engineers and I have way more channels to communicate. Internally we have email and Slack, of course. But if I'm trying to communicate an idea to other engineers, is this a video? Is this a blog? Is this perhaps a webinar? Because videos should be short. Webinars are long. Do I expect interaction? Is it a conference talk? And if you give a conference talk, it's not necessarily the same as even a user group talk, that kind of thing. So you have these different media, different channels with different expectations. And having a bit of a grasp of that makes you, I was gonna say it makes you better at your job, but it allows your message, whatever it is, to be received better. So you have to understand what people are expecting when they listen to you on whatever channel it is.

Charles Humble: Thinking about who your audience is, which is always a key part of that. So it's what media am I using, but also who am I addressing? Because the way you talk to engineers should be different from how you talk to others. About half of my work is consulting to various companies. One thing I encounter often is technical teams struggling to communicate. I'll hear, "The business won't sponsor us to pay down technical debt."

Trisha Gee: And what is the cost?

Charles Humble: Actually, can you even explain technical debt to me? I bet you probably can't because it's a phrase we use without fully understanding what it means even as engineers. So how is the business going to understand that? Rather than using jargon, if you can give them concrete information: this is what we're seeing, why it's happening, how long it will take to fix, and the expected outcome. For example: "We see 20% of customers abandoning shopping carts at checkout. We think the mobile app is hanging. It will take about four weeks to fix. If we're right, abandonment should drop by 50%." The business doesn't need to know you wrote it in a hurry six months ago and it's problematic.

Trisha Gee: Right, and they don't want to hear that.

Charles Humble: They don't want to hear that anyway. But now as a business person, I can make an informed choice against other competing priorities. I also know what outcome you're expecting, so I can hold you accountable. If we don't get that outcome, we can reassess. Do we still want to address this problem? What other theories do we have?

Trisha Gee: It allows you to focus as well. Often when I've wanted to address technical debt, it's because I want to refactor code I hate. But if you have a business goal like reducing churn or improving performance so customers don't leave, you can focus on just the tasks that help with that specific goal.

Charles Humble: Yes, 100%.

Presenting Opens Unexpected Career Doors

Trisha Gee: We mentioned conferences and presentations earlier. I contributed to one of your shortcuts around conference talks. There's one on presentations and one on conference talks. My question is: if an engineer isn't going to be a developer advocate like me, why do they need to learn to get better at public speaking?

Charles Humble: There are two answers. First, you'll probably have to do it at some point whether you're a developer advocate or not. Presenting is common in business. Engineers asked to give presentations often have a terrible time and give terrible presentations because it's not something we think about. That might be an internal presentation within the group of engineers or to management to talk about your team's work. Being able to do this well means you'll have a better time, and your audience will too. They'll come away feeling like you know what you're doing.

You slightly underplayed your contribution. I interviewed you and Holly for one of those pieces, but you also reviewed both and gave me valuable feedback. Your perspective as a developer advocate and as a woman is different from mine as a middle-class white English man.

The second reason is that presenting at user groups or conferences raises your profile, which helps your career, and connects you with people having similar experiences. At tech conferences, the best moments often happen outside the sessions - over coffee, lunch, or drinks afterwards, where you're with like-minded people. Speaking usually gets you free conference attendance, which is nice.

Trisha Gee: And you meet these really cool, interesting people.

Ethical Voices Can Influence Technology's Future 

Charles Humble: You meet a great crowd. At better tech conferences, both speakers and audience are interesting people. But it also comes back to our industry needing to get better at communicating what we're doing and why. If we don't, we risk being regulated in ways we don't understand.

Trisha Gee: What a terrible idea.

Charles Humble: And that would be very bad. I think our industry is in danger of going down a wrong path, and we need voices willing to point that out. From an environmental sustainability perspective, we're one of few industries making greenhouse gas emissions noticeably worse every year. We also make ethical choices that are questionable.

Trisha Gee: Questionable.

Charles Humble: Ethics makes people uncomfortable, but what we do is now consequential. Our work impacts social platforms, predictive policing algorithms, prison release decisions...

Trisha Gee: Healthcare.

Charles Humble: Healthcare - all areas where IT has impact. We don't typically teach ethics or sustainability in computer science courses, but perhaps we should. We need to communicate what we're doing and why. If we don't, there will be a tech backlash that will be bad for everyone in the industry. I feel we're just on the right side of an inflection point, but could go over it.

Trisha Gee: I had not thought of that. Now I'm going to worry about it all day.

Charles Humble: Sorry.

Trisha Gee: I think you're right. I've seen conference presentations about ethics about seven years ago, before ML and AI became as big as they are now. Ethics is like security but worse - developers know they should care, don't know how, and hope someone else will worry about it. We tend to assume we don't have control over what we're doing. The boss says do this, so we do it. Then we find we've created an algorithm denying poor people healthcare, for example. You have to decide if you're comfortable with that and what you can do about it.

Charles Humble: When I was chief editor at InfoQ for about six years and involved with QCon conferences, we pushed ethics hard with dedicated tracks and articles. I received some interesting emails about it. Then generative AI happened and seemed to take all the attention. While generative AI is significant, I worry we've lost sight of its implications. Cathy O'Neil's "Weapons of Math Destruction" came out a decade ago, and much of it remains relevant.

With AI specifically, issues around data collection and informed consent are ignored. People in places like Kenya are paid $2 an hour to review the worst content on the internet, which is traumatic. Are we okay with that? If we use these machines, we should understand how they're made.

My growing concern is mainly sustainability - greenhouse gases and climate change. The way we approach AI is massively destructive to the climate, which is infuriating because it doesn't have to be. We're choosing not to care about future generations or what happens to the planet after we're gone. We're willing to damage it so we can code faster.

Trisha Gee: Or not faster. I was playing with an AI assistant yesterday. I asked it to generate a unit test and it took significantly more time than if I just asked my IDE to generate the outline and write the code myself. I want to talk about this more, but it's not about the shortcuts you wrote.

Charles Humble: I've gone off on a bit of a tangent, sorry.

Trisha Gee: You started at the right point, which is that we need to be able to communicate our thoughts, ideas, and concerns, and communication skills and platforms are part of that. If you're an engineer worried about ethics in the industry or want to change something even in a small way... One reason I started blogging and attending conferences is because I wanted to see more women in senior technical leadership positions.

Martin Fowler was in the pub when I was working at Thoughtworks, and I was complaining about this. He said to me, "You are one of the few people in a position to do that because you can be writing and presenting, you can be visible, you can be a woman technologist, and you can be the change you want to see." That was 14 years ago, just before I became a developer advocate. It had a huge impact on me and my career. I'd like to think I've had a small impact on the industry because there is one more woman at conferences presenting about technical topics, not just about diversity in tech.

Charles Humble: 100%. I feel very strongly that's absolutely the right approach. If there's something you want to change, the only person who can make that happen is you. Going out, talking, and being visible as a technical woman is valuable in itself. Other people wondering if this industry is for them - if they don't see people like them, they're less likely to join. Also, it's odd to me that programming has become this weirdly male domain. It wasn't and it shouldn't be. There's absolutely no logic...

Trisha Gee: It wasn't. It started with women... The first computers were women who did the computing.

Charles Humble: All the way back to Charles Babbage and Ada Lovelace. It was Ada Lovelace that was fixing all the math, not Babbage. Literally from the very beginnings of our industry.

Trisha Gee: Grace Hopper.

Charles Humble: Throughout our industry's history, most of the pioneers were women. The idea that this is somehow a male domain is bizarre and just wrong. Whether it's climate change in my case, or women in more senior technical positions in yours - whatever that cause is, you have a voice and can make an effect. That might be within an organization or broader than that. If you can communicate better and talk about what you're doing, that's how you can have an impact at any level.

Recommended talk: Building Green Software Part 1: Introduction • Anne Currie • GOTO 2023

Career Advancement Through Visibility and Voice

Trisha Gee: You can have an impact on the industry, but it also impacts your career. Circling back to what we were saying about taking control of your career - the way to get promoted, get better jobs, all these things is about presenting the best version of yourself. It's not "fake it until you make it" and it's not learning specific skills because that's where the money is. It's about being able to present yourself, what you're good at, what you care about, to get the promotion or better job or find your people at conferences. I love conferences because my people are there. That's where my friends are.

Charles Humble: Yes, absolutely. Same for me.

Trisha Gee: One more thing I want to cover because we need to wrap up - in your section on blog writing, there was a question about where you get your ideas from. How do you decide what to write about or do a video or talk on?

Charles Humble: That's a perennial question that writers get asked all the time. "Where do you get your ideas from?" Everyone is different, but certain approaches are helpful. Real experiences are always right. I think we often assume that if we know how to do something, everyone must know how to do it.

Trisha Gee: I 100% agree with that statement. We assume that, and it's not true.

Charles Humble: It's not true. Often I've said to people, "You have experiences that no one else in this room has, and just by sharing that information, you're doing something useful." We sometimes assume we have to be the expert to talk about something. Learning from experts is valuable, but...

Trisha Gee: It's usually horrible because you already need to be at a high level to learn from an expert.

Charles Humble: Yes. We sometimes undervalue that first experience, that early learner journey, which can be a really good source, particularly with something new or novel. None of us really know how to use generative AI and large language models yet.

Trisha Gee: But even when...

Charles Humble: We're only going to work that out by discussing what were good use cases and what weren't.

Trisha Gee: I also agree that if you think about the adoption curve - I've helped run user groups, so you get a sense for which topics work well. If it goes well in a user group, it'll probably work as a blog post or conference talk too. The introduction to new technology always goes down well. But also topics that have jumped the chasm of the adoption curve. I'll use cloud as an example - it was hyped, and now everyone uses cloud. Once something crosses that chasm, people start paying attention and think, "I didn't learn about cloud when it was new and exciting, and now I need the bluffer's guide from people who've been doing it in the earlier days."

Charles Humble: I have a wonderful example from early in my career. I was working for a consulting firm and was asked to work with a large UK retail bank as an architect. The Friday before I started, someone mentioned they were using UML, which I'd never heard of. I rushed to a bookshop in London and got "UML Distilled" by Martin Fowler. I read it over the weekend and arrived Monday morning looking like a UML expert when I'd only learned about it two days earlier. It was a brilliant book that conveyed everything needed in about 100 pages. UML is unfashionable now, but the point is you get moments in your career where you realize you've missed something important.

At InfoQ, our editorial plan focused on technology to the left of the chasm that we believed would cross over - early-stage tech with real merit like cloud and microservices. It's the same logic - people want to know now, but others will be desperate to know in a year when it's everywhere.

Going back to the ideas question, another source is conferences, meetups, or talking to other engineers about their problems. If you think, "I know how to solve that," maybe you should write about it.

Trisha Gee: You'll find that things you know well are things you take for granted. It's useful to hear from people at conferences saying "We don't know how to write unit tests" and you realize, "I do, and I can explain that well." You hadn't even considered there's an audience for that.

Charles Humble: Absolutely. And with all these things, it's about practice, just like any craft. You learn programming by programming a lot, writing by writing a lot, speaking by speaking a lot. There's no shortcut. You just do it and be willing to make mistakes. That's how you learn.

With programming, pair programming or well-done code reviews have real value. With writing, if you're lucky enough to work with people who give feedback - that's how I improved. Sometimes it feels brutal, but it's how I got better. With presenting, it's similar - you start with internal talks or meetups, get feedback, and develop a feel for what works.

Trisha Gee: I have two top tips. One, 90% of the time when you're starting out blogging, most people won't read your work because they'll never find it. So it's worth practicing because there's little to lose - no one's going to pile on with criticism because almost no one will read it, which can be a good thing.

The second thing about feedback - sometimes you discover you're better than you thought. When Kevlin Henney and I edited "97 Things Every Java Programmer Should Know," everyone submitted pieces that we lightly edited. Kevlin told me my pieces didn't need editing. That was nice, but it made me realize others write stuff that needs editing and rely on someone else to polish it.

I didn't know that a lower barrier existed. I assumed my writing had to be publishable immediately, but it doesn't. You can put work out there and make mistakes. Especially if English isn't your first language, don't worry too much. When engineers read blogs or attend talks, they care about interesting content, not perfect grammar or presentation skills. You can improve those skills, but when you start, most of that doesn't matter.

Recommended talk: 97 Things Every Java Prog. Should Know • Trisha Gee & Kevlin Henney ft. Emily & Holly • GOTO 2024

Charles Humble: Absolutely. At InfoQ, we'd find engineers who wanted to write and give them basic journalism training. A tech journalist might write better, but the engineer knows the subject better. At QCon, we'd have first-time speakers who were great engineers. Audiences want you to succeed. If you're talking about things you've thought about, the audience is on your side and will tolerate an unpolished talk as long as they sense you've put in effort.

I want to add that engineers are generally bad at giving praise. If you're a manager, remembering to praise in the moment is valuable. If you enjoy a talk, blog, or book, spend five minutes to email the person or message them to say you enjoyed it.

About half my time is spent writing, which can feel like yelling into the void. It's nice knowing someone heard you and liked it. You tend to hear from people who didn't like your work, so hearing from those who enjoyed it is valuable. Even saying "That was interesting, could you expand on this part?" is fine. But mostly, just saying "I really liked this" makes the world better.

Trisha Gee: It costs almost nothing. As a presenter, when people approach after a talk to say they liked it, it makes your day. You could speak to 100 people, and if just one person says something positive, it makes everything worthwhile.

Charles Humble: Absolutely. It's a cliché to say "be kind," but taking that moment to say "That was good" makes a big difference.

Trisha Gee: I say this about code reviews too. It's not just about constructive criticism and empathy about how people receive criticism. Say nice things when you see good code. Take a second to write "I really like this pattern" or "Good job with the naming." It might seem patronizing, but it takes almost no time. I've seen arguments that it's a waste of time or noise in code reviews. But if you're focusing on learning, you want to reinforce good habits and patterns. To see more of what someone does well, tell them what you want to see more of.

Charles Humble: Absolutely.

Trisha Gee: I'm going to wrap up because we've talked for ages. Thank you so much. This was a fantastic conversation about soft skills and communication. I highly recommend anyone watching to read the articles. Regardless of your career level, some will resonate and make you think about developing these skills. Thanks very much, Charles. Anything else before we stop recording?

Charles Humble: No, that was wonderful, Trisha. Thank you so much. Always a pleasure to chat with you. Really enjoyed that.

Trisha Gee: Always a pleasure.

Charles Humble: Thank you so much.

Trisha Gee: Thanks a lot.