Scott McAllister: Welcome to Page it to the Limit. A podcast where we explore what it takes to run software and production successfully. We cover leading practices used in the software industry to improve both system reliability and the lives of the people supporting those systems. I’m your host, Scott McAllister. @STMcAllister on Twitter.
Today, we’re going to be talking about funny and cringe worthy communication failures. When building and running software and production, we’ve all made mistakes. What’s important is that we learn from them. Have you ever been told that your communication style is quote “too confrontational?” Or do you have problems persuading your coworkers and managers without sounding arrogant or condescending? Have you said something and immediately regretted it? We have all been there, especially when the stakes are high and we’re in the middle of resolving a SEV 1 incident.
We’re joined today by Michael Callaghan, a lead software engineer with over two and a half decades of experience working in software development. Michael recently published a book about what he’s learned about communication mistakes that he’s made at work. It’s entitled, Don’t Say That at Work: Lessons Learned from a Lifetime of Mistakes.
Welcome to the show, Mike.
Michael Callaghan: Thank you, sir. How are you?
Scott McAllister: I’m doing all right. Doing all right. So, to get us started, what we like to do, Mike, here on the show is we begin with a question where we ask folks to debunk a myth. So, what are some myths or common misconceptions about communicate mistakes that you want to debunk?
Michael Callaghan: I think the first one would probably be, you don’t have to respond to everything that someone says to you. You don’t have to answer every question, at least not right away. Sometimes if you respond too quickly, you are going to respond the wrong way. That’s never good.
Scott McAllister: Yeah. I could attest to that. When wanting to respond quickly, there’s emotion in there and I’ve noticed if I have emotion in my responses that the outcome is kind of up in the air, right? Things can go south quickly or at least escalate.
Michael Callaghan: And you have the old adage, too, better to remain silent and to be thoughtful than to open your mouth and remove all doubt.
Scott McAllister: I use that saying a lot.
Michael Callaghan: I live that saying.
Scott McAllister: I think it was Abraham Lincoln that said that. So, at least that’s what someone told me once and I’m going with it.
Michael Callaghan: I think he tweeted it once.
Scott McAllister: Of course. Yeah. So, Mike, the book, I read the book and it’s full of extremely relatable situations. Some that hit really close to home for me. I can say I’ve actually experienced several of them, personally, or at least witnessed them. What inspired you to write a book on communication from this angle of what not to do?
Michael Callaghan: I’ve always been a contrarian. So, I tend to take the opposite view of many of my coworkers and friends and family, et cetera. But, the book idea came about because I tweeted once, I said something to the effect of, next time you want to suggest a direction at work rather than saying, why don’t you or why don’t we, or something like, why didn’t you use CSS to solve that problem, which is very confrontational. I said, rephrase it just a little bit to, what if we were to try using CSS to solve this problem? And someone responded to the tweet and said, dude, you need to put out a course on this. Because it wasn’t the first tweet like that, that I had done.
And I look back and I had half a dozen blog posts maybe. And other things that seemed to fit the same mold. I could probably do this. And it was right about the time COVID was starting. And so, my hour to an hour and a half daily commute was no longer a factor. I said, well, why don’t I just every morning then instead of driving to work, I’ll take the laptop out onto the back porch and I’ll just type for half an hour to an hour. And so, that’s what happened.
Scott McAllister: Nice. It sounds like a common thread where you hear about folks testing out a product, right? They put something out there and then sometimes the unintended result is people like this other part of the product that you weren’t expecting to do. But, getting inspiration off of… Basically testing things out on Twitter and on your blog, sounds like a, honestly, pretty ingenious way of going about things to test out, to see if people really resonate with a certain topic.
Michael Callaghan: Right. And that was never my intention. I had done a couple of books and courses on web development and Ionic mobile development, but nothing non-techy until that point. And the really cool thing is when I got the book, I released it simultaneously at Amazon as a Kindle title, but also on Gumroad.com as a PDF. And when I tweeted my release day announcement, I also CC’d Scott Adams, the creator of Dilbert. So, I’ve been reading a lot of his books and one of his books said something to the effect of, get used to putting yourself in embarrassing situations. Potentially embarrassing situations. So, I said, you know what, why not? What have I got to lose? And so, I CC’d him on the tweet announcing the book and he retweeted it.
Scott McAllister: Nice.
Michael Callaghan: To his 100,000 plus followers. So, that’s been my single biggest sale day ever was release day.
Scott McAllister: That’s awesome. And Gumroad is the platform where you have your tutorials or the courses that you’ve wrote for…
Michael Callaghan: Everything I’ve written, yeah, books, courses. I think right now I’ve even got a book, One Hour with Mike: Private Consulting on there.
Scott McAllister: Nice.
Michael Callaghan: You can sell just about anything on Gumroad. Mostly it’s for content creation. So, you’ll find all my books and courses there at walkingriver.gumroad.com.
Scott McAllister: Got it. That’s how I discovered you. So, to share with the audience my context, I discovered Mike through one of his courses on Gumroad about the Ionic framework. And so, that’s what I was curious. That that was the only time I’ve been exposed to Gumroad was through that Ionic course. I was curious if it was just technical courses, it sounds like it’s just content in general that is there.
Michael Callaghan: Yeah. I think people even publish comic books. I’m sorry.
Scott McAllister: Oh wow.
Michael Callaghan: Graphic novels, here. Whatever they’re called. But, yeah, you can sell art, you can sell music. You can sell just about anything you want on Gumroad.
Scott McAllister: All right. So, it sounds like the way that you got into the book is the topic started resonating with folks through your tweets and blog posts. Why do you think a topic like communication breakdowns…. What do we as humans… Even right now, I’m having a problem asking this question correctly. Right? Why do you think we have such a problem with communicating? Such hard time with it?
Michael Callaghan: It’s hard to say. This is something we all do, right? That’s kind of the point. If you want a glass of water and you need help getting it, you need to ask someone to help you. I don’t know what makes it so hard. I wonder if maybe we over complicate it.
Scott McAllister: That would certainly explain, in the microcosm of me asking the question just now, I was over complicating the wording in my head leading into asking the question. When in reality, we just need to just do it, right? We need to just ask the question or state the thing that we’re trying to say.
Michael Callaghan: Right. Just say what you want. Don’t beat around the bush. Don’t try to make things too complicated. That was an issue for me for a long time with emails. My emails would be page and a half long and finally a manager took me inside and said, what do you want from this? What is your goal from this email? Type that first. If we need supporting documentation or information, we can ask for it. Okay. For example, let’s say I want to use Ionic in an upcoming project at work. I could start by writing this really long email about all the cool things that Ionic can do, but it would make a lot more sense to say, we’ve got this project coming up. It needs to look really good on a mobile. It needs to look good on a desktop. What would you say about using Ionic or at least giving it a try? Because it looks really good on a mobile desktop, switches back and forth between iOS and material design automatically based on device. Can we give this a try?
And maybe even that was too many words, but it’s a lot longer or a lot simpler than the long-winded emails that I used to write.
Scott McAllister: Why do you think we wrote such long emails? Because I feel like when I’m working with folks who are very verbose and do write long emails or talk, like they’ll take up a whole meeting to say one thing, but they took up 28 minutes of a 30 minute meeting talking. Do you feel like maybe we’re trying to justify ourselves or kind of prove our intelligence to the group or what?
Michael Callaghan: I think it’s probably different for different people. Some people really do like to hear themselves talk. I don’t think I’m that way anymore. Maybe I am. Yeah. I’m not sure. I think some people just have so much to say that they think they’ve got to say it all.
Scott McAllister: But, it’s sounds like you’ve discovered that by boiling down to the specific things that you’re looking for, you were able to get a lot more buy-in or a lot more engagement with the messages you were trying to send.
Michael Callaghan: Yeah. And there’s a chapter in the book about a technique coworker of mine. And I discovered a few employers ago, so not my current one. We had a COO who really wanted to be involved in every decision. It was a small company. So, COO knocking on your door is not a weird thing. Weirder thing is that we had a COO in a company with fewer than 20 people.
But, anyway, he and I got together and said, we’ve got to come up with a better way to propose his ideas to him. So, what we would do, we came up with a template, email template. It was, Dear COO. Here’s a problem we are currently experiencing, followed by one or two sentences summarizing the problem. That was it. No details.
We believe after deep discussion with each other, that one of these three possibilities is the way to go. Option one, option two, option three. Not caring which option that he would eventually choose. We only gave him the options we liked. If we thought it was a bad idea, we didn’t even say it. Which of these would you like us to proceed with?
Now he’s involved. We don’t have to spend an hour meeting with him. If he wants more information, he can request it, which he never did. He almost always picked the first option. So, that was our favorite option. He got to feel involved. We got to do what we wanted without a whole lot of fuss. And everybody was happy. Some people might say that, oh, well you manipulated him. Maybe, but ultimately I think it was the right amount of time and the right amount of detail for the individuals involved because he does have other responsibilities other than answering our questions.
Scott McAllister: Yeah.
Michael Callaghan: This respected his time. We had gone and done the one to two hour analysis ahead of time, the other developers. And so, we were confident that one of these two or three, maybe sometimes four, options would work.
Scott McAllister: I think it also helped, like you mentioned, that rather than just asking the question and saying, what should we do? You did the research, you did the legwork. You said, here’s what we think. What do you think? Of these options, which do you like?
Michael Callaghan: Right.
Scott McAllister: I think it’s a great communication tactic to get people engaged. Because, like you said, especially as you go up the chain in an organization, their workload and the number of people they need to be talking to and the decisions they need to make, increases. And so, helping them do their job more efficiently helps you get what you need more efficiently, I think.
Michael Callaghan: Right. I once told a manager that I felt that part of my job was to make her look good.
Scott McAllister: Yeah, yeah. That’s a great rule of thumb.
Michael Callaghan: And there’s another quote, staying on this, being brief and not talking too much. And now that Amazon Video or Amazon Prime series Wheel of Time is out. And by the time you publish this, it’ll be over, season one.
Scott McAllister: Right.
Michael Callaghan: But, I was a huge fan of those books. And there’s a quote from one of the books that says, he strains to hear a whisper who refuses to hear a shout. And I think there’s a lot of truth to that. If you don’t talk a lot and when you do, you speak slowly and softly, people will not ignore you. They’ll try to, what is he saying? They’ll want to know what you’re saying.
Scott McAllister: I love Robert Jordan. He’s a great author. I’m also working through the TV series. But, yeah, that’s great advice and to think about.
So, as software engineers, you and I both are, you’re currently a software engineer. I was a software engineer in a previous life. We kind of get a bad, like when you think of the typical software engineer, we get a bad rap. Because people kind of imagine we’re that person who’s happy in a small dark room, not talking to any and we’re bad communicators. Do you feel that that generalization is justified?
Michael Callaghan: Yes.
Scott McAllister: Why do you think that is?
Michael Callaghan: Well, because I was like that.
Scott McAllister: Yeah.
Michael Callaghan: I was very happy. If you told me what to do, stuck me in a corner with a computer, bigger monitor the better, and just said, go do this stuff. Don’t invite me to meetings. Don’t ask me questions. Just let me get into the zone and stay there. And I know a lot of people like that. I knew some brilliant software engineers who don’t want to talk to another human being throughout the day. Fortunately, if you will, that job I was at where we had the email template with the COO, it was a small enough company that when we had a major release on the product that I was working on, they would send me to trade shows because nobody knew the product as well as I did, having just finished working on it. So, they would get me an airline ticket and ship me off to the trade show in Dallas or Las Vegas or whatever.
And I’m expect to stand in our booth for six or eight hours talking to people, essentially selling them on the thing that I just built. And I remember one time in Las Vegas, our sales VP, we had all these high level executives in this 20 man company. He got sick the day of his presentation, so I had to take over essentially pitching the product to a bunch of people in the telecommunications business. I didn’t have his deck. I wasn’t prepared. So, essentially I just gave them a demo of the app. This is what it does. And it had a rest interface on it that I used for debugging. So, at one point I had pulled up the page on my phone and I said, so this is what you’ll see if someone dials 911. And I pressed the submit button on the thing and the system starts screaming and pop ups everywhere saying, hey, this is Mike’s calling, making an emergency call. This is where he is located. And it was really slick.
Scott McAllister: Did it actually call 911?
Michael Callaghan: No, no gosh.
Scott McAllister: Okay.
Michael Callaghan: Because that’s why I submitted it to the rest interface.
Scott McAllister: Oh right. Okay.
Michael Callaghan: That I used for testing because no, I don’t really want to dial 911.
Scott McAllister: No.
Michael Callaghan: Not from a convention center. But, that whole experience got me comfortable. I don’t mind sales situations. I don’t mind talking to crowds. I don’t mind dealing with people.
Scott McAllister: Yeah. Interesting when necessity creates opportunities for us.
Michael Callaghan: Yes.
Scott McAllister: In building our different skill sets that we didn’t intend to build. But, sometimes those new skills kind of present themselves in those ways.
Michael Callaghan: Well, as Scott Adam says, again, you’re building your talent stack. And so, in one of his books, I think it’s How to Fail at Everything and Still Win Big, he talks about building a talent stack, being above average in a stack of different things and the combination of those things becomes your talent stack. And if the talent stack is unique and valuable, you can succeed without being the best in any one thing. So, I’m a software engineer who’s probably better than average.
Scott McAllister: Yeah.
Michael Callaghan: Who can talk to people, who can build PowerPoint presentations and deliver them. And I can make video courses and I can do voiceovers. Which I’ve done for my current employer. So, those things combined make me an above average developer.
Scott McAllister: It sounds like a lot of those are communication skills, right?
Michael Callaghan: Yes.
Scott McAllister: More than just the coding and the figuring out the technical problems and making a software application run efficiently and run well and be a delight to use, as we say. And so it sounds like communication is, I would say, standard or a good foundation for excelling in your role.
Michael Callaghan: Absolutely.
Scott McAllister: So, in your experience, what are some of the overarching themes for the breakdowns that we have in communication?
Michael Callaghan: People judge you by what you say and what you do. People judge you by what you intend and what you mean. And there’s often a huge disconnect there.
Scott McAllister: I would agree with that a lot. That’s a lesson I’ve had to learn the hard way a lot is, I know what I mean and I know what I’m trying to say, but the words that I use and the context that it’s in sometimes gets received very, very differently. And so, then you have to be super, super careful. Yesterday, actually, I was going through a lot of issues in an open source project that I’m a maintainer for. Our Terraform provider here at Pager Duty. And as I go through those issues, I find myself… I want to just be real quick in my responses and real quick in what I say, but if I’m quick and not verbose enough, right? If I don’t say it in the right way, I know what I’m trying to say when it’s like, this doesn’t make sense or this doesn’t work or I need more context or something like that. But, the person receiving it might not understand what this was when I’m saying this doesn’t make sense.
Michael Callaghan: Right.
Scott McAllister: And so, using wording is better.
Michael Callaghan: Exactly. We may go through five or six steps in our own head and arrive at step seven at the conclusion and say this. Blurred out the conclusion. And people who weren’t following those steps, look at you like you’re an idiot. How could you possibly think that?
Scott McAllister: Yeah.
Michael Callaghan: And some of the lesser diplomatic ones might simply ask you that. Why would you say something so idiotic?
Scott McAllister: What? On the internet, people be rude? What are you talking about?
Michael Callaghan: Or even in the conference room.
Scott McAllister: That is true. And so, there’s a lot of different themes that you talk about in your book, as far as, you were talking about using too many words when we’re trying to communicate something in our emails. Some of the other themes that I remember reading about were something about prejudice. Coming in with that kind of a preconceived notion on how a person should be.
Michael Callaghan: Yeah.
Scott McAllister: And that was an interesting point.
Michael Callaghan: I don’t want to give away that particular chapter, but what did you think? Did it affect you the way I think it did?
Scott McAllister: And the way the pictures were set, I absolutely thought that the, yeah… I’ll just say, what you intended to happen for the reader, happened for me. And that was an eye opener for me. For being able to see… You perceive, we perceive people, especially notable people or politicians, as people who believe a certain way. And so, because we believe they believe a certain, we think that they believe a certain way, we attribute their words to always kind of align with that belief system. When in reality people can have different thoughts and change and communicate different ideas.
Michael Callaghan: Right. And that chapter kind of came out of a text message my son sent. He sent me a text one day and said, what do you think of this? And he had a quote. And I said, what idiot said that? And his reply was, your favorite politician. Oh. Well now I’m kind of stuck. Right?
Scott McAllister: Right.
Michael Callaghan: I can’t defend it anymore. It really is kind of silly.
Scott McAllister: Yeah. I think the key there is recognizing when we made a mistake or that we had a shortcoming or a flaw in our thinking and pivoting. And I think pivoting is a, in my experience in life, that’s definitely helped me become better and avoid confrontation and avoid situations that would not be well.
Michael Callaghan: Yeah. There’s a similar situation. I don’t think this one’s in the book, but it happened recently. Somebody was complaining about a particular coding pattern. My knee jerk, not thinking response was, why is it like that? That doesn’t make any sense? And the response came a few minutes later, again, by email with a whole bunch of people in the email thread. Said, don’t know, Mike, it was your code.
Scott McAllister: Whoops.
Michael Callaghan: So, I opened GitHub. Looking at it. Yep, that was my code. I don’t know what I was thinking, but apparently I was not pleased with myself.
Scott McAllister: Said every engineer ever.
Michael Callaghan: Yes.
Scott McAllister: About past code.
Michael Callaghan: The best code is the code you’re writing today. The worst code is the code you wrote yesterday, right?
Scott McAllister: At least you hope so. Because if it’s not, then you got to start evaluating what you’re doing.
Michael Callaghan: I am a huge fan of scouting and in coding, I follow a lot of Boy Scout rules. And one of them is leave the campsite better than you found it.
Scott McAllister: It’s a great point. I think of open source software because I’m involved with a lot of opensource projects, a lot like responsibilities on a camp site or on a camp out where it’s like, you see something that needs to happen. You go and help fix that one thing. You help go or clean up that one thing. And then if everybody’s looking and has the intent of the camp out or the intent of the project at heart, then everyone will be finding those one little things and then the whole thing will be better. And so, every time I go on a camp out or I’m involved in a group project like that, I kind of see it the same way where it feels like an open source project that everyone, hopefully, is looking at the different things that need to happen. So, yeah. Always relating software to life.
Scott McAllister: So, in the book, it talks about a lot of the different things, mistakes that have been made in your career with communication. When people read your book and identify the areas where they need to improve, what advice or encouragement would you give those people that there is hope?
Michael Callaghan: I think where we started at the beginning of this conversation. Don’t think you need to respond right now. Probably the biggest lesson I have learned throughout my career, particularly with emails, is don’t send it yet. So, a lot of times what I’ll do is I will write an email typing exactly what I want to say, what I’m feeling at the time, intentionally leaving off all to fields. So, even if I accidentally hit send this isn’t going anywhere. And then I let it sit. No one needs to know my response now. It can wait an hour, can wait two hours. In fact, it can probably wait until next week in most cases. So, I’ll type exactly what I want to say, save the draft, walk away, do something else for an hour or two, come back and reread it. On that next pass, it’ll probably end up being chopped in half.
This isn’t relevant. They don’t care. This doesn’t help my point. This might be condescending. Just try to look at it with a fresh set of eyes or better yet find the person next to you that you trust. Read this for me. I do that a lot. Come take a look at this. Even somebody who doesn’t have the context, take a look at this. What do you think of this email? Well, if I were giving that email, then I would really be annoyed that you said that. Really? Why? Because it sounds like you’re telling me that I don’t know what I’m doing. Really? I don’t see that at all, but okay. Maybe you’re right. How can I rephrase that?
If you do it right, your emails will be shorter, which means they’re more likely to be read. Hopefully you won’t be offending anyone. I tend to use words that I grew up with that some people consider you really probably shouldn’t use that term professionally anymore. My brain still says, hey guys. A lot. And I work for a place with a lot of diversity in the employment. So, I try to be sensitive to that, even though I’m not a very sensitive person, normally. Especially when I’m not thinking. So, I’ll remove, hey guys. And I’ll change it to, hello folks or team or something. But, I almost always start with 50 plus years of conditioning.
Scott McAllister: Yeah. Change is hard. Especially when it comes to the words that we’ve always used, but that particular change, I’ve definitely put a lot of effort into trying to adjust my language and how I refer to groups and it’s getting there. I’m not perfect at it, but I’m definitely getting better at over generalizing what a group of people should be or not necessarily that I thought that, but that my words implied it. And so, that’s a good point.
Michael Callaghan: Well, a friend of mine told me once that his manager came down on him for saying, good morning, ladies, when he walked into the office. And I said, were there men there? Again…
Scott McAllister: Right.
Michael Callaghan: Not really thinking a whole lot about it. And he said, no, I thought I was being polite. It was just the two of them. So, I went into work the next day and I asked, informally, some of my coworkers. I said, if I came in and said, good morning, ladies, would that bother you? And they said, no, why would it? So, it really depends on the situation and I guess you’d need to know your audience
Scott McAllister: So true. That’s that’s exactly it, is understanding who we’re communicating with, the context that we’re in, how familiar we are with those people. And so, that’s a great point.
Well, Mike, thanks for coming on the show. We invite everyone to go check out Mike’s book. Again, it’s called, Don’t Say That at Work: Lessons Learned From a Lifetime of Mistakes. It’s available on Amazon.
Michael Callaghan: Amazon for the Kindle version. Audible for an audiobook version, if you’re an Audible member. And Gumroad.com for also audio version. Right now, it is Kindle exclusive. So, I can only sell the ebook at Amazon.
Scott McAllister: There you go. We’ll have a link to that in the show notes. And then, Mike, we love to close every episode with a couple of recurring questions that everyone gets to answer and they’re the same across every episode.
So, what’s one thing you wish that you would’ve known sooner when it comes to communicating and I guess communicating better?
Michael Callaghan: How to say no without saying no. It’s a talent. It’s an art. And I don’t mean simple things like, hey Mike, would you like a piece of candy? No, thank you. That’s fine. But, the example from the book is something to the effect of, we need to get this feature into this release. How do you say no without having it be a career limiting response? Maybe there just isn’t enough time to get it into the release. You can’t simply say yes to every request that comes with across your desk. So, knowing how to say no artfully or yes and, yes if. I agree, that would be a great idea if we can maybe change the release date or take this feature out instead. What can I do to make it a yes for you? Nobody likes to be told.
Scott McAllister: That’s for sure. So, is there anything about communication breakdowns… I keep referring to that because I keep thinking of Led Zeppelin, but anyway.
Michael Callaghan: It’s a good song.
Scott McAllister: It is a great song. That might be the title I use for this episode. But, anyway, is there anything about communication breakdowns that you are glad that we did not ask you about?
Michael Callaghan: So, I saw this question in the document and I thought this one’s going to be a tough one.
Scott McAllister: Yeah. I felt that way because the nature of the book is basically sharing all the mishaps you’ve had. So, it’s like, well, I basically laid it all out there already in my book.
Michael Callaghan: One of the topics that I avoided in the book, not because I have a lot of experience with it or I’ve made a lot of failures in it, but I’ve tried to avoid… There’s a lot of people, especially software developers, and I’m not sure why, that have a problem with the opposite sex. Men talking to women developers and well, it’s not vice versa. It’s men talking to women developers. I avoided all that in the book. I’ve seen horrible communication failures. And honestly, I just don’t want to talk about those. I don’t know how to fix it. It can get uncomfortable. It’s definitely cringe worthy when you hear the way some developers talk to their female counterparts. And it can be offensive, it can be hurtful. And I just try to avoid it.
Scott McAllister: Well, Mike, thank you again for coming on the show. Thank you for being vulnerable and writing a book about mistakes you’ve made. I think a lot of us wouldn’t be able to have that kind of confidence to put something out there to say, here is the places where I messed up. You can learn from my mistakes. And so, I think it’s an encouraging message to send all of us that all of us make mistakes and we can all do better at communicating and doing our work.
Michael Callaghan: Fortunately, the worst ones happened decades ago, so they don’t sting as much as they used to.
Scott McAllister: Nice.
Michael Callaghan: Although one chapter was written while it was happening.
Scott McAllister: Ooh.
Michael Callaghan: I won’t tell you which one.
Scott McAllister: Sounds good. Well, thanks again. And thanks everyone for listening. And I’m Scott McAllister and I’m wishing you an uneventful day.
That does it for another installment of Page it to the Limit. We’d like to thank our sponsor Pager Duty for making this podcast possible. Remember to subscribe to this podcast if you like what you’ve heard. You can find our show notes on pageittothelimit.com and you can reach us on Twitter @pageit2thelimit, using the number two. Let us know what you think of the show. Thank you so much for joining us. And remember, uneventful days are beautiful days.
I began learning to program computers way back in 1981 in High School. The Data Processing teacher took pity on a young 9th grader and let me borrow time on the county’s HP 2000 to teach myself BASIC. That experience grew into a passion for software development that has never waned.
Though my early career took a 10-year detour, I finally began writing software professionally in 1995. I’ve been doing that ever since.
Scott McAllister is a Developer Advocate for PagerDuty. He has been building web applications in several industries for over a decade. Now he’s helping others learn about a wide range of software-related technologies. When he’s not coding, writing or speaking he enjoys long walks with his wife, skipping rocks with his kids, and is happy whenever Real Salt Lake, Seattle Sounders FC, Manchester City, St. Louis Cardinals, Seattle Mariners, Chicago Bulls, Seattle Storm, Seattle Seahawks, OL Reign FC, St. Louis Blues, Seattle Kraken, Barcelona, Fiorentina, Juventus, Borussia Dortmund or Mainz 05 can manage a win.