 I realize I'm the only thing standing between you and lunch, so, but if you have questions, more room for questions. Okay, so today is about leveraging procedural knowledge, which is three really long words to say how to learn. And so don't be intimidated by that part if you're a noob, because everyone's actually a noob. I promise. That's something. We're going to talk about procedural knowledge. Sometimes how to implement that first you're going to know thyself by getting to know me. We're going to drink from the fire hose, return to our roots, talk about a Django girls workshop, and talk about next steps. Okay, so procedural knowledge is actually better defined, better understood by understanding declarative knowledge. Procedural knowledge is Amsterdam is the capital of the Netherlands, J is the 10th letter of the ISO Latin alphabet. It's really hot outside because we're in Texas, and I'm melting because I'm from the Netherlands. That's declarative. Procedural is how you ride the bike, how you drive your car, how you train for a marathon, which I've never done, how you learn, how you do. So it's facts versus process. So why does that matter? Well, there are two schools of thought. One is that in order to learn something new, you learn the facts, and then you practice and practice and practice and practice and practice until it becomes procedural knowledge. You don't even need to think about it anymore, and you don't even maybe remember how you learned that fact, and that's totally valid. The other school of thought is that you learn something, and then when you want to learn something new, you remember the environment where you learned that maybe there was some white noise, but it's a quiet room with all the curtains blocked out, and therefore you want to learn something new. So you recreate that environment, and you learn something else, and it's learned more efficiently that way because that's how you learn something else, and your brain goes, I'm learning something. Okay, focus. So the first step to procedural knowledge is to actually know yourself. And oh, hi Sasha. I am a 10-month-old, a mother of a 10-month-old, who is right there. And you can say hello later or not. I first programmed on a TI-994A computer, which maybe you remember, and maybe you have no idea what I'm talking about, and that makes me feel old. But I learned basic on the manual that came with that computer. And the only thing you could do was follow the rules. That was it. There was no hacking. There was following the rules or it doing nothing. You couldn't even take it apart and put it back together and do something new. It was that or nothing. And so I learned how I learned. I practiced, and I read, and then I did. And I found that if I just read the manual and then put it down, that it completely was gone. So I realized I had to go, uh-huh, okay, uh-huh, okay. So when I self-taught myself HTML and CSS and PHP and JavaScript back when I was a developer for the web, I did. I built a website. It was on Angel Fire. I know I'm dating myself. Please don't judge. It's important for you to know how you learn, not necessarily linguistics or languages, but how you learn and what you're comfortable with. Cuz that's what you'll use to apply and learn new things. I like logic puzzles. I like math. And therefore, every time I learn a new language, I pick out relationships. And that may not work for you. And if you ask the question at the end, who are you? To me, I'll be like, I don't know. And I'll probably make up something. Just like, hate it. You might be a surgeon too. So I work for Red Hat. This is actually a Red Hat because the Fedora doesn't travel well internationally. So I took this cuz it crushes up and goes in the suitcase really easily. I started out as a technical support engineer. And six years ago, when I started, hi. You had to pass the RHCE within 90 days, you got three chances, or you were fired. And that's a lot of stress, no pressure. I wanna tell you a little bit about the US Air Force military boot camp versus Red Hat's boot camp. I know it doesn't seem related, but it is. Give me a second. I know lunch is calling. Give me a second. So the US military boot camp for the United States Air Force is you go to Lackland Air Force Base, and it's about six weeks, and you exercise a hell of a lot. You run like crazy, you get a lot of orders, you change clothes a bunch, you get your hair shaved off. It seems like hell, if you're there maybe. You're sleep deprived, you learn a lot of rules. And it seems like the purpose of it is to get you in shape, and teach you how to use a gun maybe, and maybe learn those basic skills. But the actual underlying reason for that boot camp is so that when someone tells you to jump, you jump. You don't even ask how high, you just jump. That's the underlying. So then we get to Red Hat, and I promise there's no sleep deprivation, well, there is sleep deprivation. But there's no running, definitely. And it's 90 days, it's actually 30 days, and then you get three chances. And the obvious is that you're learning to pass the RHCE. Yay, and not get fired, woo! But the underlying is that every time you answer that phone, you will have no idea what they're talking about. None, and you have to completely stay calm. What are you trying to do? How are you trying to do it? What's happening? What do you want to happen? Stay calm, gather the information, and then hang up the phone, and learn whatever they're talking about in a very short period of time. And that's what Red Hat Boot Camp is. So there are two layers to things, and you basically have to drink from the fire hose. And that's what I did. Procedural knowledge, I started taking the logic. I personally need a white noise generator, lots of quiet outside of that darkened room, and logic between commands line words. And I passed. Yay! After the second try. So I did that for six years. I was a technical support engineer, and I got promoted and stuff, and then I moved to the Netherlands. I became a technical account manager, and while you're doing that, you're constantly having to learn lots and lots of information really fast, and I went, okay, that's great, but I need a break. And then I gave birth to that guy, the 10 month old, not like that guy in the front, the 10 month old. And in the Netherlands, you're allowed to scale back at work and go to part time, but you can't be a part time technical account manager, so my job became to look for a new job, hopefully within Red Hat. So I started taking workshops, and the very first workshop I took was Django Girls, up in Groningen, which is where I live. Groningen, if you're American, this place. And I loved it. Preparation, again, was using procedural knowledge. It was using Git, which I had lots and lots of experience from this guy. It was using troubleshooting, lots of Google, and I remembered how much I loved web developments, and I went, why am I not programming anymore? Well, I don't have time. Well, I have time. Okay. So I put up a app on Heroku app.com, which I'm very tempted to upload to the Microsoft Azure site. Red Hat. After the workshop, I did the tutorial extensions, which you can get there. I uploaded it on OpenShift. I would give you the link, except I've torn it down and put it back up and torn it down and just hacked away. You can get your own free hosting there and make a lot of ugly mistakes. I highly recommend it. And then, next steps. So your next steps might be when you're learning a new language, especially with Django. They changed the tutorial so that now it goes on to Python anywhere, and you might do that. You might practice, practice, practice, practice if that's what you need. I highly recommend you do community contribution. Even if you're not coding, you can always contribute to the documentation, and it's usually the same process as submitting a patch, and therefore, you've warned a procedure that once you use code will be easy to implement. Build an app, break stuff, and then for me, I'm going to go back to Chronigan and be a coach on September 19th, and I promise I won't be too sleep deprived from the fly. So what's really next, actually, is that I'm not coding in Django at all anymore. Hi, woo! I went from being a Django girl's workshop participant to a Red Hat software engineer in five months because I drank from the fire hose, approved myself, and then I ended up getting hired to a different section of Red Hat that doesn't use Django at all. They just care that I know how to learn. And so they don't care that I learned, they don't care the language, the Python and Django, and actually I learned some Rails. They care that I learn fast, and that's what a lot of people care about. Can you learn fast? And then I know myself and therefore I know how to learn fast. So now I code on OpenStack. And by code on, I mean I contribute to the community because I just started on July 6th, so I'm still just helping with the docs. I'm doing a lot of reading and ramping up. And that is how I used procedural knowledge to get from the workshop to Red Hat Software Engineer. And now you came too. Do you have any questions? Or would you like to go to lunch? So back in the day, companies were totally into this idea of having knowledge bases, and one company I worked for had a chief knowledge officer whose duties were somewhat ill-defined, and all that kind of stuff. But the idea seems very sound. What do you think of having company-wide or group-wide or organization-wide systems for organizing all this shared intuitive group knowledge that people are otherwise just keeping locked in their heads? Right, we do that actually. And by we, I mean Red Hat in the support side. And we're starting to integrate engineering. Actually, a lot of people on the support side were like, you're going to engineering? Let's implement KBases. We have SBRs, which are specially based routing. So if I get that call and it's about cluster and I have no experience with cluster, I get all the information, I stay calm, I learn the basics so that I know what questions to ask the people that actually do know about cluster. My specialty is satellite. So when I have, when I'm not answering the phone, I then go over and help people that don't have any experience with satellite answer their questions. So we do that, and I highly recommend it. I actually think that's part of what open source is all about, is here's my knowledge. Play with it. We have time for other, we have time for other questions. The microphone can come to you if you'd prefer not to come to the microphone. Don't be scared. Okay. Oh, well. Hi, thanks for the awesome talk. I was just going to ask following on from the first question. Do you think there's, or how much value do you think there is to knowledge bases that are kind of descriptive versus maybe kind of tutorials and things that people can work through? And like, which would you recommend or do you think there needs to be a mix of both? I say both actually, and we have both. We use both. There are people that come on and they're like, I need something very, very specific. I need to know how to set up a role environment with a cluster using VMs and something very, very specific. And those might need a person to give the final act on, but we have something to get you close. And then we have tutorials and interactives that people never need to come call us because it's all the information's there. And I strongly, I passionately feel that if the knowledge is there, then you can self-help and that actually that's more important to teach people, which is what this talk about is about actually, I can teach you something all day long, but you won't digest it until you actually teach yourself and practice or whatever you need. But if I, I can talk all day, but it won't stick. So yeah, both, short answer. Anyone else? So to build on that same question and your answer may be too proprietary and maybe the audience can help too, but my team struggles with how best to share that knowledge with each other and with our future selves and the tools we've chosen over time are varying. And so does, what advice do you have for how best to share the tutorials, the lessons learned, the instruction manuals and not even specific documentation for an application, but as a team, business rules that change over time? Yeah, yeah, yeah. So when I first started with Red Hat, we were very like all over, like we, the information and it still is, I will be completely honest on the backend and the tooling, there's like a million ways and it's kind of ugly to share information, but you have to have a really good search that can network with all of them. And that helps and the other thing that we did was we built a portal that was a central location where customers and employees could both go and depending on your permission, of course, you would be able to dive into more or less information. So a customer we wouldn't want to give a raw issue that we're working on that has other customers private information on, but if there was another employee searching for that same problem, we would want them to see that raw information because that might solve their problem and therefore they can help solve this problem. So it's double. I would highly recommend an integrated search and then like integrating all your tools into one portal, for example, is what we did. There might be other solutions. I'm sure there are, but that's what we did. Thank you. You're welcome. This is my Twitter handle if you have any comments, questions, snide remarks, please feel free to shoot them out over the Twitter fear and I will respond. Thank you very much. Thank you.