Leveraging Procedural Knowledge by K Rain Leander

Speaker 1: Um I realize I'm the only thing standing between you and lunch, so I'm gonna talk fast. 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. At something. We're going to talk about procedural knowledge and 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.

Speaker 1: Okay, so procedural knowledge is actually better defined, better understood by understanding declarative knowledge. Declarative knowledge is Amsterdam is the capital of the Netherlands. J is the tenth 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.

Speaker 1: 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 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 blacked out, and therefore you want to learn something new.

Speaker 1: 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, oh, I'm learning something. Okay. Focus. So the first step to procedural knowledge is to actually know yourself. And I'll Hi Sasha. I am a 10-month-old uh a mother of a 10-month-old who is right there. And you can say hello later or not. Um I first programmed on a TI-994A computer, which maybe you remember and maybe you have no idea what I'm talking about.

Speaker 1: 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 I it completely was gone. So I I realized I had to go, uh-huh. Okay. Uh-huh. Okay. So when I self-taught myself HTML and CSS

Speaker 1: and PHP and JavaScript back when I was a developer for the webs, 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, because 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.

Speaker 1: And I'll probably make up something, just like he did. 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 because 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 want to tell you a little bit about the US Air Force military boot camp versus Red Hat's boot camp.

Speaker 1: 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.

Speaker 1: 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 there's no running, definitely. And it's 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?

Speaker 1: 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 Bootcamp is. So there are two layers to things, and you basically I 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 command slime uh words and I passed. Yay after the second try.

Speaker 1: 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, 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 inhale. 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 Uh 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

Speaker 1: 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. Uh 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 now. Okay. So I put up a app on Heroku. app. com which I'm very tempted to upload to the Microsoft Azure

Speaker 1: site. Red Hat Microsoft. 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 and then Next steps. So your next steps might be when you're learning a new language, especially with Django. They changed the tutorial work tutorial so that now it goes on to Python

Speaker 1: 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 learned 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 Krnigan and be a coach on September 19th. And I promise I won't be too sleep-deprived from the flights So what's really next actually is that I'm not coding in Django at all anymore.

Speaker 1: Hi, woo! I went from being a Django Girls Workshop participant to a Red Hat software engineer in uh 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 cared that I know how to learn And so they don't care that I learn they don't care the language, the Python and Django and 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 codon, I mean I contribute to the community

Speaker 1: because I just started on July 6th, so I'm still just helping with the docs and 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 can too. Do you have any questions, or would you like to go to lunch?

Speaker 2: So back in the day, um the um 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. So th 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 In intuitive group knowledge that people are otherwise just keeping locked in their heads.

Speaker 1: 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 K-basis. 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 satellites, so when I have When I'm not answering a phone, I then go over and help people that don't have any experience with satellite answer their questions So we we do that and I highly recommend it.

Speaker 1: I actually think that's part of what open source is all about is here's my knowledge, play with it. Go and

Speaker 2: 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.

Speaker 1: Don't be scared.

Speaker 2: Okay. Oh well.

Speaker 3: Hi, thanks for the awesome talk. Um I was just gonna ask following on from the first question, do you think there's or how much value do you think there is to Um 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?

Speaker 1: 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 acon, 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 I strongly um I s I passionately feel that if the 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

Speaker 1: 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.

Speaker 2: Anyone else?

Speaker 4: So to build on that same question and 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 and the tools we've chosen over time are are varying and and and so does uh what advice do you have for how best to share the tutorials, the lessons learned, the instruction manuals, and and not even specific documentation for an application, but as a team, business rules that change over time. Yeah.

Speaker 1: 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 back end. 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

Speaker 1: 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 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.

Speaker 4: Thank you.

Speaker 1: 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. Uh thank you very much.

Speaker 2: Thank you.