Room 103 Sunday Mar. 08 - SCaLE 23x

This talk, presented by Joshua Drake, explores how to succeed in professional open source by dismantling the myth that open source is merely free software. The speaker shares his extensive career experience, having started in open source before Linux 1.0 and ultimately forming the company Command Prompt. He emphasizes the importance of participation, the reality of ongoing challenges in a professional environment, and personal definitions of success that transcend conventional wealth and status. The talk also touches on the impact of burnout in tech professions, highlighting that success is ultimately defined by individual choices and personal fulfillment rather than societal expectations.

Testing, testing. Just question for the group. Anybody ever typed their password? testing. Yep. Okay. Okay. Let's try this again. There we go. Hey, plasma by KDE. Okay, go ahead and unplug that in. and plug that in. Okay. And then I should be able to go tools range enter view mode slideshow. Did that work? Nope. I disappeared. Do I need to Let me guess. All right, hold on

one second. We'll get there. Thank you for your patience, folks. It's Linux. It's not straightforward, especially when your mouse disappears. Where did I have no idea what this is doing. Everything was working perfectly this morning. >> I'm going to go ahead and reboot it one more time. I apologize. >> Yeah, no worries. >> You know, it's funny. Um, well, like I said, this is the first time

I've used this laptop. Usually have a Dell XPS and my Dell XPS never a problem. Just works. But I bought my wife this and this laptop got me to get her on Linux. >> So I bought this and I've never had any problems with it. But for some reason today it's it is being pnicity. Well, while we're waiting for um yet another blue screen of death from

Linux, uh what distribution do you run? Debian. Okay. How about you, Fedora? Any uh Arches? >> Slackware. >> Slackware. Wow. Uh my career in open source started with SLS, which is what Slackware was based off of. And I was selling slackware machines on Usenet of all things uh back then. That was back in the early 90s. Okay. All right. Now I have a mouse. Let's see if

I can tell KDE because I'm running Neon. Uh it says display detected. Let's get rid of all this extra stuff. do my display configuration. Okay, >> so today we're going to be introducing Joshua Drake. He's going to speak on how to succeed in professional open source. Um, today he'll dismantle the myth that open source is just a free stuff by showing the real viable career ladder that

exists. He's a pre- Linux 1.0 user who built command prompt, the oldest version of Postgress entirely through open source work. When people ask him how he made his career in open source, his answer is always simple. I wouldn't have been able to do the career I have now in any type of proprietary software >> postcrist company. I'm not the oldest version of Postcris but pretty close. Okay.

So now if this does what replica of built-in screen okay so now if I plug this is plugged in it should just I mean, it detects it. >> Oh, yeah. Is there some switch that we don't I don't know about because I mean it sees the >> That's my pointer, not the switch. There we go. Woohoo. Okay. So, I'm going to go ahead and give that and

then It was partially Linux. My like my mouse Um, okay. We're going to try this now. Uh, okay. I am JD. Thank you for the introduction. Uh, we appear to have sound. I'm going to assume we're being recorded. Um, for the young people in the audience, this is PG-13. I'm sure you've already seen and heard it all because it's the age of the internet. But just so

you [ __ ] know, it comes out. It's just the way it is. Um, this is how to succeed in professional open source. This is a different type of talk. Number one, I'm a storyteller. That's common for public speakers. But number two, this talk is two parts. This talk, the first part is the fun part. That's what we're going to do now. The second part is life. It sucks.

Okay, that's the second part of the talk. It is the reality of what success takes. Not the reality you wish it would be. That's the biggest difference is that everyone has hopes, dreams, passions. I hope everyone thinks that there's a way that things should be but that's not reality. So this talk is about how can you succeed in reality. All right. This does succeed based on participation.

If you want to succeed, you have to participate sitting here like you're in a library going through the Dewey. I guess they probably don't do Dewey decimals anymore. I haven't been in a library in a long time, but you know, card catalog, that's not how you succeed. You have to participate in life, whether you like what you're participating in or not. These guys, the white one is

Oscar Bin Laden. He has earned every inch of that name. He is my little man. He is He was the runt. He's 20 pounds of pure joy and terror. and he thinks he's a big dog. And it's funny because I mean he's a French bulldog so and I live in Montana so you have to put him in sweaters especially right now but he walks like a bulldog

so there's this 20 lb dog going I own the road right dog. The other one is Moose. He is 30 lb and he may looks a little wonky in that picture cuz he is a little wonky when uh he was naturally birthed, which is not a thing you do with Frenchies because it makes their face go and then you never grow out of it. It's like you

took tongs and pulled them out. Um I am the spare human. Do not be I'm not the primary. This is my backyard. And I show you this not to gloat. I'm not promoting. I'm showing you this because this is what success looks like for me. I busted my ass for three decades. I have 20 acres in the Rocky Mountains and I'm 100% off-rid. My nearest power pole

is a quarter mile away and I do not have a connection to it. I live off of a well and solar panels. That is what success looks like for me. This is what I look out my window every single night. I get the northern lights. I get uh what are they called? Rafters of turkeys. I get elk, bears, cougars, skunks, foxes, all of them. Um and it

took a long time, but this is what I got. And before this, I you know, I had what a lot of people would consider success. I had 10 acres. I was in Washington, uh, outside of Bellingham, which is a very popular town. Uh, beautiful house, 2100 square ft, 1,200 foot shop. I do miss the shop. Uh, but I was on grid. I had a mortgage. I had

property taxes. I had all the things that we all think that society tells us we're supposed to have. I sold it. And I moved to Montana in the mountains. And I have no debt. I have no mortgage and my house sits on wheels. So, my property taxes are $221 a year for 20 acres. Now, I'm not saying that's what you should target or what your goal should

be, but I see a couple smirks here wanting to kill me for my property taxes because a lot of you ARE PAYING A LOT more than that. And where that came from is when I bought my house in Bellingham, my property taxes were a very reasonable $2,500 a month or a year, excuse me, $2,500 a year. And then all the good-hearted intentions happened and I ended up

at $6,500 a year and I said, "I'm done." And I left. Okay, this is the formal definition of success. the accomplish accomplishment of a desired aim, purpose, or goal often accompanied by feelings of fulfillment, satisfaction, or the attainment of wealth, status, and recognition. The last part of that is [ __ ] That is not success. Wealth, status, and recognition is all what people tell you success is. So, you'll

pay more taxes. That's what it's for. It's not about fulfillment. It's not about your passion, your heart, your soul. If that if you believe in a soul, it's not about who you are as a person. This is all about whether or not you drive a Tesla, which I understand is no longer popular, but that's only a couple of years old. Okay, that's what that is. And that's

why it's orange. It's a warning. If that's your goal, if if you're looking for wealth and status and recognition, I'm not saying you shouldn't have those things. I have those things. It's why I'm the keynote. It's why I live off-grid and don't have debt. But that wasn't my goal. My goal was to try and do good work. And the profit that followed was the reward. And that's

why I have those things. So look, if you're a millionaire, good for you. If you're a billionaire, I don't care. Good for you. If as long as you earned it and you did it by lifting people up and not by taking advantage of people and oppressing people, then good for you. all the money in the world. Do not care. Just don't go to Epstein's Island, right? I

mean, just don't do that. That's bad stuff. Okay, we can agree that success is not but that's what most people think success is. They don't realize it. They don't realize they're on the hamster wheel just going round and round and round. Maybe maybe they get a promotion every couple of years. Maybe they get a raise, maybe you get a lot of raises, but are you still doing

the same thing over and over, right? This is particularly important for people in our field. Let me ask you, how many of you are devel coders, developers? All right. How many of you are like SRRES, system engineers? Okay. How many of you are all of that? Right. Okay. Got How many times have you reinvented the in your career? Right. Three, four, five, a dozen, 10. I've been

doing this for 30 years, and I can tell you this right now. There's not a damn thing we do today that I couldn't do 30 years ago with the same software. But somebody's got to feel like they're doing more, right? So, if you're going to do more, do it with purpose. Right? AI, for example, is not purpose. Now, I'm not bashing AI. It's just I'm not sitting

up here like an old guy going, "Oh, [ __ ] new thing." Right? I don't care because it's not new. It's just faster than it was the day before. Okay? Use all the tools you want, but try and do something that defines success based on your goals. Again, we don't want constant stress. How many here have ever said to yourself, "I'm burning out." Why do you think that is?

Anybody? Come on, help me out here. Why do you think you're you feel like you're burning out or have felt like you're burning out? >> You're reinventing the wheel. >> What about you in the back? >> 20our days sleeping under your desk. the now I'm Google I apologize in advance. Yes, I know you're a you're a very good sponsor of my conference Postgress comp if you guys

want to come. It's in April. Uh but Google is probably the most well-known company at a time that convinced people to not burn out. And the re how they did that was they had you live there. You would go work for Google and they would say, "Here's your chef. Here's your beer. Here's your desk, your cubicle, whatever it is they gave you. You have this massive, ridiculous

laptop to feed all of your brain synapsises and all the little shiny things us geeks like to chase." And they set you forward with a do no evil. Okay, now I'm not judging Google for getting rid of that slogan. It was a stupid slogan to have because corporations aren't good or evil. They're they're not people regardless of what the Supreme Court says. Okay, corporations are an entity

that are defined by the leadership and their goal, and this is what a lot of us forget. A corporation's number one and only priority is the shareholder, not the user, not the client, not the employee, not the team member. It's why you can have someone like an Amazon do such great things, but they don't want to look bad, so they hire out their slave labor to a

different company. Why? It's what the shareholder wants. Because the shareholder doesn't care about people. They care about profit. And don't get me wrong, that's good. Right? Because it is profit that drives the future of how we go. But coming back to burnout and success, think about what Google did there. You were just an animal in the zoo. They gave you everything you needed, everything you thought you

desired. So a 20our day was worth it. And now they're I don't think they're the scariest corporation on the planet. I I would leave that to anthropic and open AI, but they certainly could be because they convinced people that their dogma was success. And don't even get me started on Apple. So, what does success mean to you folks? How about you, young man? Yeah, I'm calling out

the the guy in the USC shirt. What's success mean to you? What do you want? There's no wrong answer. There really isn't. you're okay. So success to you is re defining a goal and reaching the goal. Okay. Do you have a goal? I mean I'm sure it'll change but what is it right now? Okay. Well, AI will help you with that. >> How about you, sir? You're

of my uh generation. >> Are you there? Sir, you made the mistake of stretching. What's your what's your definition of success? What does it mean to you? >> So, you fantastic full-time teacher. Anybody that wants slave labor going to teaching? >> Um, hey, half is not bad. So, you know what? I want to bring that up. Uh, that's a really good point. Uh, when I moved off-rid,

and that will be a theme during this talk, but when I uh, all I had was a cabin with no plumbing, no electricity. Uh, and I still have a cabin with no plumbing. Okay. So my [ __ ] actually is a portaotti. Okay. Uh that we lent basically I mean we actually own the structure but we have it serviced. It's actually my only compulsory bill. That's what was success

to me. Success to me is freedom, right? So the only bill I have that I must pay is property taxes. Everything else is a choice. how much I spend on food, how much I spend on Netflix or other streaming platforms, all that stuff is a choice. That's success to me. And that's partially it's we're all products of our childhood, aren't we? We're all products of our childhood.

So, I was broke as a kid. My first job, I was 12. I said, I don't even remember what I wanted to buy. I think I wanted to buy a bike. and my stepfather, who I hope is in hell, um said, "Earn it." So, I did. I started a a lawnmowing business, made my money, bought whatever. I think it was a bike, bought my bike, and moved

on. And that's actually how I started as being a businessman because I realized as an adult when I got fired for like the 17th time, I realized I really wasn't destined to be an employee. Uh, and so I launched Command Prompt. And Command Prompt was about two things. It was about freedom because I got to choose who I wanted to work with, whether it be my team

or my clients. Uh, and two, I was starving. So, I had to eat. How about uh you in the back? What's success to you? >> Either one. There's two of you back that's that's huge. Um, mortgages are rough. Yeah. No, I mean that's what happened to me in Washington. I got to I mean and I make good money. I was like I can't buy this. I mean

I there I mean I bought it originally for like 415 and I sold it for a lot more than that and I was only there for six years, five years. so when when you think about success in the professional open source realm, you said yourself where you're getting to do things that you want to be doing. That is the advantage of open source is that you can

end up in an environment where you're working with the tools that you want to work with. But it does take certain talents that a lot of us in this industry either a don't have or b think are a joke. And that's a bigger problem. All right. Mark Manson. Mark Manson is the author of a little book called The Subtle Art of Not Giving a [ __ ] Don't ask

how to start. Start and then ask how to improve. That is absolutely true. If you want to succeed in your career, stop asking, start doing. It seems simple, but it's not. Many of us, many of us are introverts. Probably everyone in this room is an introvert, myself included. Many of us are not just introverts, but we're shy or we lack confidence. So, we overcompensate by complicating our

tool set because it allows us to put it on the resume. I got one guy right here, I don't know what you're talking about. Kubernetes is a perfect example. Kubernetes is a 1% solution. It's a fantastic piece of software for 1%. 99% of of infrastructure out there does not need Kubernetes. Who needs Kubernetes? [ __ ] Google, Netflix, Microsoft. Guess what? You aren't them, But damn, it looks good

on the resume. You put Kubernet me if I put which I can legitimately put Kubernetes and Postgress QL on the resume I could write my damn ticket if I wanted to work like that again. And I don't I recommend the book by the way because a lot of us myself included until recently. Actually here here's a vulnerability moment for everybody which I make I'm sure everybody will

be super comfortable about this. Raise your hand if you ever judge yourself by your peers. Come on. You guys, your best friends, your brothers, right? Why do you do You're not them. They don't know your damage. You don't know their trauma. Yeah. And why do you do that? That's actually a really good point. Um, you know, we're all human. There's and we have good managers, bad managers,

right? Team leaders, supervisors. I pretty sure if I said, actually, let's do this. Raise your hand if you ever had a manager that was a manager because they didn't have anywhere else to put him or her. Right? They had literally their career had plateaued. They were technically not good enough to continue the technical work, But they weren't a bad employee and they knew the team and they

knew the stack. So you make them a manager. You take somebody who likely has the social skills of an ant, really good at being irritated or irritating, but not very good at managing people or leading people. and you make him a boss, So, very good point. Your manager might be looking at them. But here's the thing. Do you know what a good manager looks at? You, not

your competition. A good manager will lift you up and allow you to succeed based on your gifts, including the ones that you don't and the ones you think you don't have. If your manager is not doing that, quit. And I know that's very flippant. You know, I've got a family, I've got bills, I've got a mortgage, lots of layoffs. Google, or not Google, Oracle just announced they're

going to do 30,000 layoffs. That's like 30% of their their workforce. It's about what you're willing to sacrifice. Don't work at Google. Don't aim for meta. Please God, don't aim for meta, right? Work for companies that are doing good work. And a lot of those companies are Joe, mom, Bob manufacturing that need an IT guy or girl. And you'll make less money, but it'll be stable money.

and you'll be home every day by six o'clock and they're going to look at you and say, "I understand your value, not just to this company, but to this culture." That's success. The key to success, I probably should have gave that speech on this slide. It's discernment. Success is all about the choices that you make. Period. The end, right? It's not about, and granted, there are people

that are just in the right place at the right time regardless of their gifts. Zuckerberg. I mean, if any man currently living on the planet kind of fell into the [ __ ] that exists of his money, it's Zuckerberg, right? It wasn't, you know, uh, of course, now I draw a blank. a guy that died from pancreatic cancer because all he did was eat fruit, but he found an

apple. Steve Jobs, there's a guy that literally success killed him. His hubris killed him. He had treatable pancre pancreatic uh cancer. The choices that you make, I'm not suggesting you out your employer. I'm not suggesting that you out your projects that you're not happy with, but what is a choice that you could make that would move you one step closer to where you want to be? And

that's there's nothing wrong with stay staying in your lane, right? There's nothing wrong with that. That can be success. Don't chase accolades. Chase right? everything I did. So, I was the first person to uh write a Postgress book for O'Reilly 25 years ago. I didn't do that because I wanted to write a Postgress book for O'Reilly. I did that because it would further my career. How do

I know this? Because I have had at least a dozen publishers come to me and say, "Please God, write me a book." And I won't do it for less than a quarter million dollars upfront. Because writing books isn't fun. At least not technical books for me. Some people might like it. I personally thought it was grueling and boring and I was writing things that I literally wrote

a book about and made a lot of money off that book that if people read the [ __ ] manual, the book wouldn't sell. But because it had a mammoth on it and it came from O'Reilly and people don't want to read the [ __ ] manual, but they'll read a book that some guy wrote. I I've never understood all I that's all So I I've never written another book. Now

I write articles and stuff and I've been published a lot. Articles are fun because I can get it done in three hours and I'm done. Right. Choices. People don't decide their future. They decide their habits. And their habits decide their future. That is absolutely Anybody in this room that doesn't realize that improvement comes through habitual friction doesn't understand how life works. We are engineered as a species

to seek the easy road. This is why Netflix is so popular. It's why Viagra is so popular instead of I mean and don't get me wrong, I understand that it there are other reasons, but as a general rule, men, we need that pill because we don't exercise. That's why. It's not because we're 60. It's because we don't get on the treadmill. It's because we don't go hiking.

It's because we rather drink our whiskey and watch a western with Clint Eastwood. Yes, thank you. Okay. I mean, that's the truth. especially since I need an ankle. And I forgot to take my arthritis meds this morning, so I'm hurting a little bit. But if you want to find success, you have to improve. The only way to is to habitually fail. Let's talk about your rock. My

wife is actually very mad at me about this Um, her name is Amanda and she is a National Health Board certified health and well-being coach. She also went to Duke Medical School to be a health and well-being coach. She's also the CEO of the company. Uh, she's an overachiever. To her, success is overachieving. And what I mean by that is when she went to take her board

test, she I waited in the parking lot for the two hours or whatever it was and she came out and she was upset and she said, "I failed. I failed. I can't believe I failed. I blew it. I studied so hard. I failed. She got a 90 [ __ ] six out of 100. And she still thinks she failed, But she's been she did that years ago. Years ago.

she was talking to me recently. And she's like, "Look, I think I should start doing workshops. I think, you know, I want to do this and get more clients and blah blah blah. This is all about the coaching, not the the company itself. And and she goes, I want your help. I said, are you sure you want my help? And any married per couple in here would

understand that. You sure you want my help? She said, yes, I need your help. Because our gifts are very different. There's a reason she's a CEO and I am not. I do not manage people. I beat people to death because they are irritating as hell. Okay. She manages people. They're much happier with her being the boss. Well, she said, "Yes, I want your help." And I said,

"Then you have to get out from your rock." What are you talking about? I'm like, "You are so comfortable because you've got the letters next to your name." She did not like that statement. any one of us. I mean, some of us are old enough to remember when having the Microsoft certification mattered. Some of us are young enough to realize that the certifications do matter for about

a right? Once you're an adult and moving forward and you have a career, you got a couple of years of employment. If you're succeeding, the certifications don't mean anything because you've already proven your work. Okay? But she was she was sitting there and she's got the little like NWBHC next to her name and and it's makes puffy chested. I've got this. And don't get me wrong, she

earned it. It's it was hard work, right? I saw her material uh and I'm like, I no thank you. I'm not going to spend my, you know, nights and weekends trying to learn this. I'll just wait till you know it and ask you. Um but what it meant was in today's world what's an what is a way to well in today's world you have to promote if

you want to succeed you have to promote. So now she has a podcast on health and tech. That's actually who she has a passion for. Originally it was for chronic condition um because she has chronic conditions but she realized that we are way more [ __ ] up than people with chronic conditions. We just are. We're we're we get so focused, right? Just the lane. You see a problem

and it's 17 miles away and you won't stop. Even as you get older, I mean, and then all of a sudden you realize, I think I really need to go to bed if I'm going to function tomorrow. So, what is your rock? It's comfortable. It's safe. It's reliable. And it is. Your head is down. You're doing your job. That's your rock. You're paying your bills. You have

a reasonably happy life. You're going on vacation when you can. You know, taking your kids to ball games or whatever it is that they do. That's your rock. But your rock is not promotion except for annual review, 6% raise, maybe, right? Maybe you get to lead a team eventually. You're sitting there and you're like, "Why doesn't my boss see all my hard work? because he's too busy

trying to do his hard work. Don't make no mistake, management sucks. It's not easy. And they do a lot of covering for you. So if you want to succeed, you have to It is the only You have to be uncomfortable. If you are comfortable, you better be retired. Otherwise, you're just not doing. If you're not doing, what's the point? And that doesn't mean you shouldn't have rest

days. Okay? That's not what I'm Success is found in the arena. Who here doesn't know what this is? Be honest. I'm going to assume we all know who Theodore Roosevelt is. I'm going to read this. This is one of his a paragraph from one of his speeches. It is not the critic who counts. It's not your [ __ ] peer. It's not the person that tells you you're bad

or evil or down vote show you on Reddit. Not the man who points out how the strong man stumbles. We all stumble. Any person that says, "H, you failed." Kick them in the nuts. They're stupid. There are people that just want you to to fail. Hello, Mr. Mom Jen. Sir, >> one of the founders of PostQL, folks. do the contributor. >> I still have a contributor. >>

The doc. >> remember we talked. >> Yeah. Yeah. Hey, buddy. How you doing? We've known each other a very, very long time. He's a >> Yes. He's absolutely a pain in the ass because he's a black and white guy. Okay. Black and white guys are a pain in the ass. But and we'll talk about this a little later, he is also a great mentor. And that's important.

it is not the critic who counts, not the man who points out how the mana strong man stumbles or where the doer of deeds could have done them better. The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood, who strives valiantly, who errors, fails, who comes short again and again because there is no effort without

error and shortcoming, failure. But who does actually strive to do the deeds, who know great enthusiasms, the great devotions, who spends himself in a worthy cause, your passion, people, not your paycheck. who at the best knows in the end the triumph of high achievement, success, and who at worst, if he fails, at least he fails while daring greatly, so that his place shall never be with those

cold and timid souls who neither know victory nor defeat. Live this and you will succeed. Remember in the beginning of this talk I said this isn't about what you wish things We all have wish of world peace of true faith of humanity loving one another. It's not the [ __ ] world. If you want to succeed you must be a warrior. Period. That is the only way it happens.

You fail, you get back up, you fail, you get back up. Eventually, you will not fail or you'll pivot, which is all a very success driven word. Pivot. How many of you, and I have some young creatures in this audience, how many of you are on social media? Okay. How many of you are on Reddit? Okay. What about X or Blue Sky? Okay. X and Blue skies

are dumpster fires. Get off of them. They do you no good. They are literal mental masturbation. There's no purpose in them. How about LinkedIn? Good. How many of you have connected with me on LinkedIn in this presentation? It's not what you know, it's who you know. And I know everybody. Amen. Something to keep in mind. I'm not saying you have to connect with me. But that is

true. The idea it's not what you know, who you know is the truth. It's why I go ahead >> connecting with me. So my success at this point in my life is derived from helping people. That's what it is for me. Now it could also be once we connect, you might end up being a podcast guest because I have three or four of them. Go ahead. >>

Well, that's actually a really good question because you probably do. We all do. We all suck. That's the human condition. Is there any person in here who has never said to themsself honestly, "God, I wish that [ __ ] would die." You don't mean it. Usually, I can think of a couple of uh political appointees we're probably not real happy with right now, right? I'm not going to talk

names, okay? That's not what this is about. But I mean, we're terrible. Why would you wish that on somebody? It's just the condition that we are. But the reason I would know you don't suck is I would check you out because I won't just accept a blind connection. You'll come to me and say, "Hey, I was at your talk. You told me to connect. This is me."

And then I get to click and then it shows me whether or not you're worth my time. And that may sound rude, but it's the truth. You may not be worth my time and I may not be worth yours. I've got people leaving the talk now, right? And that's okay. in fact, I'm going to do this. Let's talk about this. What you saw there, she's a gal

named Allison. She has a master's in some rural field. I don't know what it is exactly. It's like land management or something like that. She has a full-time job. She's got a crotch goblin by the name of Ava who is a beautiful little creature. And uh that was her doing her passion. That was her with her child on her hip training a horse while training someone who

wanted to be a horse trainer. How many of you and I not the horse thing but myself included. How many of us have had that passion in the last 5 to sacrifice her job, her career, her current paid career to have a baby, to stay home, to work from home. Very hard job. By the way, training horses is not romantic. To train another horse trainer, she doesn't

she doesn't own her home. She doesn't rent her home. She's provided a home by the ranch that she helps manage. All so she can do what her passion is. I don't know if she has a 401k, but I doubt it. But if I call her right now and I say, "Are you fulfilled?" She's going to say, "I'm broke, but I'm fulfilled." So, what are you willing to

sacrifice for success? See if I can get this to go to the next slide now. Okay. Talked about this. That's the whole man in the arena. Success is simple. It's overcoming failure one step at a Remember, you define what success is for That's why I asked way in the be in the very beginning of the talk, who judges themselves by their peers? Screw them. They've got I

mean, don't get me wrong, respect them, work with them. I I hope you have a great team, but when it comes to your success, you are the only person that defines that. And it may be being a coffee barista. It may be being a garbage man. What is the absolute What is the mo I got a teacher in here? What is the most important or critical job

in a school? Go ahead. The teachers. That is a very common response. You're wrong. Custodian. And I'll tell you why. Because if that man ain't cleaning up your snot and your throw up and your urine and your bully's blood and the food, you're not teaching. You're sick at home, You guys ever get a chance? There's a great And I'm not knocking teachers. Please understand you guys do

critical work, but you're underpaid, overworked. Agreed. I I'm not arguing any of that. But you can't do your job without that custodian. Yeah. >> Well, and work from home. Now you're doing all that clean up, Somebody's doing it, you know. So, yeah, but it's all about what you're willing to sacrifice for yourself to be successful and whatever that means for All right, here comes the professional part.

This is the annoying part of this talk. At least I hope you don't think the first part was annoying. Um, this is the part of the talk where it sounds like I 10 minutes sounds like I read a lot of books about how to be successful. I didn't I mean I've read some I read Daring Greatly for example. Uh but this is really uh and actually if

you want a book that will help you if you're one of those folks it's like I want a book seven habits of highly effective people that is the number one book for success period there is no it it is to success what the Bible is to Christianity okay that's what it is you don't need any other book every time you fail go back to that book every

time you wonder start to feel like you're not succeeding, go back to that book, Seven Habits of Highly Effective People. All right, here's the deal. We want to master the reliability quotient because I only have eight minutes. I've never gone over in my life. Just ask Bruce. The 80% rule. Aim to deliver what you promised. This is absolutely true. Okay? Always deliver on what you promised. High

quality work over time is always going to be rewarded versus fast work get it done. Now that doesn't mean sometimes we don't have to do fast work and get it done. Okay. Sometimes that especially in tech, right? Who loves the term MVP, right? Minimum viable minimum viable product. Okay. You remember when I asked you if you ever said to yourself, I wish they would [ __ ] die. That's

venture capitalists for me. Okay. Manage expectations. Don't overpromise, right? Underpromise, overd deliver. Because if you overpromise and then you deliver, you always overd deliver. Be a problem solver. Do not bring people problems. Bring them opportunities. And that sounds crazy, but it's true. How many How many of you have a team member that every time they approach you, you go, "Shit." Not because they're not a nice person,

but because they have got something to complain about. Everybody in here's got that one. I have one that works for me and I and and I'll get ping. I leave the office. Now, my office is my house. So, I go outside. But if I get that ping, I'm suddenly unavailable because I know that that ping isn't going to be I have this great idea that will make

us all money so that we can go get raises. It's going to be this person and it will not stop. It is it it's one of those individuals that if you ask them a yes or no question, they write back a paragraph. You got those people in your life. Is this black or blue? And you get a Yawn weak. All right. Curate soft skills. This is the

big one. You got to be nice. You got to communicate. You have to be able to say to someone, I really love your ideas and I think that there is an opportunity for this to be successful if we modify instead this is a piece of [ __ ] It may be a piece of [ __ ] but I guarantee you if you say this is a piece of [ __ ] that is

not going to help your career. But if you do it the other way, it will because we are all soft, doughy people with feelings. No matter what we say, all of us. So take that into account. Emotional intelligence, it just means being empathic. You don't know what they're going through. Assume good intent. Active listening. How many of you hear listen to listen versus listen to respond? You're

a teacher, aren't you? >> you were okay. Most people and this is this is the science of it. Most people listen to respond. They do not listen to listen. Shut up and listen because I guarantee you you haven't heard the whole story. Clear communication. Don't beat around the bush. I'm not saying say this is [ __ ] okay? I'm saying be clear and intentional with your communication. Let me

tell you how you'll know that someone's not being intentional with their communication. So, like I was doing this thing like and I'm not sure like and you know like and and Instagram. Okay, that's not intentional. Look people in the eye and say I hear you. Are you saying X? Allow them to elaborate. Be intentional with what you do or don't do it. Build a strategic network. That

was the comment about LinkedIn. You need an accountability partner. We are all alcoholics. Every single one of us. We need someone to say, and Bruce has done this, and he doesn't talk like this. Let me be clear, but I'm going to put words in his mouth. He has more than once said, "J, you're being a dick." And he's not wrong. and we don't agree on a lot

of stuff, but I can go to him. I've known him for almost 30 years now. I can call him any day and say, "I need your advice." And he'll look at me and say, "You're being a dick again." That's pretty much always his response. And he's usually right. And so I take a step back. I have an accountability person and it allows me to say, "Wait a

minute. What? What is it that's causing me to fight so hard? Right? How many of you ever fought for the sake of fighting? You didn't have a reason. Well, or you had a reason, but it wasn't a good reason. Then all of a sudden, you were losing that fight, but you kept fighting for no for for no reason except to fight. Accountability partner sponsor. This is your

cheerleader. You need someone who is above you professionally to lift you up. If you don't have that person, it's a slog and you will not get noticed nearly as quick. The peer, this is your teammate. And then the mentor, Bruce has got 10 years on me, actually a little bit more, I think. He's mentored me through a lot of He's helped me be a nicer person. Let's

just put it that way. Because my communication style, as you can tell, there are remnants of it here, is to say, "That's a piece of shit." It is not to take a step back and actively listen to the opportunity. Priorities prioritize continuous growth. This is the one I'm struggling with now. Upskill regularly. I don't care about Kubernetes. I don't care about agentic AI. I don't care about

any of that because it's all it's all [ __ ] It is just another way that they're marketing to you to control you. I mean, age verification, I don't care about I just I just don't care anymore. So, how do I upskill? I can take you off grid. I know how solar works, how batteries work. And no, it's not as simple as plugging it in. I know it looks

like that, but it's not. There's all kinds of rules around it. And I'm not talking about legal rules. I'm talking about don't blow up your damn house rules or yourself, right? Seek feedback. Again, listen. Be willing to say, "Am I nuts? I've had a lot of people in my life say, "You're crazy, but it's genius." That's perfect. That's per That's exactly what you want to hear. You

want to go to your person, you want to be like D, I just cured cancer. And they're and you want them to say, "You're crazy." And that's If they don't say that, if they're not saying that, revamp, rework, and then they get out of your comfort zone. That's the rock. You got to get out from underneath your rock. If you are comfortable in your job, like you

go and start your job, you do your job, you drink your coffee, you drink, you take more bathroom breaks than necessary, but you do that because you're in your job, and then you go home and all is good. You're not continuously improving. Now, maybe that is success to you, like we have our retired tenure teacher back there, right? that. But that's different. They've already fought the battles.

They've already bled. They've already been in the arena. All right. Key learnings and opportunities. I'm going to skip this because I got one minute. But you see Oscar Bin Laden. That's Kiwi. Kiwi is our matriarch. She's old. She's going to be 12, I think. Oh, and by the way, all these pictures, they're all around my place. Next steps. Define success for yourself. What is one step you

can move forward for that success? Maybe it's quitting your job. Maybe it's learning Python. Maybe it's learning Rust. Maybe it's learning to ride a bike. Maybe it's getting off roadblocks. Whatever it is, you laugh. But I encourage all of you to look up 764 and Roblox. Um, and celebrate each small step because you're going to fail. Remember, there are books and books and books and books and

books of self-improvement. And a lot of us will say, "Common sense, common sense, common sense, common sense." There is no common sense. It doesn't exist. All common sense is is what you know to be true. And to improve, you must continually work at it. It's just like an athlete. Athletes don't magically long jump 22 feet or whatever it is they jump. They work at that for years

and if they stop in a month they won't jump as far in a month. So if you want to succeed you must continuously improve. I think that's it. Thank you very much. I hope it was helpful. >> I have been into they're doing like peer sessions or something like that where you can come and talk to me oneon one. Uh you are welcome to do so and

I invite you to I'll answer. The one thing I will be honest the one thing and Bruce will back me on this is I'll tell you I'm not going to blow wind your ass not who I am. Thank you so much Joshua Drake. Like he said um there's the open source career day. You can go scan the QR codes out there. Um up next we have Eric

Hendrickx. He's going to be speaking on From Bash to Burnout, staying sane in a 247 tech world. Eric is a longtime CIS admin with deep operational experience who has lived the reality of 3:00 a.m. alerts, systems worth millions of dollars, and the pressure of being the one responsible when things go wrong. Today, he'll talk about the very real problem of burnout in operations, and share the practical

rituals he developed after going through it himself. Please join me in welcoming Eric Hendricks. check one two. Hey. All right. How are we doing on time? Three after. All right. So, sorry, sorry, sorry. Good morning. >> Morning. >> So, uh, day four of scale. Who how many first- timers? >> Me, too. This is my first time. So, really glad to be here. Really excited to be a

part of open source career day. Um, so my name is Eric Hendricks, aka the IT guy. Uh, I am a technical product marketing manager for CIQ. In other words, I go to conferences, write blogs, and my kids are jealous that I make a living off of YouTube. So, um, that's a little bit about what I do. Uh, you can stop by CIQ's booth, uh, number 412 over

in the expo hall. Uh, be open till 2:00 today. But I hope since you're here that your plan is to take full advantage of open source career day. Uh, when I was approached to do this talk, um, goodness, I think it's catching up. Is is it me or you? Yeah, if you don't mind. >> Test. >> And I've always hated these. Makes me think I'm Britney Spears.

>> There we go. Much much better. Much more comfortable with the with the mic. So, u All right. So now now that you don't hear me breathe um so I uh I wrote this talk uh after some events that happened to me in 2025. Um so u 2025 was a makeorb breakak year for me for my career for my family. Um and uh you know I think

one of the keys to communication is honesty. And to be honest, this this talk isn't just for you all. It's for me. Um, it's a little cathartic. Uh, especially when I found out that a really close friend of mine who actually helped me through a lot of this uh lost his teenage daughter last night. So, I'm going to do my best to get through the talk today.

Um, but a lot of this hits very close to home. So, if I were me sitting in the audience, I I'm going to be a little arrogant here and say that the next 40 minutes or so are worth you putting your phone down. It's worth putting your laptop away. If you're working on work, this talk is for you because it's a Sunday morning and you're at a

conference. So, not calling out any names, but it's it's worth your attention. It's worth taking notes because this kind of stuff literally can make or break you. So, thank you to to Joshua Drake for kicking us off this morning um with his nice upbeat uh talk. And now we're going to get into something a little bit more realistic um or not realistic um we we'll get into

something uh a little bit more practical. Uh these are these are things that you can build into your life into your patterns u that uh that will really help you. So, uh, a piffy title from from bash to burnout. Uh, a little bit about me. I was a systems administrator for a number of years, uh, with a with a primary focus on Linux and open source operating

systems. Uh, since then, I've moved over to the sales and marketing space, uh, predominantly in the technical marketing side. Uh, so like I said, YouTube videos and blogs and all the fun stuff. Um but um one of the things that has helped my career in the past seven years since moving into into the product side of things was I did spend years as a systems administrator. Um

some of you may be too young to remember what a pager looks like but I carried one. Yes. And and you can't call out only only call in. Um, so I don't know I don't know how many operations folks or on call folks I have in the audience today, but many of you can probably relate to your phone sitting on your chest. It's 3:00 a.m. and that

server is down again. Not for the first time, not for the 10th time. You've lost track. There's no one else to call because you are the on call. You're alone in the dark and you're just waiting. Is that server going to come back up and we're going to have to drive 30 minutes across town at 3:00 a.m. to go and manually reboot this thing? It's not fun

to be there. And there's a problem with this. What we call dedication, heroics, those uh th those are are not uh healthy ways to think. being the superhero every single day at work. That's that's not working. That's that's surviving. And survival survival mode leads to burnout. So, little poll of the audience. How many of you have worked through a holiday weekend? How many of you have canceled

plans for an instant? In fact, uh I went through uh I went through an instance where I distinctly remember placing an order for medium rare steak, very very nice pour of whiskey. It was a girlfriend's birthday or something, real fancy dinner. The whole family was going out and I spent most of dinner with my laptop on the trunk of my car, my hotspot because hotspots weren't on

cell phones yet, and my cell phone on speaker while my uh while my significant other and her family were enjoying their dinners. I was rebooting a server. How many of you uh check your phone before going before you talk to any human being just to make sure that that server hasn't fallen over again? Yeah. So, you know what I'm talking about. These are the heroics that define

our industry. There's something I want you to write down or put into your phone or remember. Burnout is not a personal failing. It is not your fault. It is not you. It's a systemic pattern in an industry that treats exhaustion like it's a feature. Let me say that again. Burnout is not a personal failing. It is a warning sign that your body gives you to let you

know when something is wrong. And so to outline the rest of my talk, I want to share some numbers to you with you, some statistics that uh floored me quite realistically. I'll share what happened to me in 2025, some things I did well, some things I could have done better, and some practical tips for identifying burnout in your own life. First off, the numbers don't lie. 55%

according to a 2025 study, 55% of employees that were pulled report feeling burned out, feeling unenergized at work, feeling exhausted. 55%. That's not just that's that's not tech. That's the working class in the United States. That's that's your doctor. That's your attorney. That's your teacher. 55% of the US workforce says, "I could really use a freaking vacation." And in tech, the numbers are actually higher. In fact,

senior developers that were pulled in a story uh story block developer sentiment survey, let's try to say that five times fast. 58% of senior developers are considering quitting because of legacy software. They can't make things work. They're tired of having to fix things heroically. 58% that's a lot of senior developers. That's a lot of years of experience that are ready to just walk out the door. Something

else I want you to write down, put in your phone, memorize. You're not bad at your job. Just because you're burned out doesn't mean that you don't have the skills to succeed. You're you're in a profession that sets you up to be in these situations. And if you aren't there, I I don't know how many of you got comp time, but I've worked in I've worked at

businesses that it doesn't matter if you were up for seven hours overnight on a on a conference call um where all the senior leadership and all the developers and all the administrators and all the database guys were all on the same call trying to hash it out. Those businesses still expect you to be at the office brideeyed, ready to go 8 am Monday You're not bad at

your job. You're in a situation that sets you up to fail. We need to make changes in our industry. Open source, one of the biggest issues in open source right now is sustainability. Developers are aging out or they're burning out. I I know I've had friends in this industry for over 10 years that have just said, "You know what, Eric, I'm done." There's no amount of money

that can make it worthwhile. oh my gosh. Hi, I'm Eric the IT guy and I clearly don't understand how screen mirroring Wow. There there is no piffy joke, no comeback I can make that test your systems, Eric. >> This is true. Luckily, I don't have a live demo. My gosh. Oh goodness. Thank you for pointing that Uh today's today's uh background is brought to you by Digital

Blasphemy. He does uh some really cool artwork. Uh he's got spacecapes, planetcapes, uh all kinds of stuff. So, thank you Digital Blasphemy for being uh oh goodness. There's there's no coming back from that. How about that? So, some some of the uh some of the quotes I have are actually in the deck and as I as I understand there's a GitHub repository where I will uh post

my slides. Um All right. May maybe I did that on purpose. Maybe we staged that just because we're getting into the heavy There you go. Yeah. Thank you. All right. Let me let me find my rhythm again. So, 2025, I'd been working at a company for five and a half years. This company was my identity. I loved who I worked for. I loved what I got to

do. I loved the people I worked with. And uh I changed teams thinking I could make a bigger difference. And instead, four months later, I got on a call that lasted all of seven minutes and a five and a half year career came to a very unexpected close. Over the next several months, I lost my identity. I lost a friends group that I had. You know, everyone

always says that, "Hey, we'll we'll keep in touch. Let's connect on LinkedIn and we'll we'll we'll keep talking. Which by the way, there's a talk later on today about using your social network. Uh, highly recommend you attend that one. I think it's a workshop. Um, I lost my financial security. I won't go into details, but um, my home life shifted drastically. And so, where I thought I

had a rock, I found myself alone. I uh as you all might be aware the uh tech industry is in a bit of an upheaval right now just because of the economy because of uncertainty around AI uh quantum computing is a question uh as as to how it's going to impact technology moving forward. So, I spent 96 days, not that I was counting, working overnights at a

gas station, working overnights. Guess when most job interviews are in the middle of the day, which is the middle of my sleep cycle. I can't tell you how many interviews I went in slap happy or or just don't remember how they went because I was just that sleepd deprived. 96 days. And my my case is actually somewhat positive. I know people that have been out of tech

work for years. Their career now is Uber driver because jobs shift that much. That's what I said earlier. It's not a personal failing. We are in one of the most chaotic times that I have ever seen. So, the the good news is after 96 days, I actually got two job offers within 48 hours. I'm an adjunct professor at a community college in Kansas City. That was a

fun uh that was a fun challenge that I almost said no to. Glad I didn't. I'll talk about that here in a minute. And then uh uh eventually uh made my way over to CIQ. Uh we do Linux high performance computing. Uh, and I get to I get to continue to build the open source relationships that I've been I've been enjoying for the last 16 year uh

11 So, thank you. So, I promised some practical steps. So, first off, let's talk about what burnout actually looks like. How do you identify The problem with burnout is, and I I was having this conversation over drinks last night. The problem with burnout is it doesn't just show up one day. You don't wake up one day and go, "Oh gosh, I'm burned out." It is a long,

slow, quiet process. You just you don't just stop caring one day. Some point you just shut off your camera in team meetings. just don't want to be seen. You stop participating in the random channel on your team Slack. You stop engaging in social hours. You get a little bit more tired each day doing spreadsheets, building slide decks, building software. It happens slowly and quietly to the point

where you wake up one day and all of a sudden that bed looks a whole lot better than going out and making a living. So, what does what does that look like? Let me give you a few signals. Uh, I don't remember where I found this term, but I kind of liked it just because it sounded really technical. Something out of Star Trek. Energy flow inversion. What

does that mean? So, I told you that uh at at the company I was working for for five and a half years uh that I'd changed teams. And I could tell within about 3 months, about three and a half months on that team that it wasn't what I wanted to do. Took me away from the tech, took me away from the community. But I told myself, I'm

going to give this a year. The company I was at very very much supported u uh moving in into different teams and departments within the company, but you had to be in position for about 12 to 18 months. Said I'd give it a year. I will give it my all. I will build these sales presentations. I'll work on these pricing books for a year. I can do

that. 36 hours later, I had my meeting. Energy flow inversion is when you just explode at work. You nothing's working. You have a fight with your boss and then you get home and maybe have kids or a spouse or even a pet that wants your attention and you just have no energy. The only thing you do is you go sit on the couch, play a game on

your phone or you go up to bed and rewatch that episode of Friends for the 15th time. Signal number two, this was my big tell. The irritability spike. As you can tell, I tend to smile. I tend to laugh even at myself uh in front of a room full of people. Um but you get irritable all of a sudden. You're not cracking jokes. You're you're not this

you're not uh the social person. Instead, people around you really start to notice. And that's that's what Josh was talking about. You need to have those key people in your life to be able to have that. Uh think of it as like the canary in the coal mine. They're the people closest to you need to have an open channel to you to be able to say, "Hey,

you know, you really didn't handle that meeting well." Or, "Hey, the the way you went off on our kids, that's not okay. That's not you. What's going on?" Signal number three, and this is really hard for technologists, obsession or diligence. If I can just build that last server. If I can just get that last commit. If I can just if I can just and then all of

a sudden it's been three weeks. When was the last time you went outside? When was the last time you took a break? There's a difference between caring about your job and not being able to separate from it. Is your job interfering with sleep, with games, with family, with just being present in the moment at that family dinner? Are you too busy catching up on Slack threads, reading

Git commits, or are you there present with your family? Kind of mentioned this a little bit, but signal number four, social isolation. It starts with turning off your camera and it ends with just completely disengaging from the people at work or people in your own home, people in your social groups. you all have some homework for the next 60 seconds. Don't raise your hands. Don't don't count

out your fingers. But in your own minds, I want you to ask yourselves these questions. What's my energy level on a scale of 1 to five? Do I feel empty? Do I feel strong? How's my irritability? Am I peaceful? Or does every conversation, every interaction, every time that jerk cuts me off on the road, is there friction? How connected do you feel? You feel invisible or do

you feel in just energized, connected, plugged in? This last one hits me pretty hard. How much of your identity lives with your job? A lot more than I was willing to admit at the time. Is it just a job or is it everything? Those those four or five items are your signals. Those are the things that you and the people closest to you need to be watching

for every single day. And if it's a healthy network, you'd be doing the same for someone else. Now, what do the patterns of burnout look like? How do you get there? This one's this one's hard for for technologists. The hero trap. It's that that concept of if I can just if I can just do this. Problem with it is there's always going to be another bug. There

will always be another patch. There will always be another server that could use a nice performance tuning. It never ever stops. And the problem is the IT culture rewards suffering. What have you done for me lately? Doesn't matter that you had 99.98% uptime. What about that fourth nine? If if you can just put in overtime another six weeks, maybe we can hit that fourth nine. My least

favorite, and this one feeds my irritability spike. Context switching I'm a CIS admin. I'm building a server. It's a happy day. I've got music playing. Linux is installing. I've got Anaconda on the screen. It's a good day. I get to build something new. I love building things. It's fun. Let's install something new. Let's spin up some Docker containers, right? Nope. That database server fell over again. Oh,

by the way, while you're rebooting that database server, I've got a PR that needs to be reviewed. Can Can you review Oh, hey. I I know you're going to work on this project next week, but we've got a status meeting with upper management. Anybody relating to this or is it or is it just me? And then three hours later, couple of extra cups of coffee, some swear

words under your breath, or maybe not. Then you get back to that server that you were so excited to build or that application that you're so excited to compile and you go no I don't want to context switching according to a survey done of DevOps teams cont I speak for a living context switching is the primary drain of productivity you start working on this thing you get

drugged over here then you get a notification you're drugged over there 15% performance drain is a conservative estimate. Every time your brain switches tasks, it takes you 15 minutes to reapply yourself to a new task. And if you're doing that over and over and over and over, you realize four hours has gone by and what have you achieved? Nothing. This one hurts because I love this one.

In our culture where we always be learning, there's always something new to learn. I'm a Linux systems administrator and I would love to get my hands on Kubernetes. I would love to understand it. I think it'd be so cool to run a Kubernetes cluster in my virtual environment. But let's be real, I'm a single father. I'm a dungeon master. I'm a I'm an adjunct professor and I'm

working at a startup which doesn't uh which doesn't have Kubernetes as one of our products. So guess what uh guess what's been sitting on the back burner? Learning Kubernetes. I'd like to learn Python. That's much more applicable to my job. No, I ain't got time for that. I got I've got I've got party members to murder with the dragons. I mean, help them tell a story. All

my D and D nerds are are geeking out right now. Pattern number four, the identity trap. This is this is a quote from from myself actually. Uh I found it in uh in a journal that I' I'd been keeping during 2025. I was so wound up in who I was in that job that when it ended, part of me felt like it ended, too. Anybody relate to

that? It hurt. Here's the lesson that I learned, and I'm trying to figure out how to apply it now without losing part of myself, but also without uh but also without losing that spark that makes me unique in the industry. When your employer is your community, your purpose and your identity, all of a sudden something like a reorg becomes an existential crisis. And that's that's not over

the top. That's not not marketing hype, marketing It really does. All of a sudden, there's cutbacks or there's changes at work. And it's not just work now that's unsettled. It's everything. the people that I talk to, my income, my my complete identity, how can I how can I function if that's going to change? So, I told you a little bit about what and like a good systems

administrator, I did a postmortem. I wish I could say it was blameless. It was not, but I came up with a few things that I did right and a few things that I did wrong. So, I mentioned a meeting. I'd been in this role almost four months, and all of a sudden, my boss's boss throws 15 minutes on my calendar for the next day. I was like,

"Finally." I was wondering when she was going to get around to saying hello or welcome to the team because I knew her before I moved moved apartments. So, my my boss's boss throws 15 minutes on the calendar. Cool. Just 15 minutes, gets chat, and you know, woman I I respected, leader in the industry, leader in the company. But I joined a Google Meet and I waited and

I waited and then not one but two people entered the room at the exact same moment. My VP and you all know who I'm going to say next, a representative from HR. My stomach dropped. My brain went blank because I knew exactly what was about to happen. I didn't fight it. Didn't argue. Didn't ask why. I knew what was happening. I mentioned working overnight at a gas

station and I forgot I had these slides in here. Working overnight shifts, lifting 60 lb crates over my head. I lost 15 pounds, by the way. It's not a not a diet plan I recommend, but it was enough. It kept me going. it uh it didn't bring in the uh the salary I was I was uh used to but it uh you know it was something so

what did I do right what what were my wins the same day I got I got the notice I I was given 30 days and I was taking taken off all my work projects so I basically had 30 days to find something um one of the things I did right was I reached out to my network immediately. I've made contacts, friends, colleagues, co-workers across this industry, largely

from events like this and their associated online uh groups. I reached out said, "Hey, this is what's happening. If you know of anyone that could hire someone with my skill set, please let me know." And funny thing is my my network uh of of friends and co-workers really impressed me because not only did they just not only did they say, "Hey, yeah, I'll keep an eye out."

Or, "Hey, I know this guy at this other company that's looking," they actually checked in on which was something I didn't do myself. which I'll talk about that here in a moment. But they checked on me as a person. Not just Eric the the IT professional, but Eric the human. I stayed visible on LinkedIn. I didn't want to. I just lost my career, my identity. I didn't

want to be on LinkedIn posting about Linux tech tips. Y'all on your own. I don't care. I just lost my job. But I stayed on there. I may may not have had some input from from chat GPT just to keep things going, but I stayed visible. I built a daily rhythm. Work, learn, rest, time off, apply to a new job. I built built my schedule in I

mentioned becoming an adjunct professor. That was an interesting challenge. But I said yes to an unexpected opportunity. In fact, one of these days I may say goodbye to technical marketing and and become a full-time professor. That's kind of my semi-retirement plan. And kind of a piffy one, but true. I rewatched Argate SG1. Find find those comfort shows. Find those comfort activities. It doesn't matter if you've watched

The Big Bang Theory through six times. Do it again. Find something that you can relate to. Find an anchor whether that's in a partner, whether that's in a hobby. reidentify with yourself and I'll talk about that in the next section when we talk about the the uh practical tips. Now told you it was a mostly blameless post postmortem. What would I do differently? When you lose a

job, whether it's something you identify with or it's just an income, it's still a loss. Given how invested I was in my company, it was part of my identity. I literally lost a part of myself that day. What I could have done differently, I immediately started looking for jobs. I immediately started looking for work. But what I should have done was I should have taken time to

grieve. It doesn't matter the kind of loss, whether it's the loss of a person, the loss of a pet, the loss of an identity, the loss of a hobby, um the loss of your health, a loss is still a loss. Your brain doesn't care. Your body doesn't care. It is part of you and you lost it. Take time to Quality over quantity on applications. This is important.

This isn't a talk on how to get a new job, but my quick tip is don't send out a hundred resumes. Don't just flood the market with jobs uh with with uh with applications that don't really match what you're looking for. Instead, pick three or five opportunities a week. Research the company, research the products, research their technologies, and really put in some effort into a cover letter.

see if you know anyone at the company. Quan uh quality over quantity. One thing I did was I'm I've got a podcast called the IT guy show and I stopped doing that too and so I complicated matter matters further because I'm I'm a podcaster. I'm a content creator and I stopped doing So in losing my my pime primary identity as an employee at this company, I also

took away my my voice in the community which further aggravated the situation. Don't step away from the things you still have. Job hunting is a job. It is the worst job you will ever have. The boss is terrible. The pay is atrocious. that that wasn't something I found online. That's something I told a friend while I was job hunting and uh I wrote it down. It is

the worst job you'll ever have. So, what do you do with the job? You build a schedule for it or it'll consume your ever waking hour. and the hours you're also supposed to be asleep. Build it into a schedule. For the next hour, I'm going to research companies with with positions open in my field. Then an hour after that, I'm going to work on a Python course.

An hour after that, I want to watch Stargate and eat lunch. the the important thing about this track and what really excited me about Open Source Career Day is it's supposed to be practical. That was one thing that uh was was communicated very well when uh when I was asked to give this talk. Practical steps. What can you take home on the flight tomorrow or this afternoon

if you're flying home today? Um what what can you take home and implement immediately? First thing is automate the things that to the automate the toil that drains I am a single father with a two-bedroom apartment and a daughter who doesn't mind helping me clean, but I've actually hired a cleaning service. They come into the apartment every two weeks and they clean. It's one less thing I

have to worry about. It's just that much more space in my mind and in my schedule to focus on. Some toil helps you build skills like I'm glad that I built Linux systems by hand for years before I found tools like Terraform and Ansible. But things like cleaning, something that I can hand off to someone else, especially if I'm in a season of healing, script it, delegate

it, eliminate it. Figure out what is draining you. Get rid of it one way or the other. Build a daily rhythm and protect it. Job hunt block, learning block, recovery block. Put put it on your calendar like you would a meeting if you have to rebuild a routine that you can you can grow with. And not not every block has to be pro productive. Like I said,

Big Bang Theory is one of my one of my favorite shows. Stargate SG1 was was a big big favorite of mine. It was completely unproductive. I knew the outcome of the story. Jack O'Neal comes in at the last moment, saves the day, and then they exit through the Stargate. Roll credits. But it gave my mind time to heal. It gave my mind something to connect to that

was familiar and comfortable in a job situation that wasn't. This is one that I'm still working on. Number three, build a life that isn't Put it in put it into into blocks. You've obviously got your day job, but then you need some things that aren't directly related. I do community podcasting. I teach a Linux class for a college. Um, those are things that that are indirectly related

to what I do for a living. But then I've been focusing on building connections and routines that are definitely not related to what I do on a day job. Um, like playing D and D. I'm trying I I'm I'm a dungeon master as I mentioned, but I am trying to figure out tools and methods that I can use to run my campaign without a screen. Did you

all know that paper books are still a thing? They're still out there. As much as I as much as I can, it's harder when I travel, but as much as I can, I actually try and read a paper book. Why? Because it's not a screen. So, I I mentioned working at QuickTrip for 96 days overnight and losing 15 pounds. Don't recommend it, but strength training actually has

been a big outlet for me. There's nothing better than being frustrated with with the situation at work and going and hitting the gym. Best workouts I've ever had. I've worked out angry. It's been great. Have a fight with your spouse? Don't argue with them. Go to the gym. Be doing everybody a favor. Take care of yourselves. Take care of your body, your mind, your spirit. And uh

a pro tip, work life balance not a thing. You'll never find it. There will be seasons where work will dominate. For the last few days, I've been here in Pasadena at scale. Tomorrow morning, I will fly home to Kansas City and we'll spend the next three days not sleeping much because we've got a major product release, but that product releases on Thursday. And so when the marketing

materials are scheduled uh on our website, on our social media platforms, I'm not going to do any work this coming weekend. I've been away for a trip and then a major product release. And then I want to make sure that I spend time with friends, spend some downtime. See, what show am I currently binging? Starfleet Academy right now. We we can we can discuss that later. Uh

and then and then next week I'll be back at it. I'm going to be recording an episode of my podcast. Uh we've got another product release in April. I'm going to Linuxfest Northwest, which I have another talk I need to write. Should probably put that on my agenda. But it's all about it's not about perfect balance all the time. It's about remembering that there's times where work

will require a lot of your effort. But then there's times where you need to focus more on you. Tip that I that I kind of stumbled into. Maintain three relationships with no agenda. There's people that I've worked with uh that I check in with couple of times a month. Sometimes it's just a LinkedIn message just, hey, how you doing? You know, I saw you got this achievement

or I saw you got this job offer. You know, how's that going? What how's how's work? What are you doing? How's what are you thinking? Other times it's, hey, Eric, I really need to chat. Sure, no problem. Put 30 minutes on my calendar. Let's let's meet over Zoom and let's just talk. So, if you don't have that network, start building it right now. There's a workshop later

today to help you do that. But maintain three connections. Doesn't matter who. Don't need an agenda. Just connect with Something that's important to remember is you can't build those types of connections. You can't build that mentor mentee relationship in the middle of a crisis. So if you're the the thing about life is that you're either recovering from a crisis, in a crisis, or getting ready to head

into a crisis. Sorry, but it's true. If you're if you're coming out of a crisis and you're healing and recovering, good for you. But guess what? There'll be another one. So, if you're not in crisis, if you're coming into one, coming out of one, work on building those personal relationships. In fact, my network actually is the reason why I have the jobs that I have at CIQ.

Some people knew me, knew my and uh they told my VP of marketing about me. And December 26th, I spent seven hours with the CEO and the VP of marketing going back and forth. spent seven hours on Google Meet with two different people talking about a position. I actually turned it down three times in the last year and a half. And then uh then my VP of

marketing finally convinced me to join the company. But it's because of my network. It was because of the types of stuff that I put on LinkedIn that people knew about my work. The other one, the adjunct professor, was somebody in my DevOps Kansas City community, saw the posting for Johnson County Community College looking for a Linux professor, and they're like, "Eric, what do you think about teaching?

I'm not a teacher. I'm not going to do that." No, wait a minute. Actually, almost didn't apply. But the more I thought about it, it's like, what am I doing right now? What what do what do my tech tip videos do? What does my podcast do? Oh, wait. Technical marketing is almost like teaching. Well, funny side note, it's actually not two weeks in two weeks into teaching

my class, I was like, what am I doing here? But at the end of a 16week class, so we we'd kind of sorted it out. And the best u I'm going off on a tangent, but I'll finish my story. Uh the the best feedback I got from one of my students was uh he came up and asked um so is this the only class you teach? I

was working on my schedule for next semester and your name didn't show up. They enjoyed my class so much that they wanted to take another class with me. So, I don't I don't tell you that story to brag. Mostly just because it makes me laugh, but also because that can be each and every one of you. Find those people in your life. Build that network because at

some point you're going to need it and at some point they're you're going to at some point they will also need you. Which brings me up to I think my last point uh which is ask for help and mean it. Reach out and say, "Hey, I'm hurting. I need help. I need help finding a job. I need someone to talk to. I need someone to vent to.

This isn't fair. I just need someone to talk to. In fact, if they've been through burnout or if they've been through job loss, so much the better because maybe like this talk, they have some feedback. And uh and kind of as a sub bullet to that, one of the biggest tools that has helped me in relationships, systems administrator, problem solution. That's how my brain works. There's a

there's a bug, there's a fix. That works with people too, right? No, not always. So, if you have a partner, would like a partner or work with people or know people or have seen a person, write this question down. This has saved me so many arguments. I hear what you're saying and I need to know. Are you asking for a solution or are you asking for me

to listen? That helps everybody involved. My brain is no longer trying to fix a solution. Instead, it's like, I need to be here. I need to be present. I need to be affirmative and supportive. Even though in the back of my brain, it's like, oh my gosh, give me 30 minutes and I can fix all of your problems. asking for me to listen? Saved me so many

fights with so many people. It saves relationships and your sanity. I cannot oversell that statement enough. All right, so to wrap up for me, for me the best admin isn't the one who never sleeps. The best developer is not the one who The best project manager, the best people manager, the best whatever position you're in is not the one who never sleeps. It's the one who takes

care of themselves physically, mentally, emotionally, relationally. Trust me, I have an apartment. I work from home most of the time. I parent at home. I live at home. I eat at home. I work at home. I play at home. I sleep at home. By the middle of the week, I am stir crazy. It's why Wednesday nights are my self-d night. I take myself out to dinner. I'll

even dress up. I'll even shave. I I treat myself well when I go out on a date with myself. I take me myself out to live music. There's a bar not too far from my apartment that has acoustic music every Wednesday night. to the point where the bartenders and some of the musicians know me at least by face if not by name. But it gets me out.

I love music. I love going out to eat and it's it's it's my midweek reset and it happens to coincide with my parenting plan that Monday and Tuesday my daughter's with me. Wednesday, Thursday with her mom. So Wednesday is just my reset night. Sometimes I'll take my laptop and do some work if I feel like it. Other nights don't even pull out my phone, just listen to

the music, eat some food, have a drink. Sustainability is probably one of the most important skills you could possibly develop. Reliability requires maintenance. Just like a server, just like a codebase, you have to work at it. You can't just write the code once and leave it. You can't just spin up a server and leave it. It just like your brain. You need to reboot your mind every

now and then. Few weeks ago, I felt really bad because I spent a sat a a a Sunday that I could have been unpacking those last few boxes and instead I laid in bed until noon. I needed it. My body said just rest. And I'm glad I did. Granted, those four boxes are still sitting in my living room, but I got to binge a show and just

So what do you what can you do next? I will upload my talk so you get to see all the slides that we missed. But there's um and I hope that you took some notes that you took a few things away from this talk that you wrote down some of those some of the signals some of the patterns and some of the defenses against burnout because it

is a real thing and it hurts. But you don't have to wait because there are things you can do right now. And this sounds like a marketing pitch, but I'm going with it. Opening up, I think, right now, if not here momentarily, there will be consultations out these doors where you can go and have a conversation with an expert or me uh that you can't necessarily bring

up with your boss. There are people from all over the industry, all over the country, all over the globe that are out there ready to talk to you about whatever it is you need, technical, professional, personal. And then there's a workshop coming up in room 104 right next to us about burnout prevention from for engineering teams. So if burnout is something that you're dealing with right now,

I highly recommend you go attend that workshop. There's a workshop later on uh right after that about building a network. I talked about building a network from the perspective of growth and uh protection against burnout. But that's not the only thing a network's good for. I got to spend several hours with members of my uh network last night playing card games, teasing each other over drinks. It

was fantastic and I won the last game and then just noped out and went to bed. But having a network, both personal and professional, is so important. So my closing thought, if you're in it right now, know you are not alone. You aren't. I promise you there's somebody within one or two circles of you that is going through the exact same thing. And like Joshua said, and

this is something that resonates with me, is you never know what's going on underneath that smile. You never know what is boiling right underneath the surface. Assume good intentions and just connect with people. So in the next week, if this is you, take one step. Put in one application. Reach out to one person. Just take baby Oh, how about that? So, my QR code obviously didn't upload

into the slide deck well, but I'll I'll have it pull it up on my phone. But I love to make connections with people. I love to talk. Uh I love to share uh share stories. So, I'm Eric the IT guy. Hendricks. Please feel free to reach out and connect. Uh I'll be available at the uh consultation table um I think all day. Um but uh you can

also check out my podcast, The IT Guy Show. In fact, uh a few months back there was an episode where I talked to a couple who has developed a workout regimen using swords to battle burnout. So it was it was a really fun episode. We had a lot to talk about. Um so definitely check that out if you'd like and be sure to stick around. There's plenty

of consultation LinkedIn uh not LinkedIn but professional head shot there's workshops there's more talks like this so thank you all for uh attending really appreciate your attention and your patience with me and my technical issues uh but thank you all very much and uh look forward to seeing you again at the next scale over the ears. >> Yeah. And then the other guy put the um stick

underneath his ear. >> Maybe that's what I need to do. >> I hate headlights. >> Thank you. Appreciate it. >> Uh yeah, the talks are He was pulled back into emergency operations and spent the day at ground zero. Today, Scott works at Oracle and shares how skills from careers that came unrelated like emergency medicine or mechanical troubles can translate directly into debugging, problem solving, and driving tech.

Please join me in welcoming Stros, >> that's like the best introduction I think I've ever gotten for anything. My wedding introduction wasn't even that good. That was awesome. So, as you said, my name is Scott Stros. I currently work for Oracle as a developer advocate on the MySQL team. Um, before I get into all the stuff that we're going to talk about, which hopefully you guys can

take and use for yourselves, I need to get into my obligatory I love me slide. I am a full stack developer and I have been a full stack developer for longer than the term full stack developer has actually been in existence. Back then we just called ourselves developers even though we did everything. Um as the title of the slide or the title of the presentation should let

you know I was a paramedic. A paramedic for almost 15 years. In that time I delivered three babies which I think is really cool. Even cooler one of them their middle name is Scott because I delivered him in the back of the ambulance. I like giving things away. At the end of my talk, I'm going to ask you a question about something you saw or something I

said. The first person to get the question right by raising your hand, not yelling out the answer, is going to win a dolphin. This dolphin, not that one. And then lastly, that cute little guy in the screen, that's my best friend in the world, Murphy. He is my dog. He's a Labradoodle. He spends all day every day with me in my office. Most of the time he

spends it underneath my desk laying at my feet. And he knows more about code and databases than any other dog in the world. You know why? Because when I have a problem, I talk to Murphy about it. And he looks at you with those eyes and the solution just comes to you magically. But this is Murphy four years ago when he was a puppy. This is Murphy

now as the 112lb beast that he has grown into. And this wasn't this trip. This was a trip a couple years ago where I literally brought my suitcase down and he came over and he was like, "Dad, don't go." So, give you a brief history of me. Like most people my age, I was introduced computers in high school. Um, mostly because computers didn't really exist until I

was in high school. Yes, I am that old. Uh, I learned programming initially on a TRS80. My first programming language basic, my second programming language, Pascal. My high school actually had a Pascal class and I loved it. I really loved doing stuff with computers. I thought they were awesome. I used to have a Commodore 64 computer. Uh, there was a program for Commodore 64 called Graphics Basic.

And basically what you did was you wrote basic code and when you ran it, it generated graphics on the screen. And I would spend hours creating neat little designs by just using different parabolic equations to see how the randomness of it would look. Um I also use I also did some focus thing where I don't know anybody here remember like the old MTV where like the colors

used to flash and they would all change. I actually made something in in the Commodore 64 graphics basic where it drew the M, drew the TV, and then the colors kept rotating around. That took me a long time. Um, after high school, I wound up not going to college due to reasons beyond my control. To make it feel like my time away from college was not wasted,

I actually joined the local first aid squad in my town. It was volunteer. You only had to put in like one night a week. Um, and it not feel like I was wasting my time, like I wasn't being a slouch, you know, I wasn't I was doing something. But I never lost my love for computers. Even though I didn't have one after a while and I didn't

have a need for one where I worked, I still always liked computers. And then I got to a point in my career where I did something about Now, how did this happen? A question I get from a lot of people, I've been speaking at conferences for over a decade, well over a decade. And the question I get most often when people find out that I used to

be a paramedic is h how how did that happen? Like how how did you go from from there to here? You know, it just because they these people think they're they are such different careers. like how is it possible you were successful in one and also successful in and I actually spent a lot of time over the years thinking about yeah how that doesn't really make sense

how is it possible and I come to realize that there are a lot of skills and a lot of mindsets that I honed in my years as a paramedic that have benefited me as a and the way it actually happened was so I worked for there was a period of time where I was the operations manager for the largest EMS company in the state of New Jersey.

I had about 400 employees underneath me. And I realized I had no more upward mobility because the only two people left were director of operations and president of the company. And I knew neither of them was going anywhere anytime soon. So I started thinking about what's next. What should my next step be? Did a lot of soulsearching, talked to a lot of people. I thought about going

into teaching. My wife thought that I would have been a I would have made a fantastic teacher. Um, I thought about doing a bunch of different things. After talking to some people that I worked with, some people in my family and other people I knew, I decided I wanted to go into computers. Not really knowing exactly what it is that I wanted to do. I actually signed

up for MCSE training, Microsoft certified systems engineer. Um, I finished the training. I didn't get all the certifications for that. However, I am a Microsoft certified system architect for um Windows 2000. That's how long ago it was. Okay. Windows 2000 was had just come out when I started this class. And the president of the EMS company told me when I was in school, when you're done and

you feel like you want to move on and you want to you feel like you want to leave, come talk to me. So the day after my last day in class, I walked into his office and I said, "Vince, I'm done." and he goes, "I want you to be my web guy." Now, to this day, I'm pretty sure he had no clue that what I went to

school for had nothing to do with web development, but I decided I'm going to take a chance. I had I I knew that I had resources available to me that I'd be able to actually succeed in it. It wasn't completely foreign to me, but it was foreign enough to where there was a little bit of panic, but a whole lot of excitement about what I could do.

And over the over the basically for two years because I did that job at that company for two years, I was getting paid to learn. Yes, I understand how completely amazingly lucky I was to have that opportunity fall in my lap. And if I'm going to be honest, I've had a lot of opportunities fall into my lap since I'd made the switch. Um, so that's how that's

the the path I took. And as I said, I spent a lot of time looking over, you know, looking back and and what made it possible because I I'm I have no problem saying I was a good paramedic. Actually, no, I was a great paramedic. And I have no problem saying that because I know how good I was. I know how good there was a partner that

I worked with for 5 years and him and I I would have put us against any other paramedic in the state, maybe even the country. Yes, I know that sounds a little arrogant, but I'm telling you, I was that good. And I think one of the reasons why it held me back so long because I was I became a paramedic because I thought it'd be a good

job to have to go back to school. I could work nights, gave my days free, and then I just fell in love with the job. It became, you know, such a part of who I was that I kept putting it off. And I think part of it was because I was afraid I would never be as good at something else as I am at being a And

I got to tell you, I think I'm a better developer than I was a paramedic. I'm I don't think I'm better than most people in the country like I did with a paramedic. I'm not that arrogant, but I think I am actually a better developer And some of the things that carry over, some of the the mindsets that you can carry over from one thing to another.

The first one I want to talk about is there's a saying in medicine that when you hear hoof beatats, don't look for zebras. Anybody have an idea what that means? What the what the overall message on that is anything you want to share >> exactly. So it's basically saying when there's a problem it's more likely the common reason than the exotic reason. Okay. So if you're taking

care of a patient and they're, you know, they're exhibiting signs and symptoms of something that's common, it's more likely that that's the problem than some exotic disease or, you know, something that isn't as common. And the same thing, you have to have that same mentality in software development. Now, a lot of times when I give this when I when I when I talk about this with people,

we're talking about finding bug, you know, finding the source of bugs, but that's it's not always the case, but that's a good example where if you're working on something and there's a bug in your software, it's more likely a common reason for the bug. You know, it's more likely a problem in your code than a problem in the network stack. It's not to say problems in the

network stack don't exist and problems in network stack don't pop up but you don't jump right to problems in the network stack. You have to build towards that. Okay. So common things are common for a reason. Don't discount that. All right. And that is something that you know it's one of those things where in in paramedic class we they teach you a lot of stuff and they

were patients. There were things that we were taught in paramedic class that in 15 years I never saw because they're rare, but you have to be prepared for them. But just because they teach you that this could happen doesn't mean it ever will. So that should be something in the back of your mind, but until you get to the point where you've ruled out everything else, it

shouldn't be in the front of your mind. Another thing that's common is when you're trying to solve problems. And again, on the on the software development side, I'm not necessarily talking about finding bugs or issues or, you know, finding a reason why production's down. It's trying to solve a problem. Sometimes you need to think outside the box. Sometimes you need to think outside of the warehouse that

ship the box. That's both in medicine and in software unfortunately in both places, the only way to know when it's time to think outside the box, the only way you learn when to think outside the box is experience. And the only way you gain experience is by making mistakes. Okay? Very rarely will you learn from your successes. If you start something and you never do something wrong

and then you finish it, odds are you didn't learn anything. But if you start something and you make a mistake, you learn how to avoid that mistake, you learn how to do it the right way. Then you make another mistake, learn how to do it the right way, and that's how you learn. Unfortunately, in medicine and EMS, those mistakes can sometimes be tragic. Fortunately, I've never had

a I've never had an incident in my 15 years where I made a mistake that caused harm to the patient. Okay. But the the thing is the followup to when you hear hoof beats, don't look for zebras. Is there may come a time where a zebra escapes and that's when you need to find a zebra. Okay? And the only way to know that is experience. That's not

something like a junior developer is not going to have a finely tuned antenna for when it's time to start thinking outside the box. So there's going to and and here's the thing most of the time it's not when you're you go through it's common that wasn't it common that wasn't it. It's not when you when you've knocked off all the items all the common items that it

could be that you start having to think outside the box. It's like you learn to get to a point where you're like all right this doesn't seem like it's actually fitting into anything else. maybe we should start thinking of other So, the thought there is you hear the hoof beatats and you start looking around and you're not quite in a full circle and you go, you know

what, maybe I'm looking for a zebra. Doesn't mean you jump right to looking for a zebra, but you need to start considering the fact that maybe the hoof beats were caused by a zebra. So, let me back up here again. Um, whoops. Some of the reasons why this matters is it helps you eliminate tunnel vision. When you start to learn to think outside the box about solving

a problem, you you know you most of the time we try to solve a problem, we're looking like this. We get to a point where we have to start doing this to try and make sure that we solve the problem. And knowing when to do that takes time, takes experience. So if you start working in a new job and you you know you know you're working with

somebody who comes up with this you know I think the problem is blah blah blah blah blah and you're like there's no way that's the problem and that's the problem. It's not that they're some magical genius it's because they have experience and when that happens and somebody else comes up with the answer and it's a file that away for the next time because you might have to

wind up using you might have to wind up tapping into that methodical assessments is something that I I I'm going to be honest and I don't mean to I don't mean to put it make a joke in this, but I had when I worked as a paramedic, I had a little bit of OCD in how I performed my job. And it wasn't like I had to do

it this way or else I didn't feel right like some people when when when they get into the repetitive behaviors with OCD. But for me, it was to make sure I I did the same thing for the same patients every time. And that's how you make sure you don't miss things. But the thing is, my assessment on a patient a lot of time, my sure, my methodical

assessment on a patient a lot of time would be dictated by what they're complaining about. So if somebody is having chest pain, my assessment is going to start with trying to figure out what happened with the chest pain. Was what caused it? Could it be cardiac related? Could it be some type of injury? Um, if you have somebody who's complaining of respiratory problems, you're going to start

your assessment focusing on that. If I have a trauma patient, I need to do an entire head-to- toe assessment that is probably not going to be as thorough as I would for a medical emergency because very few medical emergencies is the doctor going to care whether or not the person has any type of deformities in their leg. In a trauma patient, that's a pretty big deal. that

could that could be the the root of of a pretty big um problem. And by doing the assessments the same way when when I do when I would do a trauma assessment it literally was head to toe. I would start doing my exam at their head, their face, their neck, their shoulders, their chest, their abdomen, their hips, their legs. Every time every trauma patient, the assessment was

done in the same exact way. And what that does is it made sure stuff didn't get It made sure that when there was a lot of pressure on the line where the patient was in critical condition where a lot of people might start panicking a little bit, I had my method in place. I knew that I had the tool set. I knew that I had the ability

to figure out what needed to be done. And when you're working in software, it's the same thing. And again, people tend to focus on bugs when we're talking there's a bug or production's down. And it's not always the case. It doesn't necessarily have to be an emergency. It should be you there's a problem some whether it's production is down or there's a bug or a customer wants

to implement a feature. You still need to go through the same process of trying to figure out trying to identify what the problem is and then trying to identify how to rectify that problem. Um, so on the on the software side part of this would be like if there's an error or there's a u you know the system goes down, one of the first things I'm going

to do is I'm going to look at the logs. Again, depending on what the problem is, if like if production goes down, that's the first place I'm going. I'm going to check out to check the logs to see um what's happening. You know, you need to gather metrics. You need to be able to reproduce the problem. It's one of the biggest issues with solving bugs in software

is if you can't reproduce the problem, then you don't know if your solution is going to work. And I shouldn't I should say if consistently. Okay, I've worked on many many issues as a software developer where it took me more time to reproduce the bug consistently than it did to actually fix it. I was on a project once for a big government agency. We had a bug

that took me 5 days to track down. And the reason why it took me so long is because the bug only showed up when a scheduled report ran on Tuesday mornings after a specific event happened on Monday. So it wasn't every Tuesday. It was only on Tuesday morning after specific events happened on a Monday. And it took me 5 days to figure that out. And when I

finally figured it out, I was able to replicate that bug every time. I was able to run that scheduled task every time and and and generate the bug. You know how long it took me to fix the bug? 5 days to find it. Took me two minutes to fix it. Okay? And and that and part of that was because of my methodical assessment. I wasn't trying to

push through and go, "Oh, this is the reason why. This is the reason why. This is why." I spent the time to make sure that I understood why the bug was happening before I even tried to implement the fix. And that's very, very important. A lot of times people are like, "Oh, it's this, but but without even looking into it." They're like, "It's got to be this."

And they try to start fixing things. And that's like trying to treat a patient without doing an assessment. You can't do it. It's not possible. Well, you can do it. It's just it's a crapshoot at that point. Excuse me. And the next thing is I realized that my ability to do a differential diagnosis on a patient really helps when troubleshooting software issues. Now, for those of you

who don't know, a differential diagnosis is you don't determine what is wrong with the person, you determine what isn't wrong with the person. So, if we walked onto a scene of a call for like an unknown medical emergency and the person is unconscious, we have no way of knowing why they're unconscious. So we start doing our assessment. We start taking vital signs. We start, you know, investigating

what's going on. Ask questions if the family's there to find out why the patient is unconscious. And with each piece of information you gain, you can get a clearer picture. So we might start with 15 reasons why the person's unconscious. And then after 5 minutes of doing an assessment and talking to the family, now we have three. We were able to eliminate a bunch of them because

they don't fit into the timeline. So with a differential diagnosis, as you get more information, you start checking things off the list of what it can't. So you know, yep, can't be this, can't be this, can't be this. You know, first is unconscious. My first two things are it's either a drug overdose or they're diabetic. Those were the two things that I would be like in my

head. Um, but there's a variety of other reasons. And if you find out, are they diabetic? No. Okay. So it's pro they're probably not unconscious because their blood sugar is low. So we can we could check that off and that's part of the differential diagnosis. And the same thing happens when you're when you're focusing on issues with software development. Okay? If somebody says production's down, that's all

you got. Production's down. You're going to start thinking of what could be causing these reasons or there's a bug when when when I hit this report there, you know, there's a bug and the data never gets saved. You actually start thinking of potential reasons. And as you start investigating what is actually happening, you can start kicking some of those things off the list, you know. Um, it

it's it's not a it's not a database issue because the data is up and running and we can hit the database from other sources. Not a database issue, you know. It's not a it can't be a network connectivity issue because I can hit the website. It's just having problems, you know, doing something with the data. So, you can say, okay, network connectivity issues, not the issue. And

you gradually as you gain more information, you gradually start throwing stuff out until eventually you're only going to have, if you're lucky, one possible cho um cause or two or three. And it's a lot easier to find out what the cause is when you're hunting down two or three possibilities as opposed to 15 to 20. And this also um prevents television. It causes you instead of focusing

on one thing that you think it is, you start making sure that the other things aren't This is probably the biggest one. Okay, being able to stay calm under pressure. And this is exactly what I'm talking about here on the software side is production is down. whatever the whatever the system is that you're working on, whether it's the production database, the production website, whatever, it's down. It's

not working. Nobody can access it. Okay. Um, this slide is actually pretty accurate on the EMS side because I have done CPR on the father of the bride on the dance floor at the reception twice. Do you think there's anything in the software world that's going to put more pressure on me than that? No, there's not. So, when there's issues like that, I'm like, "Bring it on.

I got this." And one of the reasons why being calm in situations like that, and probably the biggest reason why being calm in situations like that is important, is because calm is contagious. One of the times when we walked into the wedding, everybody was all frantic and they were carrying on and they were crying and screaming and yelling. And me and my partner walked in and we

walked in like we're here. We weren't running. We weren't screaming. We weren't frazzled. We walked in calm, cool, and confident because we knew what we had to do. And that calm started to spread. the family started to feel a little bit better. There wasn't, you know, that that high energy in the room. We were able to bring the energy down. Same thing happens if you're working on

an issue and production is down and you got your manager and the customer and everybody screaming at you and carry on and you're calm. That spreads. Now, I will tell you it's not easy, especially if you don't have the experience to back up the confidence that you need to you need to project. But you need to work on that. Okay? Because again, calm is contagious in any

situation. I don't care if you're dealing with EMS, software development, social social interactions, whatever. Calm is if you are calm, people around you are going to start getting calm. And then in software development, if you got production down and you're not freaking out, the customer is going to bring the temperature down. Well, all right. They must they know what they're doing. this guy's not freaking out, so

maybe it's not as bad as I thought. Which, in honesty, it's probably worse than they think, but you're making them think it's easier. It's it's it's better than they think. So, try not to get amped up. I've worked with software developers that, you know, it's like a it's like a five alarm fire when when there's a slight glitch in production and, you know, we have to have

IT'S ALL HANDS, EVERYBODY ON DECK AND BLAH BLAH BLAH THIS other thing, you know, and it's like, dude, just chill, you know? There's no reason to to do that. It's I understand it's important that we need to get production back up, but you know, constantly saying, "How we doing? How we doing? How are we doing? How you know, getting in my that's not that doesn't help." And

it's the same thing when you're doing CPR and the father bride at the wedding. You don't want the bride constantly going, "How's he doing? How's he doing? How's he doing?" You know, because it distracts you from getting your job done. And again, calm is I've seen it happen more times than I can remember in EMS and in software development. I have a funny joke. Um, I worked

on a government project for the Social Security Administration and the project wasn't going well and there was a big meeting between the people on the project side at SSA, the development team, as well as like the management and president of the company that I work for at the time. And we get into this conference room and there's a there's a conference table in the middle where where

I saw some of the other developers sitting and then there were chairs stacked up three rows deep on each side of the conference room and there were people in every one of those chairs and I was like this is not going to go well and you could just tell there was there was tension in the air right there was I mean it was palpable and one of

the developers we worked with he actually worked at SSA his name was Fonnie and he was supposed to be sitting at the conference table with the rest of the development team, but Fonnie wasn't there. So, somebody goes, "Hey, where's Fonnie?" And you turn and look and there he was in the very back corner of the third row of chairs and he's like, "I'm over here." And I'm

like, "Fonnie, get over here. Nobody puts Fonnie in a corner." For those that miss it, that's a call back to um Dirty Dancing, an old movie from the 80s where they say, "Nobody puts baby in a corner." The room erupted in laughter. Everybody who went into that room either getting ready to defend what we were doing or to accuse us of not doing enough just evaporated. The

tension just went away. And the president of the company came up to me afterwards and says, "You know, after you made that comment, you could have left because at that point your job was So this is this is probably the skill that I had honed that has saved my companies more money than anything else. And that's hearing the signal through the noise. When I would go on

EMS calls at a wedding, for example, there's a lot of chaos. There's a lot of people who are trying to tell you things. Sometimes when you're doing assessment where it's just the patient and his wife, what the patient tells you is the complete opposite of what the wife tells you. Okay? There's a lot of noise. Sometimes you get a patient who we would say would be they

were a horrible historian, which means you go, you know, what's going on today? Well, you know, back in 1972, I had a polip removed and then in 1980 I had to have a hip replaced, you know, and here the person is having chest pain, likely having a heart attack. Do you think that that that their polyps they had removed in 1972 matters? No. So, you need to

filter that out. You need to be able to filter out what they're telling you and be able to pull out the specific pieces of information that are going to be pertinent to helping take care of the patient. On the software side, I spent a lot of my time as a consultant. And over my years as a consultant, my philosophy became my job is to give the customer

or to give the client what they need. Unfortunately, it's almost never what they ask for. So, when I'm in meetings and we're doing requirements meetings or, you know, all of a sudden there's a new feature they need to add urgently, if stuff doesn't start to make sense or didn't start to make sense, um, I had a question that I would ask that my teammates and project managers

and product managers and um, clients learn to dread. And that question often that question was what problem is this meant because I realized over the years a lot of times a customer would tell you to implement what they think is the best solution to the problem they have rather than telling you what the problem is and letting you come up with the solution. And I can tell

you from 20 plus years of experience the customer solution is never the best one. So you need to find out what the problem is. And the way you do that is by Okay? If things start don't making sense, like like if if if you're listening to a client tell you what feature that you want to implement and something doesn't make sense, then I I would almost guarantee

you that what they're doing is they're trying to tell you what what they think is a solution to the problem. And then the question you you can ask then is what problem is this meant to solve? So hearing being able to hear the signal through the noise and trust me when you're in customer meetings there's a lot of noise. There's a lot of you know you'll hear

rah rahrrah stuff from the project manager and you know and there'll be the corporate line and we have to do you know we top quality software and blah blah and then the customer is like you know we need to make sure and they'll start throwing all these big corporate words you know and trying to get you this is what we need to do and then you like

my thing was why why are we doing why are we implementing this feature and most of the time that I asked that question the client came to the realization that what they were asking for was stupid without me actually having to tell them what you're asking for is stupid, which is I think it's pretty cool. Um, and then we have a conversation about what the problem actually

was. And then we would actually craft a proper solution because when you're working on a project, the customer is going, not always, but more often than not, the customer is going to understand the business processes more than anybody else, but the developers are going to understand the database and the code more than anybody else. So when the customer tries to tell the developers what you know how

what code to write that's a problem. What the customer needs to tell us these are our business rules. Write the code to meet them. And they don't understand that. Cuz here's the problem. If you sit with a meeting and the customer says we want this and you go we can do that. And then you spend months building that and you come back and you lay down you

go here it is. This is what you asked for. and they go, "That's not what we asked for. That doesn't that doesn't help us. But that's what you said you wanted." Yeah, but you know, it's not. It's It doesn't help us. It's because you didn't give them what they needed. You gave them what they asked for. And you know who's on the hook for that? You. Because

the customer isn't happy. If the customer is unsatisfied with the job that you did, no matter what the customer was responsible for, you get blamed for it. So hear the signal through the noise. Find out exactly what it is that you need to do and make sure that your solution meets that need. Anybody know what the word is in medicine for prioritizing patient care? >> Triage. Exactly.

Some of the most difficult professional decisions I have ever had to make took place on mass casualty incidents in EMS. And a lot of people seem to think that triage means you take care of the sickest people first. And that's a good layman's example, but really in triage, you take you you determine which of those critical patients will be most likely to benefit from the resources you

have at hand. I think it's safe to assume that a lot of people would say, well, if somebody is having if somebody their heart stopped and they need CPR, that's pretty in a mass casualty incident when there's other people who are hurt, do you think it's worth um spending resources on somebody who is not likely to survive? No. If you have somebody who, you know, is, not

to put it in, you know, a dark humor way, but, you know, we say like one foot on a banana, one foot in the grave and one foot on a banana peel. Okay. Again, they're alive, they're hurt really bad, but they're not likely to survive their injuries. Is it worth dedicating resource to that person when you have 50 other people that you need to tend to, that

you need to make sure get care? And those are decisions that to this day, some of them still haunt Did we make the right decision? And the thing is, you really can't do that in EMS because it will it'll destroy you. You know, it will eat you up inside. And thankfully, the type of triage you do in software development doesn't nearly have as detrimental consequences, but that

doesn't mean it's not important. So when you're triaging stuff, if you have, you know, something's there's a lot of things going wrong and you have 15 things that you need to take care of, you need to learn how to prioritize those. got a ferry coming in. Um, you need to be able to prioritize. You need to be able to figure out which is the important stuff that

needs to get taken care of first and which is the stuff that can wait till later. Now, it's a little bit different in software development in the fact that to show the the customer that things are moving in the right direction, you need to grab some of the lowhanging fruit. Okay? If I finish just knocking out a bug that was pretty serious and I only got like

an hour or two left in the day and there's another serious bug and I know I'm not going to finish that bug before the end of the day, I'll grab some of the easier tickets where I know in the next two hours I can knock two or three of those out because then I can say yesterday I fixed four bugs rather than yesterday I fixed one. Okay.

But still, I'm not going to you I'm not going to do those those lowhanging fruit. I'm not going to do those easy tickets at the beginning of the day. I would usually do those at the end of the day so that again you can show that you're doing stuff. But it's important to be able to figure out which is the important stuff and which it isn't. Because

a lot of times the customer might think that this particular issue is the most important, but you know deep in your heart it's not. This other issue is even more important. And you need to be able to identify that and you need to be able to express that to the customer because that's our job. The customer doesn't dictate the priority of issues. We do. And here's another

thing that's funny is um I guarantee any of you that goes into um is going to have a customer where everything is important. Everything is critical. And here's a little bit of information for you. If everything is critical, nothing is Okay? And you have to push back to them and be like, especially like for feature requests, we need this important feature. Okay. Is it more important than

this one? No, no, they're the same. Okay. So, which one do we do first? Do them both at the same time. Can't do that. You got to pick which one I work on first. But we need them both. I get that. But which you need to tell, you know, sometimes you need the customer to be like, which is more important to you in terms of features and

stuff like that. Bugs, it's going to be whatever is causing the most damage. Those are the ones that you want to take care of first. Unless, again, I said, like I said, you know, you at a time where like you're like, I know I'm not gonna be able to get through this today. Let me see if I can knock a few other things out to knock stuff

off the list. Shows you're making progress. It shows that um you know, you're you're on the thing because again, clients are going to look at the bug list and be like, "Why did you only clear one bug yesterday? You were working for eight hours." Well, I did. I finished one like, you know, most of the way through the day and then I started on another one. They

don't care. All they care about what's finished. They don't care what you worked on. You need to be able to embrace ambiguity. Embrace ami ambiguity. Embrace for So the calls that I dreaded most when I was a paramedic were the ones when you go walk in, you go, "Hey, what's going on today?" I just don't feel right. Well, what what what do you mean you don't feel

right? Explain to me what's what exactly that I just I don't Yesterday I felt good. Today I don't. Well, are you having trouble breathing? No, not really. you have any chest pain? No, not really. And you go through this whole cycle of, you know, and you don't know that it is so ambiguous like you know, you need to you need to help me here. You need and

and then you need to start really proddding. You need to really start focusing your questions on, you know, well, when did you stop? When did you start feeding? Did you wake up this way? Did something happen? You know, and and you start trying to gain more information that way. And the example I have on the on the the the software side is and you really can't get

more ambiguous than I want a I've actually had people call me up. I want a website. Okay. What's the website do? I don't know. You figure that out. You know, it's for my business. What business do you have? I'm a photographer. Okay. So, do you want like a portfolio? No, I just want a website. So you need to be able to understand the fact that sometimes the

requirements are going to be these amorphous um ambiguity ambiguous statements like I want a website and again you need to start honing your assessment to to get more information and when you have to start pulling information from customers about you know cuz that tells me they don't know what they want. They don't know exactly what they want. They know they want a website. They don't know what

they want the website to do. Should they have called us before that at that point? No, probably not. They probably should have thought more about what they want the website to do and then said, "Hey, I want a website that does blah blah blah blah blah," not just I want a website. And then ultimately when you have these the these ambiguous situations, things are going to change

and things are probably going to change very very rapidly because in my experience the patient who's like I just don't feel right. Can you tell me exact I can't tell you. It just there's just a feeling and it's not right. Those are the people that die in the Not the people who have crushing chest pain or have really bad, you know, they have a really bad trouble

breathing or, you know, they had like Now, I'm not saying those people might die in the back of the ambulance, but the ones that scared me were the ones where you that you really didn't know what was going on and the patient couldn't explain to you what was going on. Those are those are the patients that that are usually going to crash very quickly. And because you

don't have enough information from a focused assessment because they couldn't help you. Then you start that's when you have actually have to start doing things without kind of thinking. And the same thing happens with I want a website. Well then when they start thinking about it they're like no but now I want this and I want this and I want this and I want this. So all

the require when they start thinking about it the requirements are going to change. Something else I've learned I've learned in my career as a software developer is will ask for what they think the developer can deliver rather than what they want. And I've had this usually this is they've already been through a round or two of other companies trying to develop their website and those developers either

weren't good or weren't able to communicate effectively to find out what the customer actually wanted. So the customer thinks, well, what I want is too hard. So maybe I need to change what to get to be able to to get what I want. Which if you think about it doesn't make a lot of sense, but I've had customers before and I'm like, you know, we can do

this. Well, I I I the other team I had said they couldn't. I said, well, maybe the other team couldn't, but I can. You know, and you need to that and that's where you need to be open to change. You know, sometimes, God's honest truth, I had been in the middle of working on on requirements that were like, you know, I'm talking like one particular requirement taking

two weeks to finish and I'm like 3 days out and everything about that requirement changed and now I got to go back to the beginning and start over. You need to be able to understand that that's going to happen. It's going to be frustrating, but try not to show that frustration to the customer. Just like I'd have to not show my frustration to the patients when they

were being ambiguous and I just This is one that anybody who knows me would laugh at. Um because I used to joke in EMS that I would be like this job is great for the patients. And then when I became a software developer, I was like, "This job is great except for the users." But one of the things that I I I learned and and was able

to hone when I was working as a paramedic was I became much more empathetic than I was. Now granted, some of that might have come with maturity. Um but I learned not to judge people by the situation that they're in. I learned to show caring for people who might think they have a serious illness or injury when in fact they don't. Um, I learned the very difficult

reason or the very difficult lesson of having to tell a spouse or child or parent that the patient has died. You really you you can't be in medicine and not have empathy. You can't be good know, you hear all these doctors that, you know, they have like the they're they're a great doctor, they got bad bedside manner, then they're not a great doctor because the bedside manner

is part of it. Okay? And it's the same thing on the software side. Whether you're dealing with a customer who doesn't understand exactly what it is that they want or doesn't understand exactly what the capabilities of what they can have or it's a user who doesn't understand why it's not working on their system, you have to be empathetic. You have to understand that it might be easy

for us. You know, I can I can click through and and and fix things or install software easy because that's my job. It's what I do. Some of the people we're going to deal with, that's not their job. It's not what they do. You know, it might be somebody who is, you know, they're older and they're retired and they decided that they want to start learning more

about how to use a computer. Don't be mean to them. Embrace them. you know, show them that we're not elitist snobs because sometimes people in software, we can get that way. And in in it in general, we can get that way. If people don't know what we know, we think less of them. Don't do that because there was a time where you didn't know what you know.

And you probably got to where you were because people who knew more than you didn't treat you like they knew more than you. And it's the same thing. It's it's you know the one thing I I I like I I tell people is behind every bug report is a human trying to succeed. to flip this on its head, there's a an animosity usually between developers and QA.

Okay, developers hate QA because QA makes developers do their job appropriately. All right, and I tell people that all the time. I'm like, you know what? Q, you don't like QA, that's fine, but they're doing their job and they're making sure you do your job and you don't like them because they're holding you accountable. be aware of the fact that sometimes people are just trying to do

their job, even if that impacts you doing yours. And then probably the biggest commonality, the biggest thing between the two careers is a thirst for knowledge. Would anybody want to go to a doctor who says, you know what, I know everything I need to know. I don't need to learn No. Would you want to hire a software developer who says, I don't need to know anything else.

I know Java better than anybody. I don't care any I don't need to know anything else. No. And I can tell you, I've worked with people in EMS and I've worked with people in software development who have said to me,"Well, we always done it this way." I didn't like working with any of those people. Okay? You always need to keep learning in EMS, in medicine, in it.

You can't stop learning. The second you stop learning, you become obsolete and the job passes you by. It's, you know what, some people don't realize that. They don't think about it going into it, but it's it's the truth. If you work in IT in any in any area of IT and you're just like, I'm not going to learn anything new. I don't care what comes down the

pike. I'm not learning I don't want to hire you. Hey, it's great that you have all this that you have all this old institutional knowledge, but if you're not willing to add to that bucket, get out. You're not worth it. You know, and it's the same thing with EMS and with medicine. I don't want to work with I didn't want to work with a paramedic who didn't

want to know about some of the new techniques, the new procedures, the new protocols, new medications because we always done it this way. You know, they that's not the attitude you want in software development or in a medical provider. So now, as I said, all of these things I realized retroactively. I realized a lot of these things, a lot of these commonalities from taking my time as

a software developer and looking which is kind of easy. It was kind of easy for me to do at that point because I didn't need to worry about it. But how can you do that now? If you came from a different area, if you came from a different career and you're trying to get into it, you know, whether it's software development, network um administration, whatever, cyber security,

how can you do that? Well, the first thing you need to do is you need to look for patterns rather than the tasks. Okay? I can tell you with almost 100% certainty as a developer, I'm never going to need to start an IV on someone. So, the fact that I was very good at starting IVs is pretty much irrelevant. But some of the other things that I

that I learned that I honed, being empathetic, being able to, you know, listen to the signal through the noise, being able to stay calm under pressure, those things translate directly to things that happen in software development all the time. So, don't focus on the individual tasks. Focus more. You need to pull yourself back and and and and look more at the the general um types of patterns.

You need to identify thinking styles, whether it's an analytic thinking style. Do you break problems into little parts? Uh is it systems thinking? Do you understand how the different pieces actually work together? Uh creative thinking, do you find the unconventional solutions? This is the people who tend to think outside the box. Okay, again, not you don't need to jump right outside the box. Sometimes you got to

middle in the box a little bit and then realize, hey, I need to go somewhere else. Um, identify what we Whoops. Sorry. Identify what I like to call the the um the meta skills. So, this is more like the high the high angle thing. I'm a good listener. I can I can I can ex absorb information, filter everything out, and be able to pass on the details.

that those those types of skills. And then you translate those things from, you know, from to two, like from being able to manage the chaos at a mass casualty incident to being able to help the team uh recover from a production outage. They see these seem like drastically different things and they are drastically different things, but the skills you need at the high level to manage both

of those are the same. I was talking to somebody once at a conference and a young man came up to me and he said, "I'm I'm really nervous I'm the first person in my family in generations to not go into the family business." He says, "I'm getting ready to finish an IT boot camp. I have a job lined up. I start next Monday." He said, "And I'm

really scared because I don't know if I'm going to be able to do it." I said, ' Do you mind if I ask what the family business is?' And he says, 'I'm a mechanic.' My father was a mechanic. My uncles are mechanics. My brothers are mechanics. I said, 'Okay. So, what do what do you worry about? He's like, I don't know if I got the skills to

do it. I said, I could tell you right now as a mechanic, you're going to be amazing at debugging software. And he's like, well, how do you know? I said, well, if somebody comes into you and says, "My car is making a weird noise. You probably have a system in place where you start going through and try to analyze what's wrong and try to narrow down what

it actually is and then ultimately come up with way to solve the problem. And he was like, "Oh my god, I never thought of it like like that." And I'm like, "Well, you're 18. Why would you?" I mean, I literally I said that to him. I'm like, you know, it's I said that that's what comes from experience. I was talking to somebody else and they were they

said that um they were thinking about changing careers and they wanted to go into um something in in the uh software development realm and they were an executive assistant and they were an executive assistant for somebody very high up in a decently sized company. and and she was like she's like I just I don't know if I'll be able to handle it and I said well I

could tell you right now I guarantee you'd be a good project She's like what makes you think that? I said how many balls do you keep in the air for your boss on a regular basis? And she's like quite a bit. I go project manager do the same thing. They were able to I said and you probably are able to direct your boss to the things that

need his attention at that moment. She's like yeah I go same thing with your So just because you you have a background that is not consistent with it, I have to be honest, some of the best developers I've ever worked with didn't have IT degrees, didn't have computer science degrees. Probably the best developer I ever worked with had an advertising degree. So got few minutes left. I

can answer some questions or I can give away the dolphin. Whichever order you guys want. Unfortunately, there's quite a few people in here um who weren't here for the beginning. So, when I ask the question, you're going to be like, "What the hell is he talking about?" And that's your loss because you were late. Anybody have any questions before we >> What was the most zebra thing

you experienced as a paramedic? >> Ah, the most zebra thing I experienced as a paramedic. This is actually a good one. So, um there is a and I can't remember the name There is a type of poisoning that is common amongst people who work in um landscaping, you know, lawn management and stuff like that where if they're exposed to a particular chemical over a long period of

time, they start to exhibit signs of um people who have congestive heart failure. So, it's people who having trouble breathing, they get really sweaty. Um and it's usually those people in that condition, they don't have heart And we had a guy, it was January, and this is what made it really, this is what made it really like the zebra thing really like out of nowhere was the

guy was exhibiting all these signs that, you know, initially it was like, oh, he's in congestive heart failure, but there were things that didn't add up. He was younger, not young, you know, but he probably younger than I am right now. um his blood pressure wasn't elevated, which is usually that's like a a pretty a pretty big giveaway, but we like we couldn't figure out, but he

was really sweaty and and I'm like, "What do you do?" And he's like, "Oh, I'm a greenskeeper at a golf course." And right away I'm going, "It's January." There goes that idea. And I'm like, "Are you working now?" And he goes, "Oh yeah, we just got done refering the fairways." Bingo. That was the zebra. It was the poisoning. Right away, we knew it was wrong. We gave

him atropene and by the time he got to the hospital, he was fine. Now, I'll be honest, if it wasn't for the fact that I was a golfer, I might not have picked up on that. But it was one of those things where I was like, you know, that was kind of like out of left field. That's organo phosphate poisoning. I knew I was going to remember

it. Organo phosphate poisoning. And a lot of organo phosphates are in fertilizer. And that's what wound up happening. He was exposed for a long time over the week to organo phosphates and it's and it actually built up and became toxic to him. And you know my partner at the time who he was actually it wasn't my long-term partner was somebody who was relatively new and he was

like how did you pull that out of your ass? And I'm like it what he what he was presenting with didn't fit. Started had to thinking outside the box. >> Anybody else? >> Yes sir. Yes, it's called golf. No, that that's actually a very good question. For those who didn't hear it, is is there a system to be able to avoid empathy burnout? And just like any

other kind of burnout, in order to kind of prevent it or nip it in the bud or or do the reset, you kind of have to like step away. whether it's taking time off um working on other tasks that you know won't require you to actually have to deal with people um that's probably the best way just like again it's just like any other kind of burnout

you know if you start if you know there's if there's times where like I'm having a bad day or I was having a bad day you know I tell my wife I said can I go play golf out and play nine holes and actually I live on a golf course and a lot of times in the afternoon in the summer I can go out at 4:00 and

finish 18 holes by 6:30 if I'm by myself cuz the course is usually empty, you know, and this, you know, and it I'm not saying not saying everybody has to pick up golf to get over the stress. That's not what I'm saying. I'm saying that's how I manage it, which is funny because golf is stressful in and of itself. But you need to you need it's going

to be unique to everybody, you know, just like how do you deal with burnout? It's going to the best way for everybody. It's going to be different. The way I deal with burnout is going to be different than the way that you deal with burnout and the way that they deal with burnout. Okay? And you just have to find ways to step back. And here's the key

before it gets too bad. It's interesting that I step when I came into the previous talk, he was talking about burnout. And that's something that in EMS is a very bad problem. And the problem in EMS, and it's the same thing in software like with particular things you're talking about is burnout gets to a point where you can't come back. If you don't deal with the burnout

in a timely manner, you're never going to get out of it and you're always going to stay burnt out. So, if you feel yourself starting to get really stressed or having to deal with the same thing over and over and over again, and you're starting to lose patience, you need to step back, take a day off, take a weekend trip, you know, go for a walk. You

know, I I work from home, so if I'm having a stressful day, I can go for a walk around my neighborhood for an hour. And it just helps you clear your head. It helps get you away. It helps you reset. It doesn't have to be something big. It can be something small. It can be something as small as I'm just going to go take a five minute

break. Going to go sit out on my deck or I'm going to go, you know, walk around the building, you know, visit the lunchroom. Something just you take a little break every once in a while is probably the best thing that's going to help. Anybody else? Yes, sir. >> What would you say? Fantastic question. So the question was, I was able to identify all these skills retroactively.

If I didn't do that retroactively, how would I actually promote those skills I had as a paramedic when I'm sitting in a job interview for a software developer? I that's not exactly what you asked, but I think I think that was I think that was the point. And the thing there is that's where you that's where the from two statements come from. Okay? You know, you can

work into the interview. You know, I I deal I dealt with mass casualty incidents where we had upwards of 50 patients. So, I can handle chaos. I'm I'm able to make sense out of chaos. I can stay calm under those under those conditions. You know, I know how to be able to maintain my level of professionalism in certain situations because I've had to do that for x

number of years in this particular career. you know, the I I know how to debug systems. That's he could say that he knows how to debug systems. Doesn't matter what system. Debugging is pretty much the same. You know, it's a methodical way of trying to figure out what's wrong and then a the best solution. So, you kind of got to corporate speak it. See, you guys, anybody

who's going through that now is probably a little bit better off than I was because we have AI to help us. You can put in you can ask AI, hey, you know what? I I work in this career and these are the skills that I have in this career. How would they translate? And then you could take what it tells you and you can use that in

interviews. You know, you can you use that experience. I never thought to do it because at the time I thought they were so different it didn't matter. But looking back, I'm like, I was an idiot. I probably could have gotten much better jobs and much more money early on in my career had I used that to my advantage. And I never did. Okay. So, the beginning of

my talk, I told you that I was going to give away this dolphin to the first person who can answer a question that is based on something I said or something you saw. Remember, raise your hands. Don't yell The question I have is, "How big is my dog?" >> 112 pounds. And anybody if anybody has any questions, um I'm not going to be outside right away. I

got to run back over and close up our booth and I'll be back for a little bit. Um so if you want I'll be out in the middle. So keep an eye on it. Keep an eye out for me. But thank you everybody for attending the session. I hope you guys got it. I hope you guys got something out of it. Thank you very much, Scott Stro.

Next up, we have Gina Verstro speaking on Check Your Own Boxes: How I used my blog to land my first job in tech. Gina is a technical writer based in San Diego who landed her first job in tech through her blog. In this talk, she shares how documenting what you learn can become more than just writing. It becomes a portfolio, proof of continuous learning, and a way

to demonstrate that you can communicate technical concepts. Please join me in welcoming Gina Verastro. Hello gentle friends. I'm Gina and I'm a DevOps engineer for Soshi. And I just want to open with why me, why this talk, and what I hope that you get out of it because otherwise you aren't going to care about anything else I say. Um, first off, I'm a career transitioner. I went

through a web development boot camp when I was 29. And I started my first job in tech at the age of 30. And I know that may still sound young to some of you, but a lot of my colleagues when I first entered the field were a lot younger than I am. And so I know that feeling like you're starting from behind and you're scrambling to catch

up and um they're all just like everyone around you is miles and miles ahead of you. I found that first job search for my first technical role to be very frustrating and the conventional wisdom around that that was supposed to help me just made it more frustrating. Maybe you've heard a few of these things before. And then after being ghosted by pretty much everyone I was interviewing

with, I started to question if I had anything to offer. The last speaker talked about those transferable skills and I felt like I started knowing what those were and then I was wondering if I even actually had any of those. And of course that's not really a fun place to be and I don't want anyone else to wind up in that place. I want to give you

the tools to check your own boxes, to know what your skills are, recognize your strengths, be able to demonstrate them, communicate the value that you bring, and never doubt how awesome you are. So, I'll share with you my story. I thought for most of my life that I wanted to be an English professor and then I discovered that academia was not for me. I was at a

conference kind of like this and there were a bunch of people in the room arguing two different interpretations of a piece of literature. Voices were raised, fingers were pointed and I just went, "Oh man, I don't care. I don't care about this enough to yell at someone. I am in the wrong room. I must get out." But I still really liked writing and I wanted to keep

that part of my life. I wanted to keep sharing my writing. So I started a blog, just your run-of-the-mill WordPress with a template kind of situation. Then in 2016, there was sort of this perfect storm in my life where I was in a job that I had kind of burned out on. I was having a heck of a time getting out, though, and I just wasn't feeling

challenged anymore. I also lost two people in my life that were very close to me. And a normal person might go to therapy. I went to Code Academy. I decided that the one thing in my life I could control was my blog. And gosh darn it, I was going to control her down to the pixel. So, I started spending a lot of time with our three good

friends, HTML, CSS, and JavaScript in a quest to do just that. And along the way, I discovered, hey, I actually like doing this more than I like doing the writing. In 2017, I finally found a new job as a project manager at a very small web design and development company in San Diego called Shovel Creative. And there I met my first mentor, Steve Lutz. And Steve was

like chat GPT before Chat GPT existed. I could ask him absolutely any question I had. No matter how weird, how offthe-wall, can this be done? How does this work? What is the internet? And he had the answer like that while he was also coding a website. So he helped me out a lot. He gave me some of the best advice that I've ever gotten. We are still

friends to this day and I am just very grateful because he fueled that fire in me to keep learning and keep pursuing this this path. I also joined an organization called Girls in Tech because I was new to San Diego. I had new friends and I was going to absolutely every meetup out there just trying to find some people and these were the ones who had a

vacancy in their organization. So, I joined up and started to surround myself with just like-minded people doing that networking that everyone talks about. And up to this point, I hadn't really considered doing a web development boot camp because number one, tuition very expensive, and number two, there was no guaranteed job at the end, which to me was very scary. Then in 2018, my boss decided to close

down Shovel Creative to focus on being a parent, which is admirable. At the same time, I was out of a job and looking at that big scary awful job hunt again. And simultaneously, a woman that I knew through Girls in Tech said, "Hey, I know you have a blog. What if I give you a discount on tuition at Learn Academy and you blog about the boot camp

experience?" So I thought, well, even if I'm sitting there doing the job all day, I'm not guaranteed a job at the end. So I guess now is the time. So fear-based decision-m and I completed that web development boot camp. And along the way, I started to transition my blog from just something fun that I played around with to more of a professional portfolio. And finally, November of

2019, I got my first technical role as a tech support engineer at Soshi. Now, let's talk about you. You've heard enough about me. This is your time. How do you figure out what your strengths are, what those transferable skills are? These are a few tricks, tips, tools that you can use. most basic one probably is what classes did you excel in at school and what classes did

you like? I was really good at English. It came easy to me. So, check that box. But biology, biology was really hard for me. It's not one I would automatically go to, but I liked it. It was fun. I liked doing the research that led to a discovery. And now I know that that's good for debugging and documentation. Think about what kind of compliments you get from

your friends, your colleagues. I always heard you're so good at explaining things. Even if you're the type of person who goes, "Oh, no, no, no, not me. Oh, that's so kind, but I could never." Start to internalize those compliments and think about what people are saying and what they're saying, what you hear from different people. Also, think about what your hobbies are, what you like to do,

and what attributes make you successful at those hobbies. So, I love photography. It's something that I used to do with my dad. Doesn't necessarily translate directly to tech, but you have to have a lot of patience and commitment if you want to get a certain shot. If you want to wait for the lighting to be just right. If you want the angles to be perfect. If you

want to wait for that train to go by, but the train only comes once an hour. You learn patience. And again, that's good for debugging. It's good for infrastructure because you have to figure out how all of the different pieces go together. And my last tip on that is take BuzzFeed quizzes for real though because if you're ever taking one of those online personality tests and then

it you get to the end and it explains why your aura is like that particular slice of pie and you're like, "Oh my god, yeah, that's me. Wow, they really got me." What did they say that resonated that told you, "Oh my god, yeah, that's me." Cling to that thing. I'll give you one for free, too. the fact that you're willing and excited to learn new things.

Just the fact that you're in the room right now tells me that is true about you. And that has gotten me the farthest in my career. To be honest with you, everyone at my company knows I love to learn. I make no secret of it. If I don't know an answer, I'm honest. I say I don't know, but I'll learn and I'll come back to you. And

recently we had an infosc team forming and the director of that team said I need a ops person and our CTO was like Gina likes to learn new things tag her in. So just being someone who wants to learn new things even if you struggle sometimes if you feel like learning is hard that's okay. Just the fact that you want to is huge. Bonus points. Start to

think about how these strengths can make a company money, save a company money, or save a company time. And remember, time is money. So, if you can save them time, you can save them money. All right. Maybe you're thinking, "Does anyone even read blogs anymore, Grandma? How is this going to help me?" Fair. Totally fair. My thing was a blog, but yours can be anything that is

easy for someone to access that you can share pretty easily. For example, if you're into gaming, maybe you make a really simple browserbased game that has to do with learning technology. Maybe you're a mobile person, so you make a mobile app. Maybe you have a YouTube channel or Tik Tok or a podcast where you talk about what you're learning, what you're studying that's techreated. Or if you

like writing, but you want something that's a little more modern, maybe Substack could be your thing. Now, I'm going to talk about the concrete steps that I took when I was transforming my blog into something more professional that I could actually use. And again, just because this is exactly what I did, kind of think about how you would apply this to whatever thing is more up your

alley. In the beginning, I was writing whatever I felt like journal entry style. I wrote fiction. I had a more conversational tone. Oh, and I'm I'm stepping on my own toes here. I skipped the first and most important thing, accessibility first. Um, I don't know how washed out the screen is, but things like if you're doing text, high contrast, dark, dark, and light colors. Make your um,

if you have images, make your alt text actually descriptive. Don't just stick the image in there and say, "I'll write this later." and then forget. Actually put what's in there, especially if it's a screenshot and there's code, things like that. You want as many people as possible to be able to access your content. So, make sure that you're considering all of the different accessibility features for whichever

medium you choose. All right, back to the after. Um, I started of course writing more tech focused posts and talking about code concepts and my tone became a little bit more professional, a little less casual profanity, that sort of thing. Before my posts were inconsistent, they didn't really follow a format. It was just sort of whatever I felt like. Afterwards, I tried to structure my posts according

to a formula, having a goal, where I got stuck, and how I worked through it because that's what people want to see. They like to see your process and your thought process is it is a transferable skill like the last speaker spoke about if you have that systemic mindset and approach to things that can be very helpful especially for interviewers to and you're always going to be

stuck. I know failing out loud as scary. Failing in front of people, failing in front of the internet can be very scary, but it's good to show how you recovered because we're all going to get stuck, but you're also going to recover. And that's something I do in my job like 20 times a day at least. Before my blog was more textheavy. I had really flowery language

and I strove to be entertaining. When I made the shift, I wanted to use a mixture of text and images, lots of screenshots as I went through how to do things. I wanted to teach and granted the things I was teaching were very basic because my knowledge was very basic, but it was more about how I was communicating how I can convey knowledge to others. I also

placed an emphasis on personalization in the beginning. I wanted all of the photography to be mine. and I was hold over from kind of the first time that I redid my blog where I wanted it to be under my control down to the pixel. I let go of that and I started using stock photos because before if I didn't have a photo that went with a post,

I was going to wait. I wasn't going to post it. I wasn't going to sit on things this time. Once I learned something, I was going to put it out there because next thing you know, I'm moving on to something else and I want to put that out there. Finally, I had a simple and kind of functional aesthetic that I didn't change very much before because I

didn't want to touch something and break it. Let's be honest, I was still a newbie. If I couldn't fix something, it was going to stay broken. But as I started to learn more and get more comfortable technically, I went for some cool extras. And I'm going to try and show you some of those. So, so this is what my blog looked like currently. Um, it's not online.

I just have this on a locally hosted WordPress situation, but I started adding little color changy effects and cool buttons. I thought my drop shadow was really neat in the beginning. My about page used to just have a little picture of me in the corner and then a bunch of text. I threw up a bigger image. You can tell this is old because my appearance has changed

somewhat. I included a dark theme just for funsies and my little flippers. The more I could do on the front end, the more I just wanted to play around with things and show off my skills. And my posts looked like this. They had a dark theme as well. And this is one of the very first posts that I put up because I remember being a long time

on the outside looking in, seeing all the memes and thinking to myself, what does this mean? And feeling like I wasn't really part of it. And then the more I started to learn, the more I started to feel like I was part of the community. And I wanted to give others that right away and also demonstrate that I was learning and I knew what these things meant.

So, this was it didn't follow the regular formula, but every now and then I deviated and added some things that were just more fun. So, what happened? First of all, my confidence improved because I was demonstrating my own understanding and my competence to myself regularly. I would learn something, then I'd have to write about it and teach someone else. And so, that reinforced to me that I

actually knew what I was talking about. So, when I got ghosted by all of those different employers, I didn't sweat it as much because I knew I knew what I was talking about. Networking events got easier, too, because it was a talking point. I'm a really shy person. Um, people in my life can tell you how much I was freaking out just getting up here today to

talk to all of you. And it was really hard for me to do that networking dance where you see a little cluster of people over here and you kind of shuffle up and then you wait until everyone laughs and then you laugh too so that it looks like you were there all along and then you can kind of just work your way into the conversation. Once I

had the blog, people started coming up to me and I will say that was helped by being part of Girls in Tech and they'd share my posts and going through the boot camp they would promote my post. So people were seeing it at least locally. I'm not like wasn't a celebrity by any means, but people would come up to me at networking events and say, "Hey, you're

code copy coffee. I've read your blog." And then that gave me the opportunity to say, "Yeah, you know, when I made that blog, it actually taught me that I liked coding more than writing. Isn't it funny how you just can fall in love with something totally unexpectedly? Have you ever done that?" And then suddenly that gives them the opportunity to talk about something that they love that

maybe they don't necessarily get to talk about all the time. And people love talking about things they love. They may not love their job. They may not be super passionate about sort of the small talk things that a lot of people go with at network networking events. But when you get them on a role talking about their passion, that's a good happy positive feeling that you can

leave them with. And it also gets them to talk so that me, little shy person over here doesn't have to. And I remember the day that a recruiter came up to me at an event and said, "Oh, I I read your blog. That's really cool. Um, you should talk to this this guy, the hiring manager over at a company called Sohi." And of course, that is where

I am now. I also felt more prepared in interviews and I had interviewers reference specific posts. And once you have interviewers asking you about something that you're super confident about, you're going to be really confident in that interview. In my interview for Soshi, I remember I had my interviewer say, you know, we need someone who can communicate because we do mobs, we do teams. I need someone

who can learn and teach because that's one of the main principles that So she was founded on, still one of our main principles today. You learn and then you teach others. And that is exactly what I was doing with my blog. I was learning at first and then So I was and then for another position I had a um the VP of technology actually say I read

your blog and tell me about this post. Tell me about where you got stuck and how you got out of that loop. And so that's where I learned that showing where you struggled, even though it may seem like, oh, I don't want people to know that I ever struggle, is actually that can actually be something that's useful. So before I wrap up, I want to point out

that the next speaker, Lola, has these adorable little possum cards, and you should definitely find her and go up and ask her for one because they're really fun and because it will be a good exercise in going up and talking to people. As far as where you can find me, if you have questions or just want to connect, I am most often on LinkedIn or on Instagram.

So feel free to reach out and send me a DM. And I also love to just work on side projects with other people. So if you feel like I mean I know you have chat GPT now that you can ask all your questions to, but if you ever just want a buddy to code with um feel free to reach out. We can work together. If teamwork is

your jam um I mostly know PHP which everybody hates don't come for me. But I I can learn other things. I can do Python. I have a bash tattoo. So I'm buried. Um but hopefully you got something out of this because that's that's why I wanted to give this talk to give you something that you could actually use. And if you do want to come find me

and talk about things like what are my transferable skills? You know, I think I have this and this, but how how could I parlay that into tech? or if you have questions about um you know these this is my skill set, how how does this make a company money or save them time, I'm happy to brainstorm with you on that either here or just online after the

fact. Thank you so much for coming. How are we on time? Should we do question if anyone? >> Oh, okay. Um, does anyone have any questions right now that they want to ask? >> So, I've been very lucky. The question is, how do I identify a mentor? Because sometimes they're in your domain, they're outside of your domain, but really inspirational. Um, I think there's room to have

lots of different mentors. Um, in fact, I don't know if all of my mentors know about each other, but I'm about to out myself here. I have quite a few. Um, I have different mentors for different things. So, I met Steve in the beginning and he helped me learn a lot of those basic things when we worked together. Um it's it is a little bit tougher to

find mentors when you are just trying to break into the profession because you're not necessarily sharing a job in a physical space with them. But that's why things like meetups are really great. If you go and you hear someone speak and it sounds like they really know what they're talking about in a subject that you want to learn about, you can approach them after and just say,

"Hey, I'm looking for a mentor." Um other ways are uh LinkedIn. If you see someone posting something that again is something that you want to learn about or sounds good and there is absolutely room for those mentors who inspire you to that aren't necessarily in your domain but they could teach you those transferable skills maybe that you can still apply. >> sorry. Which platform do I run?

>> Which platform do I run? What? >> Oh, um, so currently it's just local on my machine on X Amp, but um I would probably my next step I'm going to try to self-host it on my Raspberry Pi. I uh I'm a little nervous about opening that up to the internet. So any any aspiring hackers in the room, please don't come for me. It'll be too easy.

Don't come for me. >> Don't come for me. You can you can red team me. >> I tried to be regular about it and post every two weeks. um didn't always get there because I was also working at my job and everything like that, but I did yeah try to be consistent just so people could there was always more to learn and I also wanted to be

consistent with myself and reinforcing that knowledge before it got too far behind me. >> Sure. Yeah. Um, since it's not currently out there on the big bad internet, um, I will put some posts. I'll take I'll do screenshots or PDFs and I'll put them on my GitHub after today. So, on Monday, I will have them up on my GitHub, which is on my LinkedIn, but it's also

github.com/bashgcase, same as my Instagram. >> Yeah. Anything that you're learning, any projects that you're working on, start writing about that. Um, if you uh let's see. So, if what is that one? Udemy. if there's Udemy classes that you're taking, if you're building something on there, and don't be discouraged if you feel like, well, people have already written about this, someone has a whole class on it. No

one's got it from your point of view. So, if you're working on, say, building a social networking site, that was one of the first Udemy projects I started. Just write about the process of doing >> Okay. Yeah. You know, I think that's a great that's a great point. Um, I haven't I shut down my blog in 2022 actually, so it has been a minute. Um, I'm definitely

not up on the the latest tips and tricks and tactics, but I before I put it back up, I absolutely want to be. So, thank you for that. Okay, thank you. testing. 1 2 3 All right. Next up, we have Lola Edgerman speaking on No Internship, No Problem: Using Open Source as your first real world job. Lola works with Codeday Labs, supporting California State University students, community

college students, career changers, and veterans. people for whom the traditional career path doesn't always work. Through her internship program, she connects students with mentors and open- source projects so they can make their first real world contributions and learn how to present that work on resumeumés and interviews. Please join me in welcoming Lola Edgar. Hello, I'm Lola Edgarman and welcome to No Internship No Problem: Using Open Just

as we get started here, a few things few thick a few quick things I want to note. Uh there will be slides available at the end. Um I'm telling you this because there are lots of links that will be in there and lots of QR codes. You don't need to scramble to search for them. You can just use the one QR code at the end if that's

if that's what you prefer. Um we're aiming to have about 10 minutes for questions, but I will be around after uh if you want to talk to me more than the 10 minutes that we'll have. Um lots of times during the talk there will be side boxes like this. They'll be fancy, colorful. They have big, bold headers, and they will have some resource that's useful and relevant

to whatever I'm talking about. Um, I won't always talk about them when they're on the screen, and that's because the last section of the talk will be summarizing all of those, and and each one will have its own dedicated slide, but just keep an eye out for those boxes. They'll be really helpful, and they'll uh you should look for them. So, um, a quick little bit about

me. My name is Lola Eggererman. My pronouns are she, her. I work for a nonprofit called Codeday. As mentioned in the introduction, we run an open source mentorship program. Um, this talk is not primarily about the open source mentorship program, but about everything that I've learned running the open source mentorship program. Um, for context, there'll be a little bit more about the about the program, you know,

on in in the next couple slides. Um, and then my favorite animal is the opasum. So, if you need an excuse to come talk to me, I have these little opasum trading cards. Each one has a different opasum on it and a different fact. Um, so if you want an icebreaker, walk up to me and ask for an apossum trading card and I'll give you one. So

this is a long talk and it's the last one of the day, but I promise that paying attention to me is worth it. And I have two main reasons why. For one, I run a mentorship program as mentioned called Codeday Labs. This is an online free mentorship program for everyone. We do a lot of work with the state of California. Um, we have about 1 to 2,000

students per year that make their first ever contribution to open source software um through the program. um it connects students directly with the industry and we have a proven impact on hiring outcomes and job performances. Part of that proven impact is demonstrated here. So this is an email from somebody named Mark and Mark is the VP of software at a multi-billion dollar tech company and Mark is

talking about an interview that he just had with one of my students and I want to highlight a few things that Mark said in the email. So Mark said that this student has oozing passion, is the cream of the crop, has a stellar resume, and that Mark has already forwarded that that stellar resume onto the relevant team at this company. I want to take a look at

that stellar resume and point a couple things out. The first thing on this resume that you'll notice is that this student goes to a community college. This is what's called in my field as a non-target school. It's typically, you know, students don't have access to a lot of opportunities and recruiters aren't going out of their way to to go to community colleges to hire at companies like

Markx. But the special thing on this resume is that this resume listed specific open- source contributions that this student made. And purely by having those open source contributions on the resume was so impressive that Mark fasttracked and interviewed this candidate personally. So this brings into a question of just what does industry even want because schools will tell you a lot of things about what industry wants. You

you know have a lot of miscon you have a lot of thoughts on what industry wants. Um and then industry wants something and and often none of these things are aligned. So we had this innovative idea of just let's just ask industry what do they want? So we interviewed 20 hiring managers at top tech companies and asked what are you looking for when you're hiring? And we

identified some major and minor themes here. And I'm just going to list these off and just keep an eye out for these themes because they're mentioned several times in this talk. And I've made it easy for you because they'll all be highlighted just like they are here. But so industry wants to look for people and hire people who have problem solving skills, who have initiative, who are

skilled at teamwork, who have domain knowledge, product sense, curiosity, and persistence. And these are loosely in order of how often they came up in these interviews that we did. And even the things that are labeled here as minor themes doesn't mean they aren't important. They just weren't universally important to every single person we talked about. And I want to highlight notably a couple things that weren't mentioned

when we talked to interviewers. They didn't say, "Oh, we really care about your GPA. We care about what school you went to. We we care about how many times you organized the chess club." Nobody said anything like that. They care about specific skills that you will be using on the job. And this is something that we call the experience gap. And you've seen this as job seekers

of every single entry entry- level job is asking for experience, right? And that's really frustrating. And that's because a lot of common undergraduate CS programs just aren't in the right format to teach the skills that industry wants. So on the left, you can see all of the skills that you can both learn and demonstrate by making contributions to open source software. And you'll notice it's every single

skill that the industry is looking for. And then on the right, there's just one skill that's easy to teach in a lecture, domain knowledge. So this is why this is the most important thing. This is why you should want to contribute to open source because you will learn all of these skills and you will have artifacts showing, hey, I'm really really good at these skills that you

can show to recruiters. You can mention in your interview, you can have on your resume and that'll make you the best candidate. So what even is open source, right? You've probably heard this word a lot, you know, while you're at scale. So who here is familiar with open source by a show of hands? Okay, most of you. That's good. Okay. Now, who here has made a contribution

to open-source software? Okay, that's a lot less people. So to the people who didn't raise their hand, I want you to come find me next scale and tell me about an open source contribution that you made in the last year. Can you all do that for me? Great. So, the key thing to know about open source is that it's everywhere. I'm going to go through some examples

of just popular open source software. We're starting with one that you've probably heard of, and this one is called Linux. I likely, since we're at the Southern California Linux Expo, don't need to go into a lot of detail about what Linux is and why it's cool. Next up, we have a piece of software called Inkscape. Um, Inkscape is my personal favorite piece of software of all time.

Uh, it's similar to Adobe Illustrator. It's a vector graphics editor used by designers and used all over for, you know, making art. Um, I use it for, you know, everything possible. I've used it for slide decks. I didn't use it for this slide deck so it'd be easier to access because most people don't use Inkscape to make slides. Um, next we have a piece of software called

I Naturalist. Um, this is an open source piece of software that's kind of a social media network for people to report nature observations. So if you see a plant or an animal, you can post it on I naturalist and then it's recorded and you can see statistics on migration patterns and you can discuss with other other nature observers. Um if you remember the apossum picture that was

on the about me slide that was a picture that somebody posted on I naturalist. Um this is a little bit of a meta one. This is an open piece uh an open source piece of software called all contributors. And all contributors is a piece of software created to recognize contributors of open- source software. So if you've ever seen anything like what's on the right there, that is

powered by the all contributors platform, which is itself Finally, this is the cheapest USB foot pedal that you can buy online. This is an input device. It's helpful for accessibility. Some people use it for gaming. And this is open source software used to configure this software on Linux because it's only supported on Windows and doesn't have any native firmware. So open source is all over, right? And

I'm telling you this because if there's anything that you personally are interested in, there's a really, really, really high chance that you can find a piece of open source software related to that interest. And I want to give you all a congratulations because you just earned domain knowledge. Remember how easy it is to teach in lectures? So now you know what open source is. We know it's

everywhere, but how do you even find an open source project, right? The answer to this is really, really simple. You just have to start looking for one. So I really recommend that you should look for a piece of open source software about something you care about. A lot of open source projects are on a website called GitHub, which you're maybe familiar with. They have a booth here.

Um, you've heard their name a lot if you're if you're listen to people talk about open source. And you could just go on GitHub and search for something you're interested in. So, oh, did I Oh, I pressed the button. Whoops. Okay, so you could just go on GitHub and in and you can find an open source project related to that. So, a couple things I want to

highlight. So, I I'm interested in Magic the Gathering. I play a lot of Magic the Gathering. So, I went on GitHub and I searched for Magic the Gathering. And then what I did is I sorted by most stars. stars is like a like on social media. So if a project has a lot of stars, it's popular, it has a lot of users, you know, a lot of

people contribute to it. And so that's an easy way to find big open source projects. You want something kind of in like a middle scale. Um because if it's really really big, it might be hard to understand. But then if it's really really small, you know, it's it's there's not much of a community there and you need to have a community to to contribute to the open

source. So, a couple specific things about this cube cobra project that I found when I was looking for a Magic the Gathering open source project is so one, it has, you know, 250 stars, which is a pretty reasonable amount. You know, there are projects on GitHubs with tens of thousands. So, it's not a whole ton. But it's not that it's this, you know, nothing project. Um, it's

also been updated recently. So, you can see there it's been updated 4 hours ago at the time of me taking this screenshot, which is a couple weeks ago, but updated 4 hours ago. So, it's an active project. People are still developing it. And then it also has this label on it that says Hacktoberfest. Does anyone know what Hacktoberfest is? Okay, we have one person. So, Hacktoberfest is

an event that happens once a year and it's all about getting people their first contribution to open source. Um, so this Cube Cobra project was so excited about the idea that open source contributors could come and contribute to their repository that they added Hacktoberfest to one of their GitHub tags. And so that this project to them is just as important about the fact that it's made in

React and Node.js is that the fact that it's open to new contributors and they they've told you that by by telling giving you the the Hacktoberfest tag. So when you're looking at a repository, there are a lot of different things you can look at and I'm not going to go over all of these. Um and there's a resource on the on the side there for you know

more even more things to look at. But the number one thing I really want to emphasize is does the project matter to you? Because you are going to work harder on something. You're going to be more motivated. you're going to understand something the best if it relates to something you care about. Does this software solve a solve a need in your community? Do you use this software

and and you encountered a bug and you want to fix that bug? Right? You're going to you're going to work on that if it matters to you. So, I want to make sure when you're looking at different open source projects tomorrow when you're starting your contributions to open source, make sure to just think and have that be the first thing in your head is does this project

matter to me? And then once you found an open source project you think you want to contribute to, you're going to want to find an issue. So open source projects have issues which is you know sort of like their bug reports or feature requests and it's people who have said hey you know I want to I wish somebody would fix this but I don't want to fix

this so somebody else should do it. Um a lot of things that maintainers do is they will put a tag on their issue that says good first issue and this means exactly what it says. It means that if you're a first-time contributor and you want to make your first issue in this pro and you want to work on your first issue in this project this is a

good one to start on. So keep an eye out for that good first issue tag and you can search for good first issues. So I have a couple examples here of just what a good first issue looks like and there are more examples in the resource linked and again I'll talk more about that in a moment or at the end of the presentation. So this is a

an issue in an open source piece of software called free code camp classroom. Um this is a learning management system for teaching programming. You know kind of similar to like blackboard or canvas if any of you use that in your classes. And so here they're making a bug report where they're just saying, "Hey, we don't like how this is displayed. We want it to be displayed differently."

It should be really, really easy to display it differently because all the data is right there. Um, and then what's what's awesome about this issue is another contributor has even gone in and said, "Hey, this is the file that you should probably look at." Like this would be a really good starting point. And so you could go in and you could see do that look at that

file and you you'd hit the ground running making this contribution. This is another issue. Um, you'll notice this one has that good first issue tag I was just talking about. And this is an issue um in the p5.js graphics library. If anyone happens to be familiar with that, it's used for a lot of drawing, you know, programmatic art, physics, simulation in the browser, that sort of thing.

So, this has both the good first issue and a tag that says help wanted. So, they are up here shouting from the rooftop saying please, please, please, we want somebody new from open source to make this contribution to our repository. And the cool thing about this issue is that it's they're asking not for a code change, but for you to write documentation. So they've said, "Hey, the

our project documentation is missing these these critical things our users should know about. We none of us have had time to write it. Do you want to write it?" And the reason I'm showing this here is because not all open source contributions have to be writing code. You can add to documentation. You can, you know, work on the, you know, user design. You can you can design

their make a better logo. You can improve the marketing, right? There are lots of things that you can work on. Not every open source contribution has to be specifically technical. Um, and that's all valuable even if you work on something that isn't writing actual code. And it's often really easy or it's easier to start with something that isn't technical. So if I had never contributed to this

p5.js graphics library, which I haven't before, I might want to start on an issue like this because it's I can write documentation, especially when they've listed exactly what I need to write. I just need to put it in a more formal tone. And then I'm also familiar with their documentation. So when I work on my second issue, I'll already know how the library works. So when you're

looking for a project and an issue, this teaches you initiative, product sense, and curiosity, which you remember, these are all things that recruiters want and things that tech hiring wants you to have is they want you to have these things. So when you're looking for projects, when you're looking for issues, it helps you get better. Even if you haven't done any coding yet, you're still learning. So

you're working on open source and and I get this question a lot of of you know Lola what is the hardest part of contributing to open source and unfortunately there is not an easy answer to this question because there is not a hardest part of contributing to open source contributing to open source what that looks like for everyone can be very different um and it can be

you know different levels of difficulty the further you work so um this is a graph that some students that I worked with um about a year ago made of how hard it was for them making their first open source contribution. And I think this is a really good graph and it highlights a lot of things that I want to mention. So there are a few things I

want to point out on this graph. The first one is that every time the project got easier, every time that they felt like, oh, it's it's not it's not as hard anymore, is when they asked a question. So I know that the circles I added covered up what the labels are, but so the first one is sharing knowledge is helpful for all. The second one is asking

questions save time. And the third is documentation for nextdevs. So it's not specific technologies. They just learned how to talk to people better and they learned how to use the resources that are available and that's what made it The next thing I want to point out is that it is very uneven. This graph is jagged. It's like a mountain pass, right? And so it's contributing to open

source and getting better at software engineering and problem solving is not a linear process. It's really easy to think of uh you know kind of be down on yourself because you try and relate it to other skills. Like if you're learning an instrument and you practice every day, every day it's going to get a little bit easier. Open source is not like that. Being a programmer is

not like that. And a lot of you have probably already figured that out. Um but that's normal and some things are easy, some things are hard and it's always going to be changing, right? that this entire graph takes place over a 12week period. And I think they had already contributed to open source before. So this was their, you know, subsequent pull request. They were still pretty new

to it. But um in in my program, Code Labs, it we estimate it's going to take you about a month to work on your first pull request from start to finish. Um and that's for, you know, a small change. And so my takeaway for you from this is be patient with yourself. Learning takes time. Like this is really hard stuff that you're doing. You know, you are

solving problems nobody has ever solved before. and you are going to struggle and that's a good thing because these are some really common things that almost everyone struggles with when they're contributing to open source. Um, and these are skills that you're going to need to have every single day when you're working in the in the software industry. You know, when you're solving problems, you're going to need

to set up new development environments. You're going to need to navigate large code bases. That especially happens every single day because the company who's hiring you to to work, you're probably not their other you're their only engineer. they're going to have, you know, tens or hundreds or thousands of other people also writing code. So, you're going to have a lot of code there. Okay? And that's going

to be hard. That's hard to get to because a lot of projects in school are like one or two files. And it's really easy to get that all in your head. But then you can't do that with with larger scale projects, right? You're solving new problems. Okay? And you're, you know, learning new technologies and languages. You know, I always say that learning how to be a good

programmer is not learning how to program, but learning how to learn to program. And if you're good at problem solving, you'll be good at programming. But you have to get better at problem solving. You have to work on that. And you'll notice problem solving is the number one thing taught by each of these. And that's on purpose. And I'm pointing that out on purpose because if you

remember, problem solving is also the number one thing that recruiters were hiring for when we asked them, "What skills do you want?" So the other thing I want to point out is that it's okay to ask for help. You're going to get stuck and asking for help will save you a ton of time. Just like we saw in that graph from earlier, every time they asked somebody

a question, every time they, you know, wrote a documentation or, you know, shared knowledge, it made things easier. So, it's okay to ask for help. There are so many projects that have dedicated programs specifically for firsttime people working on their software, and they'll answer your question, right? Everyone you're talking to also remembers what it was like and how scary it was for them to make their first

open source contribution. My first open source contribution was fixing a typo in documentation. And it was like one line of change and I kept, you know, apologizing. I'm like, I'm so sorry. I know this is nothing. But then it's like, no, it's okay. My first poll request was fixing a typo, too. So, everyone knows what it's like to be there. And everyone started somewhere. Even, you know,

this this really experienced person you're talking with who's reviewing your code is thinking about in that moment what it's like to be in your shoes. And they know how hard it is. And they will help you. And I also want to make sure, you know, not to be afraid to just be honest and just say, "This is the first time I've made a contribution to open source.

What do I do? like I'm so stuck. What do I do? Right? You know, you can just say that. No one is going to be mad at you if you say that. You're allowed to just be upfront and say I'm not sure what the next step is. And showing that you're asking for help. You're going to learn how to, you know, take initiative to have teamwork and

persistence. And because it's open source, you'll have all this document. You you'll have document documented. you'll give specific artifacts showing when you asked for help and that you asked for help in a in a good way and that you took feedback and all of that which is really really really valuable to you know recruiters when they're looking at your resume and just being able to ask people

for questions is going to be really good to you as an engineer. You are also solving problems that nobody has ever solved yet. When you're in school everything either has a, you know, a right or wrong answer. You know, you use the quadratic formula correctly or incorrectly and there's no in between. And if you get stuck, you know, your your professors who are all experts can tell

you, you know, here's the right answer here. Here's how you get to the right answer. That doesn't happen in software engineering. Nobody else knows the right answer. If they knew the right answer, they could just write the code themselves or ask an AI to write the code. You're you're solving a problem they don't know how to solve. People can help you, you know, give suggestions of, oh,

here's how I would approach solving that problem, but they they don't know exactly how the problem is solved. And that right there is why problem solving is the most important skill for recruiters because that's what your workforce is going to look like. That's what your job is going to look like is solving problems and solving new problems. And so they want people who can just be like,

"Hey, fix this." And you're like, "Yep, I know how to solve problems. I can fix that." So now we know everything there is to know about open source. Right? But how do you even contribute to it? How does contributing to open source even work? If you have ever taken a class in school and they've tried to teach you Git or GitHub, you have seen a lot of

really, really confusing diagrams like this one, this one, or this one, and they're telling you about branches and tags, release candidates, rebates, and you are, you know, irrationally scared of this thing called a merge conflict. Um, the really great news I have for you right now is you don't need to learn any of that. at least right now. And I'm going to explain to you how simple

open source really is. This is all you need to know about open source. There are four main components. The first one is the main repository. This is where everything starts. It's where the final code is and it's how users go to download the project. So here I have on display the main repository for a project called Open Energy Dashboard or OED. Um this is a project we've

had a lot of our interns contribute to. And so this is where people go if they want to use OED they go they go there they go to you know github.com/openergy/ed what you can do is anybody can create what's called a fork of the repository and this makes your own personal copy of that main repository where you can do whatever you want you can make any changes

you want and this doesn't affect the main repo at all right so you can see here I've created a fork of OED where I've improved the name of it and I've renamed it to open Lola dashboard Um, and then but you can still see I took the picture on the left after I made my change in the fork and it's the project is still called open energy

dashboard to the people who go to download it. So you can do anything you want. You don't need to be afraid that oh this might have a bug. This isn't finished yet. That's okay. Um, to make your changes in your fork, you clone the repo. Um, this is just downloading it and then you can open it in your IDE of choice. You can run the code. You

can do the documentation. you go, you can use all the tools you're familiar with, you know, VS Code, Jet Brains, whatever. Um, once you've made changes that you're happy with, you make a commit and then push it. And this is basically just uploading your code back. And that's uploading your code back to the fork, not to the main repo. So, still everything you do here completely separate

and you can do whatever you want. Okay. Once you have some more code in your fork and once that's ready, you open what's called a pull request. A poll request is you very politely saying, "Hi, I wrote this code. Do you want to use the code that I wrote in your project?" So, here I didn't actually open this poll request, but I just made this an example

of here's me asking them to please rename the project to open Lola dashboard and that I have added to the read me. I've renamed the project to open Lola dashboard and I think that makes it better. Um, and then you open the poll request and then a open source maintainer will look at the pull request. They'll review it. They'll download it to their computer. They will try

and run it. They'll make sure everything works. They'll make sure it does what you say it does. And then if they like what they see, they will do what's called merging it. And that is where they take it back and put it back into the main repository. And only maintainers are allowed to merge. So even though it's open source, anybody can ask to make changes, but it's

only these special maintainers who can actually make those changes. Sometimes a wrench gets in the work and there are some things that are might happen as part of your poll request. You might be asked to sign a CLA. Um, a CLA is some kind of legal document that just says, "Hey, you're not going to sue us because the code is open source." It's a little bit more

complicated than that, but it's usually very easy to move forward on signing the CLA. You might be asked to add some test cases to your code to make sure that, you know, even if the code works now, they can automatically find out if the code ever stops working. And that's really helpful for future contributors of the project. You might be asked to make some really tiny changes

like, "Oh, we like tabs instead of spaces or we don't like how you named this function." You know, they might have some really small thing that seems so trivial, but it's on you to to change that. And and that helps because even those really small things add up when you have hundreds of contributors. If each person is using a different coding style, then the project is really

hard to read, right? And so those small changes, you know, can add up. Um, sometimes there might be some build error. Ideally, you've tested your code before you made the pull request, but they might have some different machine. Maybe it only works on whatever operating system you have, and it needs to work on other operating systems. So, you might have to fix some small build errors. And

it is really, really normal to be asked to make these kinds of changes. Um, I have on the bottom here, this is feedback that I got on a PR that I made where you could even said see the maintainer said, "Oh, this is really great, but I have two paragraphs of things that you still need to do." So this happens to everybody even people who have made

a bunch of open source and congratulations you just made gained more domain knowledge that part about it being easy to teach in lectures hasn't changed. So you've heard this word a lot of of a maintainer right and that sounds kind of scary. Is anyone scared at the the idea of a maintainer? Okay. Wow. Nobody. That's okay. I guess it's just me. So there are some really common

misconceptions about maintainers that I want to kind of dispel here. So maintainers are trusted members of the community and I I'm sure there are a couple maintainers in this room. Um and they have permission to make changes to the to the main version of the code. A lot of the time open source maintainers are volunteers and they are helping the project out of their own free will

in their spare time. A lot of people work full-time jobs and then maintain on the side. Um and projects can have any number of maintainers. You know it's typically larger projects will have more maintainers. Smaller projects will have less, but it can really vary. You might have a small project with a ton of maintainers. Um, and maintainers are all people. Okay, these are three maintainers that I've

personally worked with and I've really enjoyed working with and they're all really friendly and if you work with them, they will be friendly to you too. So, um, on the left we have Colton Padden who, uh, maintains a project called Dagster and Colton is who you saw earlier making giving feedback on my poll request that I made to Dagger. Um in the middle we have Rajep Barachary

um who is a maintainer for keyshade which is a secret management tool and uh on the right we have KitKanak who is a um they are a maintainer of p5.js which I talked about a little bit ago. It's a graphics thing. Um they're all really really friendly and awesome people and every other maintainer that I've ever worked with has been really really friendly and really awesome people.

Um when you're talking to a maintainer even though they're awesome you should still follow some rules. The first one is to be respectful of their time. Like I said, a lot of maintainers um do this as a volunteer position and they might take a month to look at your code because they've been so busy at work, right? And they have other contributions that they need to look

at and they're a volunteer. So, just make sure to be patient and be respectful. Um when you communicate with them, that's another way you can be respectful of their time is to communicate clearly. You know, be transparent, be concise. Make sure to do your homework first of if you're asking them a question, say, "Oh, here are the the ways I tried to answer this question independently and

and why I'm asking you instead of looking at the docs because it's not in the docs, right? Or if it is in the docs, I couldn't find it. Here's what I tried." And if you're making a poll request, make sure your code works. Um, at least, you know, make an effort to test your code. Sometimes it can be hard to test it on every single platform, but

um just make sure that it's clear you've made an effort to to test your code and and just that you're being respectful and and acknowledging that they are taking time out of their very very busy schedules to look at the code that you've written. So ultimately though, maintainers are still there to help. And every time you talk to a maintainer, you're getting better at teamwork skills and

you are creating more artifacts demonstrating other people when they look at your GitHub profile, they see, oh, this person is awesome when they talk to maintainers. Right? It's like the same way of, you know, it's sort of like when you're talking to a maintainer, it's like a professional email you're writing at work. So, if a recruiter sees that you're writing really, really good professional emails and you're

really good at professional communication, they're going to want to hire you, right? Because that's how you're going to act in the workplace. And open source, it sounds really scary now, right? Because you have to talk to a lot of other people. And it it almost sounds like there's more talking to other people than there is actually coding. And that's is that scary to anyone? That was really

scary to me when I started. And now you kind of know what an a maintainer is. We're going to we're going to talk about this. So, um, yes, talking to people is hard. Um, and it takes time and it's a skill that you need to learn and cultivate and develop. Just like being able to code, you need to be good at talking to people. Um, there are

some really specific key teamwork skills that when you're contributing to open source, you'll be learning more of, right? Like asking for help, being able to talk to your talk about your code non-technically. That's a really really big one. being able to explain to, you know, someone who who doesn't know the specific lines of code that you wrote what your code even does. If you say, "Oh, you

know, this instantiates a new class that, you know, is named this and it has these built-in functions." None of that matters. It's, "Oh, this handles the payments for our software." That's, you know, being able to talk like that is really, really helpful. Um, being able to work with others on code, you know, open source projects are big. Lots of people are working on it. And it's a

different way of coding when you're coding with multiple people. Um, you'll also sometimes disagree with people. People will ask you, you know, hey, why did you do it this way? I don't I don't think that's right. But then you can say, well, I did I tried it the way you did, and I thought this way was better for X, Y, and Z reason. But being able to

stay professional while you're arguing with people, which is, you know, really hard when we're on the internet. Um, but being able to stay professional and handle those disagreements is really, really key and going to help you succeed in the workplace. Um, and you will use these these exact teamwork skills every single day on the job. Um, so yes, open source involves talking to people. Yes, that is

scary. But yes, it is worth it. So now that you know a lot of these things, I have a question for you. Can you contribute to open source even without internship or work experience? And before you answer this question, I have a spoiler that the answer is yes. And great news, the answer to this question is yes, you can contribute to open source without any prior internship

or work experience. So anyone can and should work on open source. You can start really small. You can work on something non-technical like I was talking about with those documentation changes of, you know, updating the documentation, fixing a typo, just like my first pull request. If you make a mistake, it won't affect the end users because it's all in your fork or in your pull request. And

the maintainers are there to help you out. And every single thing that you do when you're working on open source will make you a better problem solver. And industry wants to hire problem solvers. So you should work on open source if you want to get hired by industry, which if you're at an event called open source career day, you want to probably have a career. So recommend

getting better at problem solving through open source. Um once you've made some contributions to open source, you also need to be able to talk about those contributions to recruiters. And the first thing that you should do about that is you should write about your experience. So I am not an expert on blogging, but in the audience we have Gina who is and her LinkedIn code is on

there. This is not in the slide in the in the the recap slides because I just added this after talking to Gina and getting and getting her permission. So, I'll give you a moment to scan that. Um, if you want to talk to Gina or you can find her. Um, just make sure that when you do something you're proud of, talk to people about it because you're

the expert on what you've done and you can't expect other people to just know what you've done if you don't tell them about it. I have a few examples here as well of you know open source contributions that or open source blog posts that some of my students have written that I think these blog posts are really good and you can use those as a model for

you know what your you know posts and and how you talk about your open source should look like. So you should also put your open source contributions in your resume and doing that is you know a little different than how you would say you know oh here's you know my work because it's it's just different you know so you want to make sure that you talk about

here's a suggested format to talk about you want to talk about what the project is and you know what the issue was that you worked on so talk about how many users there are if there are a lot of users or if they're you know really niche users you know talk about who uses this product and That helps show that you understand you have product sense. So

you understand what the what the code is, who uses the software, why that software important, you know, what need does it address in the community. You want to make sure to also use specific technical language. So talk about, hey, I use Docker for this project. You know, this was a, you know, react.js website that I contributed to. You know, talk about the specific skills that you learned

and you demonstrated and that you used when you were making that contribution. And then talk about what was hard about it because you want to talk about oh this was really really challenging because you know this code wasn't compatible so we had to refactor this part or you know this was really hard we really couldn't figure out the right location for it. Talk about what was hard

about it and how you overcame that challenges. And you also want to make sure to just include links. You know recruiters want to click through and they will click through. So link to the issue or pull request that's related. You know if you wrote a blog post about it link to your blog post. talk about what you did and make sure people can find where you talk

where you spoke about what you did. Um, I have an example here of, you know, one of uh, one of my students and how they listed one of their open source contributions in their resume. You'll notice they didn't do everything that I said here and that's because this is just suggest just a suggestion. It's a format and you are responsible for bragging the best about what you're

the best at. So, I'll give a second because I see a couple people are taking pictures. So um and the slides will be will be available at you also want to talk about what your contributions demonstrate. So you know you can sort of lead you know they recruiters care about the fact you have contributions but they also care about what your contributions mean. So talk about what

you've done and demonstrate how that showcases the skills you excel at. You don't need to list all of these these seven things of these seven, you know, key key elements, but talk about, oh, I think I'm the best at initiative, right? So, I'm going to really, you know, highlight why you should hire me because I'm really good at initiative. I have strong initiative. Okay? And here's how

my open source contributions demonstrate my initiative. So, I have a few specific examples for other um ways to talk about, you know, teamwork and domain knowledge. These will be available at the slides in the end because we're running a little bit short on time, but you can you can talk about this. And so just make sure to talk about what you do and why they should care

that you did that. So you know everything about open source now. Congratulations. What do you do next? The first thing you want to do is just find a cool product or find a cool project. Pick an issue. Tell the maintainers that you're working on this. and then open a poll request that addresses the issue. So on the left here I have a an open- source project contribution

guide. Um this is a guide that code wrote. It's aimed the target audience is people who have made one poll request and helping them make their second poll request, but a lot of the information in there is still going to be helpful for you making your first um when you're finding a project um when you're evaluating it, if you want a specific like metric, it's it's and

a rubric to follow of specific things of about the project, there's this project evaluation rubric. This was created by an organization called teaching open source which focuses on just how to teach open source in the classroom. Um which is something people do care about, but it's something that's hard. Um I went to a panel a couple weeks ago at a different conference. It was just called why

is git so hard to teach? You know, it's been out there for 20 years. We should have figured it out by now. Um the conclusion was we still don't know. But yeah, so check out this project evaluation rubric when you're looking at different projects. One thing that's not mentioned on that is does the project matter to you? You know, is it important? I know I keep saying

that. This is the fifth or sixth time you've heard me say pick a project you care about, but it's because it really is that po that important. You need to be you need to care about the thing you're working on and you will learn more. You'll be more motivated. it will feel more rewarding because you can see the specific outcomes of what you've done when you're looking

at an issue. This is another resource you can do. This is another thing that's kind of the the target audience is a little different. Um this is a resource code wrote specifically for maintainers helping them create issues that are good for first-time contributors. But the reason why I'm sharing it is because it has a lot of specific examples of different categories of good first issues and what

those look like. So you can click through to that and you can see, oh, this is what I should be looking for. This is a real world example of an actual issue somebody solved and why it was a good first issue because we wrote about, you know, I think the resolution is too low, but we wrote specific things if you click through on like why this is

helpful. So the next thing I want to talk about is Codeday Labs. Um, you've heard about it a couple times, so I won't go over the whole thing again, but it's the program I run. I think it's really cool. um if you want to participate in it, we have general um public applications that open in April. Um it's accessible to people who have never contributed to open

source before. But for the summer program specifically, you have a higher chance of acceptance if you've already made an open source contribution. So you have a month between now and April to make an open source contribution and have a higher chance of getting into my program. Um yeah, that opens April um April 6th, I believe. It's a Monday. So check that out, learn more if you're interested.

Um there's also something called if you're a student in the state of California, which I know most of you are. Um there is something called the computing talent initiative. This is a program out of California State University, Monterey Bay. Um and it's open to any CSU student, but I think also any student in California at a public university. Um they are really really cool. Like I cannot

speak highly enough of all of the faculty that I've that I've worked with, you know, in my job at the at the uh CTI. Like all of their people are are fantastic. They have like a special curriculum specifically on, you know, this kind of thing. And they have so many different programs available um including mine, Codeday Labs. So if you're in California, that's the easiest way to

participate um even even over applying to the public because you'll get a a much you'll have a much higher chance of getting a seat. So that's something to check out. And outside of my program is also just really cool. So there are also a couple of websites specifically for people to help find good first issues. The first one is, you know, aptly named goodfirst issue.dev. Um this

just has a list of things on GitHub tagged goodfirst issue. Um and a list of projects that regularly have good first issues. Um a similar website to that is this one called upforgra.net. Um and that's just an alternative if you know you couldn't find anything on good first issue or vice versa. Another thing I just want to make sure to emphasize is when you're looking on those

on those um websites, keep in mind, is this project important to me? So that's everything. Go ahead, get started to open source, start contributing, and we have exactly 10 minutes for questions. I did a great job keeping the Uh okay, I think is there a microphone to pass around or Oh, you're not. Okay. Yes. sorry. Uh, the um, what if I want to or what if I

want to work on an issue and somebody else beat me to it? >> Yeah. So, the question was for anyone watching live is, what if I want to work on an issue and someone else beat me to it? Um, this happens. There's only so much you can do about it. The number one thing you should do is just say when you want to work on an issue,

comment, "Hey, I'm working on this. I want to work on this. can you assign me the issue? Um, and then that way someone else if they're looking at that issue can can see, oh, someone else is working on this. You know, I should find a different one. It can unfortunately still happen that you'll get sort of sniped and someone will just take it out from under you.

But telling people, hey, I'm going to start working on this when you start working on this and and giving regular updates of like still working on it, stuck on this thing, you know, can help to to prevent and mitigate that. any other questions? >> Yeah. From my experience, >> yeah, so the the question was um when looking for a good first issue, you can find issues sometimes

that are really out of date, you know, like three or four years old. Um and and specifically it was a they were asking do I have a cut off point for when to stop considering an issue. So it can kind of vary on the project. You know sometimes some projects that are really mature you know a a three-year-old issue can still be relevant but then sometimes if

it's a fastmoving project you know the feature they're complaining about doesn't even exist anymore. So that's to say there's no universal answer. I typically aim for something that's between two months and 12 months old. Um I don't want a something that's too, you know, recent and too new because then if it's high priority for the maintainers, you know, they might, you know, go ahead and and snipe

it and work on it while I'm still working on it. But then if it's past like a year old, the code might not be relevant. It might not still be a priority. So I would I would aim for 2 to 12 months as your ideal age, but it can really really vary and you can make a judgment call based on the on the How do you deal

with resistance? >> Yeah. So, the question was, how do you deal with resistance and negativity when you're when you're contributing to open source? So, um it doesn't happen a whole ton because people want you to contribute to open source. You know, as a contributor, you're giving the maintainers free labor. So, they're usually very happy about that because it's something they would ordinarily have to do. And you've

said, "Hey, I'll do this instead." They're like, "Great. you save me a ton of time. Um, I would say though in the in the rare cases you do encounter, you know, resistance and negativity is just to, you know, make sure to stay professional and like keep in mind that it's like, hey, I know what I'm talking about and like this person is kind of in the wrong.

But despite that, I still need to, you know, be professional about it because everything you do on GitHub and everything you do in open source is open, right? And so, you know, potential employers will see the kinds of things that you've been saying. And if you're really mean to people when they disagree with you, you'll likely be mean to people when they disagree with you in the

workplace. And that's not going to be super appealing to them. So, >> when it comes to focus GitHub. >> Yeah, that's a that's a really good question. So, the question is a lot of open source projects are on GitHub, but not everything is gone on GitHub. There are things, you know, like GitLab or people will just open source or or have their own self-hosted Git servers. Um,

and and the question was, you know, does it look better for recruiters to only have GitHub or is it okay to make contributions to other projects? Um, I don't know exactly. Um, because I'm not a recruiter. Um, my my thought would be that it's still open. Um, and if you can still link to those artifacts, they'll click through. They might not be as familiar with it if

it's, you know, like a niche thing. Even though GitLab isn't really niche, I would say it's mainstream, just doesn't have as much market share. Um, you would still be able to to click through and see those artifacts. And by contributing to these GitLab projects, you're building the problem solving skills that are going to make you, you know, make you succeed. So um yes but also no. >>

So yeah that's a so the question is work on do you work on one project or multiple projects? Um and this is also a question that my answer is yes but also no. So for one, working on one project and getting involved in that community is going to show, you know, like persistence and you'll you'll be able to be a more valuable contributor because you're already experienced

with that project. But one of the really cool things about open source is that you can there are so many open source projects because open source is everywhere, right? I had like six slides talking about all this random open source stuff. So you can really use that to find what project you want to contribute to. So you could, you know, hop around and make a couple PRs

to different projects and until you find the right one. And that's one of the really cool things is you can't really experiment like that with any other way to learn CS and you could figure out, oh, I really like, you know, data analytics or I really like working on front end or I love, you know, writing, you know, APIs or, you know, I hate all of this.

I'm going to pick a different career, you know. Um, so it looks good to have repeated contributions to the same repository, the same project, especially if it's like a notable one. Like if you could say, "Oh, I made four commits to the Linux kernel." Like that sounds really cool, right? Um, but also you deserve to find what you actually want to do. And so it's okay. It

doesn't look bad that you've tried a bunch of different things. Um, so it's kind of both valuable. >> Are you able to get into more detail about that program? >> Uh, which program? >> The 8week program. >> Oh, yeah. So, yeah. So, the question is, can I share more detail about the the 8week program? So, um, yeah. So, this the program I run is called Codeday Labs.

Um, and it's an 8week program that happens over the summer. And what we do is we'll match you with an industry mentor. So it's someone who has worked in software engineering but maybe not specifically in open source or on that project and then they will help you work through and give you highle guidance on problem solving and making your contribution. They'll walk you through making your contribution

um over that period of 8 weeks. And so code day will assign you um an issue and an industry mentor and we have lots of other resources available for you to get started and and you know like a crash course on learning git or whatever the programming languages are used by the project and we have some other like tutoring available for if you get stuck on something

specific. Um, and then once you've, you know, finished the program and you've made your poll request, we connect you with, you know, resume help and practicing for interviews and if it's relevant, like a specific company who wants to hire people who have like worked in that vertical. So, Thank you very much, and I look forward to hearing about your open source