 When you take your seat, make sure you make it possible for other people to sit in your row as well and shift if necessary so everyone who is interested could join. And please be aware that you can disturb the speaker if you slam the door, so please try to enter the room carefully and gently close the door. All right? Yeah, so if you see a space to the left or right of you, please shift so that other people can sit from the rows, from the entrances. Thank you. Testing? Can you hear that? Yeah. Is it like a ratings piece of your app? Feedback? Yeah, that's not that. Okay guys, we will start shortly, but one more time if you have a free seat on your left or right hand, you're doing it wrong. So shift so we can have more people sitting here. Shift towards to the middle and the side rows towards to the side probably. It was going to be awesome, right? Come on in. We're about to start. Okay, so we have last few people entering the room, then we're locking the room and nobody can get in. And guys, if you can't find a seat, this seat keynote is broadcasted to the rooms underneath in the basement so you can still find some free seats there. I actually see a couple people downstairs and yeah, it's more or less empty. All right, so welcome everyone on the eighth developer conference organized here in Bernal. My name is Radek Volkow. I'm one of the co-organizers. A couple things before we start with the keynote. As you know, developer conference, conference organized for developers, conference organized by developers and volunteers. Most of the work that was done around this conference is done by people in their free time as a volunteering activity. So I would like to thank them right now, first thing, but then second thing, if you see something going wrong with this conference, something that you would change here, please do it. Don't hesitate and do it. It's conference that we are all organizing. One more thing like this. During the conference, all the sessions will be recorded so everything will be on YouTube. All the speakers will present their slides on our DevCon webpage. So if you find something interesting, find the website, find the slides there. We have a couple offloading rooms. So the schedule is really packed and we will try to keep it on time as much as possible. If you want to talk to the speaker after the session, grab him to the rooms that are labeled as private rooms here and you can talk to them there. Important thing, developer conference, it was last couple years that we usually had the two main days and then Sunday was kind of fading out already. This time Sunday is packed with talks and we really want to convince you to stay here as long as possible, even on Sunday. So important announcement here, we will be doing, as the very last session of the conference, we will be doing a great quiz where, I guess, like 15 people can win a really great prizes. We have a bunch of interesting stuff here. So make sure that you stay here as long as possible. And of course, a great conference wouldn't be a great conference without great party. So there will be a party in StaraBernard brewery tomorrow. The tickets will be available at the Redhead booth right in front of this keynote room. So make sure you get your ticket because unfortunately the venue there is limited. So stop by the Redhead booth, get a ticket there and make sure you make it to the party. So before I hand it over to Tim, I would like to thank the university, Bernhard Technical University here for this great venue. We've promised them that we will keep the venue in the shape as we got it. So please take your trash with you. Please make sure that this room stays clean as much as clean as possible. And with that, I will hand over to Tim, my boss and my friend. And so as you might have realized, we're doing two keynotes. And I was just telling Tim that he's doing the corporate Redhead keynote. And Jan Wilderberg is doing the more open-sourced one. But I don't think that's true. We'll see. Is that loud enough? Let me turn this one off. Oh, maybe if I turned it on, it would work better. How's that? All right. Step at a time. All right. Thank you, Radik. First of all, I want to thank the Bernaud team. They're always extremely hospitable and they put on a great event. So I know we haven't proved it yet. We'll see how good it goes. But I'm really grateful to Radik and the whole Bernaud team for pulling this together. So this is a new presentation for me. I wrote it just for this conference. It's different. Usually, when I do these keynotes, it's more of a technical roadmap. But this one's not at all a technical roadmap. It's something different. And so I really appreciate feedback. If you see me in the hallways later or something, tell me, you know, you liked it. It sucked to anything, you know, just any feedback is welcome. Okay. So what we're going to talk about, this presentation I just wrote, it's called Rockstar Recipe. So what it's about, it's about proven approaches that I've seen by dealing with thousands of engineers, literally thousands in my career. And I've tried to do, it's basically a top 10 list. I got like 10 slides that show like, what are some of the attributes? What are the behaviors? What do I think makes a really awesome engineer? And, you know, most of the stuff isn't even particular to engineers. It's generic. It applies to pretty much anyone. And why, you know, why should you care, right? What's good about this? It's about you. It's about your career. It's about people who are happy and enjoy doing what they're doing and are good at it. They enjoy life better. They're more pleasant when they go home, you know, to their families. Think about how much time you spend at work with, you know, whether it's online or, you know, directly in the office with other people. So, you know, you're important. It's worth doing it right. So I just want to pass this along. And so, you know, who am I? What cred do I have with you guys, right? So I've been a kernel developer, a Java programmer, a cluster programmer and architect. So before I became a manager, I used to do some real work. So, but not only that, but I've seen, you know, I don't claim to be a rock star myself. But I've had the privilege of working with a lot of them. And there's some rock stars in this room. And so, you know, just like open source, it's like pass it on. Maybe you can learn from what others are doing and, you know, and build on that. So that's the whole point of this talk. So, first slide. A lot of people think that it's their manager's job to tell them what to do, what their career should be and every step they should make. But, you know, honestly, your managers do want to help, but nobody should care more about you and your career than yourself, right? And so, a lot of people think that, you know, you take a job and, you know, you might read a job description. That job was not written just for you, right? Because everyone's different, everyone brings different strengths to the job. And so the first thing I want to say is that one thing you can do when you take a job is to tailor the role. So by tailor I mean tweak it, not just like say, hey, I took this job and I'm not doing any of that, right? It might be like, hey, there's some things that I'm good at that I can do. I can write auto tests. I can be good at adding documentation. I can improve the usability. I can integrate it with better with other components. So it's all about creativity. Add your own ideas to what your job is. The other thing is when it comes to your job, that's how people perceive you. That's how they view you. And so they view you through two main ways. One is your output, you know, whether it's your code, your documentation, your testing. It's really what you do. And that's important. But also your perception is really a lot based on your interaction style. Are you somebody that people like to work with? And that's what a lot of the other, the rest of these slides really talk about is more interaction style and what I find really makes a successful engineer. So in your job, it's important to care about what you do. So if you don't like what you're doing, then don't do it. Really, you're not doing anyone any favor. Like the worst thing is to have somebody miserable in their job. It's not good for the person doing it. It's not nobody wants to be with them. So care about what you do. And, you know, the fortunate thing in our industry, there's so much opportunity, there's so many different roles. You know, even at Red Hat, we have so many different products and stuff. If you don't like what you're doing, go on a different team. That's the cool thing. We all have, we all know what garbage in, garbage out means in computing, right? It's like you, you know, throw in crap for inputs and you'll get crap for outputs, right? Well, it's the same with your job. If you don't take, if you don't care, if you don't really put quality into it, you're not going to get quality out. And it's not just about, you know, the code. It's about your satisfaction, your enjoyment. And, you know, one thing I'll get back to later, it's not to get like too philosophical about it, but, you know, when it comes to liking what you do, like, it's really about the journey. It's like, you know, you're never done. It's, you know, you can always learn and grow. So you might as well enjoy what you're doing along the way. Now, next point is breath is an option to death. A lot of people think that the best way to be a rock star is to do one thing like your whole career or for a long time and just stick with that. And that's fine because, you know, that's one approach. Because keep in mind, like, these things are not, not everything works for everyone. So it's like pick and choose what works for you. But what some people often don't recognize is that breath or having expertise in a lot of different topics, that's really valuable too. Because there are, frankly, in our industry, it's harder to find people who have a lot of experience in different areas than people who are narrow. But to do something different, it takes some courage, right? You have to get out of your comfort zone. You have to be willing to do something different. And so it's, you have to be willing to stretch and grow. And growth isn't just technical skills. So it's not like, hey, I'm doing kernel device drivers today, and I'll do networking layer tomorrow. That's one form of technical growth. But true rock stars don't just grow technically, they grow in non-technical skills. So things like organizing a project or being good with support, and we'll get into those things. So it's not just the technical skills that make up a rock star. And when people move, I say it's not, it's often not a lateral movement. What a lateral move is, I mean, sometimes you could be like the authority or the expert in one topic or one subsystem. When you move over to a different team, you're probably not going to be the expert on that team. And so sometimes within a career, you have to go down to go up because the more you learn, the more you can grow. And so it may look like you're taking a step down. But when you add all those up, it's really like you're getting to higher and higher places as you go. Nobody likes trolls. So a lot of people think that, hey, I'm a tough guy, right? I'm going to be that guy on the mail list who just snipes at everything. And they think like, I'm awesome. My peers are really looking up to me because they think I'm standing up to everyone. You know what? You look like a jerk. You really do if you do that, right? So what's better, rock stars don't do that. What rock stars do is they're more problem solvers. So rather than saying, oh, that'll never work or that's stupid and stuff like that, they propose ideas. They say, okay, hey, that's a good approach you had. But how about if we tweaked it this way and stuff like that? So being a problem solver, that's what rock stars are all about. The other thing is trolls don't listen. All they do is they're output only devices. And so what you need to do is rock stars basically, it's almost like a tenant of open source. It's like you take stuff that already exists and you can build from it. And so that's what rock stars do is they're able to hear and listen to what others say, sort of start with their approach and augment and build on it. And to be a rock star, it's just as important how you say it than what you say. And often it's more important how you say it. Because a lot of people, when there's this a tendency on mail lists and stuff like that for people to be more abrasive or more terse and not really show respect for others. And so true rock stars really show respect for other people. And last point I have is avoid slamming groups. Sometimes people say like, oh, everyone on that team sucks. Don't trust any of them. They're all bad. That's not really helpful. Often I hear it as a manager. I'm usually in that category. Don't trust them. But the truth is anytime you're slamming a whole group it probably means you're being a troll. Because seriously, not all groups are super awesome but there's good people in all teams. Next point is human touch. So as geeks it's really easy to do everything online. IRC, email, whatever, Twitter, all this stuff. But what we find is seriously you can get so much more done sometimes by doing it the old fashioned way, talking to people, picking up the phone, going to conferences like we are right now. Dev Comp is an awesome example because people often say it's the hallway track that's the best. Not the presentations but just getting to talk to other people. So that stuff is more valuable because you may not realize it whether you go to the Staro Bruno brewery thing and stuff like that, that party. It's just you're establishing bonds and connections with people that you don't even realize it at the time. But trust me it really means a lot and makes you much more effective. So rock stars tend to be more social, I guess is a word to put it. They're not completely introverts. Another point is you don't always have to get in the last word. I see this often with people who are more junior in their career. So you're on a mail list. It's like somebody does a reply and you always have to have the last reply. So you just keep going and going and going and it never stops. Sometimes it's better just to let things flame out or to if you don't have anything constructive to say, don't feel like you have to get in there and just keep twisting the screws on it. Because a lot of it's really talk with people inside, try to get them to a common understanding and just be willing to say that you don't have to win all the time. Because it's really about it's not if you can talk with somebody on the side or in other ways and help shape their ideas, it's often more successful to indirectly get your points across. Teams are better than individuals. Teams get much more done than individuals. That's often the term rock star. You think of one person up on the stage, a solo performance. That's why I think rock stars is a little bit of a misnomer. Whereas I think it's more like a soccer team or a football team. That's a better analogy. It's clear that the smartest team of collaborative people can do much more than one smart guy or one smart woman. Rock stars are good at working together with other people. In that sense, it's not win or take all. It's not one person has to win and someone has to lose. It's really about how do we work together as a team. Another point is sharing, mentoring and growing. Some people think in their careers that their best strategy is to be the only guy who knows something. It's like, hey, I'm the only one who knows the subsystem. They can't fire me. I call that like a monopolist, someone who has to hold all the toys. Someone like that never becomes a rock star because they never get out of that toy box. They never play on a team on a bigger field. If you want to be a rock star, you're going to share your toys. That's the point. Walking the walk. You can't expect more from others than you're willing to do yourself. If you're nasty to people on the mail list, people aren't going to be good to you in return. If you don't try to do things like, if you're the first one to leave at the day, if you're not working very much, then you can't, if you're any form of team leader or something like that, you have to be willing to help other people on your team out in other ways, like whether it's, I don't know, help to test or try stuff out, review the documentation, see if you can follow the steps and get these things to work. But also as part of walking is that people are not the same. People come into projects with different skills. There are some people who are awesome at testing. There are some people who are better at documentation. There are people who are better about community building and stuff like that. So walking the walk means that treating people with respect, be willing to work hard and set a good example, and to recognize that people bring different talents. And open source would not be successful without different talents. Whether it's people doing storage or people doing middleware and stuff like that, that's the reason it's succeeding. It's because people walking together. Rock stars are always customer focused. So some people think that the customer is the enemy. Like you hear like, man, my job would be so much easier if these customers weren't submitting these stupid bug reports or stuff like that. But as far as I'm concerned, developing software and delivering products, something is only useful if people use it. I think Linux, open source, hugely successful, used by millions of people, millions of varieties of applications. That's awesome. So if you just code stuff and nobody uses it, as far as I'm concerned, it doesn't exist. That's an academic exercise. So for customer focus, first thing is install and run your code. I know people who are sometimes, they do like this one small component that's part of a bigger application. And they'll say, but they don't even know how to install and run their product. Because all they can do is their own little tiny piece. And so rock stars have an appreciation for how easy is it to install your stuff? How easy is it to use it? They have a sense of they talk with the support team to understand what are the inputs they're getting from the customers. Support teams add valuable experiences in terms of how this stuff is received or what the customer experiences is. So it's extremely important. And as part of that, in order to prepare your code that works in the first place, is that developing automated unit tests are a core part of developer's job. So in the old days, in the bad old days, people would think, hey, I'm a developer. I'm going to throw it over the wall. The guys in QE are going to write the test and it's all going to be awesome. But that separation just doesn't work. Now, fortunately these days, we have much more collaboration between QE and the developers. But rock stars are people and teams who develop automated unit tests that do like CI testing up front. So don't think that automated unit tests are not part of your job because they are. And that's what it takes to be a rock star. Managers don't have magic wand. So people come to me all the time and say, hey, I need twice as much travel budget and I need to hire twice as many people. And it's like, yeah, awesome. Everybody does. And so you've got to recognize that we don't have infinite budget. So we have finite constraints that we have to deal with. But that doesn't mean don't ever talk to your managers. That's not the point because managers like to talk to people and get that input of what's going well and what's not. But instead of coming to your manager with demand, come to your manager with ideas, it might be like, hey, I know we've got a lot of stuff going on. There's too much. I can't get all this done. Is it all right if we focus our priorities on this stuff here and we do less of that stuff? So that's an idea of like a trade off proposal. That's the type of thing that work well to discuss with managers. Also, phased approaches. It might be like, look, you can't do everything all at once. So just talk about, OK, let's start with this. This will be phase one. Then we'll do phase two later. So it's really about coming up with ideas and being creative as opposed to just trying to dump your problems in somebody else's lap. And raise issues early. So honestly, managers want to like to find out about problems in like the release early rather than often. People often say, oh, at the end, when we're doing the code freeze, someone will say, oh, well, we're way behind on it. And it's like, well, did you know that a month ago? Yeah, we knew that a month ago. So bring it up because that allows your managers to help maybe shift some more people on to help that, the trouble spots and things like that. Rock stars are, it's amazing how much more productive some people can be than others. Seriously, there are like, I put up here that productive people can be three times more productive than the average person. I think that's, I think it's, it could even be more than that. So, you know, true rock stars, it's just amazing what they can get accomplished. And there are rock stars in every discipline. So rock stars are not just coders. There's rock stars in program managers who like coordinate things, people like scrum masters. There's, there's rock stars in support. So these principles can be applied to anybody in any event. And one thing I've found is that leadership and coordination is one of the hardest to find talents in, in our industry. So some, so what I would encourage there is for career advancement, like you don't have to go to the dark side and become a manager. That's not completely necessary. But there's a lot of opportunities for like technical leads. It might say, hey, let's, someone, you'll start within the development team coordinating the efforts or working with like two or three other people to, to get something bigger done. Or you might, another way is to join, to go to meetings for another team. Like say there's other layers that call your, your software. So become familiar with what those other teams do. And those are examples of, of leadership. So don't be afraid to, to try and get out that because I'm telling you, it's always a scare skill. So it's always going to be in demand for people who can, who can do that in a cooperative way. And so rock stars typically are people who combine most of the attributes within this, within this presentation. So the last one I'll put, last of the 10 things before I get to summary is what I call the career unicorn. And that is, it's the difference between a job and a passion. So if you can find a job where it's not, you're not just punching the clock. You're not just doing it to pay the mortgage or, or your student loans or your car bills. But it's something you really want to do. That's really special. And I think that open source provides us all a really unique opportunity to try to lend a unicorn job. So take for example, you know, people work in Linux, open source. It's used in so many different ways. There's whether it was, you know, things like the one laptop per child initiative that was trying to get computers to low income people in countries, you know, there's a lot of what we do. It's more than just, we're not just selling stuff, right? We're making, we're transforming the industry. We're making a lot of things happen beyond just our company. Of course, you know, you want to contribute to your company. You want to align your efforts with your company. But open source is a truly unique way to do so much more than that. And that's why I think, you know, we're really in a unique profession because it's not just a job. So in summary, there's, there's no one right answer for everyone. It's not like, do this, do this, do that. And then you'll be a rock star because there's different rock stars and different ways to get there. But what this shows is that rock stars typically like what they do. They care. They bring passion to their job. So they're not doing garbage in. They're, they're putting passion in. You put passion in and you get rock star out. That's really how it goes. Rock stars are team players. They're not trolls. They don't just snipe. They really propose good alternatives, good solutions. And they have the courage to grow, to step out of their comfort zone, to try something different, to help out other people. And rock stars, they can, through their examples, they can truly be inspirational to others. And the thing is that most people think, oh, I'm not a rock star. I can't do that. So all this stuff doesn't apply to me. But the thing is, people can. It's like, it's easy to not think that you have what it takes to get there. But really all it takes is playing well with others, growing, respecting other people, and trying to challenge yourself in new dimensions. So to wrap up, it's really your journey. I'm old. Marco reviewed the slide. He says, Tim, you're old. So this really points it out that what I learned is that, you know, I've been in this business over 30 years, and it's a long time. But it goes by really quickly when you enjoy it. And the way you enjoy it is by bringing passion to your work and being part of a strong team. And so open source is a great way to do that. And so I hope you do it well. It's hard. It takes constant effort. You're never done. But it's well worth the ride. So do it well. Thank you.