CORALINE:  Hello and welcome to Episode 102 of Greater Than Code. My name is Coraline Ada Ehmke. I'm joined today with my dear friend, John Sawers.

JOHN:  Thanks, Coraline and I am here with Janelle Klein.

JANELLE:  Thanks, John and I am here with my fabulous co-host, Sam Livingston-Gray. I do love saying your name.

SAM:  Why, thank you. I do love hearing it. Hello, Janelle and hello listeners. I am super thrilled to be able to introduce Katrina Owen. Katrina is an ecosystem engineer at GitHub. She accidentally became a developer while pursuing a degree in molecular biology. When programming, her focus is on automation, workflow optimization and refactoring. She works primarily in Go and Ruby, contributes to several open source projects and is the creator of the amazing Exercism.io, which is a platform for code practice and programming mentorship.

Katrina, welcome to the show.

KATRINA:  Thank you. I’m so happy to be here.

SAM:  Or perhaps, I should say, welcome back to the show because you were with us back on Episode 8.

KATRINA:  That's been a while.

SAM:  It really has.

CORALINE:  That's like over 50 episodes ago, right? My math isn't great.

KATRINA:  Your math could use some work. Yeah, that's right.

SAM:  Wait, but I thought you had to be good at math to be a programmer. Unnecessary arithmetic.

As you probably remember from last time, Katrina, we like to start by asking everybody what is your superpower and how did you acquire it? And I actually don't remember the answer that you gave, so you can just surprise us all with whatever you like.

KATRINA:  I also don't remember the answer that I gave, so here we go again. You know, I pack a mean dishwasher. I think that's probably my greatest skill. It does, to be fair, also spill over into other parts of my life like I'm really, really good at organizing and systematizing. I think systematizing is probably the best word.

CORALINE:  Is that something you've always been good at or was that a learned skill?

KATRINA:  I'm pretty sure it's a learned skill but I think I started learning pretty early. No, no, tell a lie. We didn't have a dishwasher until I was an adult but I pack a mean suitcase, trunks of vehicles as well. I do pretty well with this.

CORALINE:  And you were a world renowned Tetris player, ranked fifth in the world from what I understand.

KATRINA:  Don't we wish? Yeah, I didn't actually have a computer games, either.

CORALINE:  You're on your way to becoming a molecular biologist and you actually became a software developer?

KATRINA:  Yeah. I kind of got into the whole university thing a bit late. When I was about 25, I realized that my life was probably over. I was a loser, I had gotten nowhere, there was no hope for me, all of those things. I guess, mid-life crisis, if you aren't going to live very long. I decided that I needed a plan that was better than what I had. I like science and so, I figured since there is no hope for me, I could at least just become like a mediocre scientist and that would probably be decent and fun. But I didn't have enough high school to actually get accepted to university so I spent the next two years learning math and physics and chemistry so that I could apply to some university programs.

I did that, applied to several, got accepted to two. I was interested in both of them. One of them was airspace engineering and the other was genetics. I ended up in the genetics, kind of on a coin flip. By that time, I was about 27 and when I started university, I got my first computer. At that point, I started playing around.

SAM:  I love how that illustrates that you don't have to have grown up with computers in your crib to become a good developer. You don't have to have started with programming basic at age eight and so on.

KATRINA:  Yeah. I felt really intimidated by all these programmers who knew how to program before they knew how to like, tie their shoe laces or whatever. I had conversations with friends of mine who said, "I don't ever remember a time when I didn't know how to program." It seemed like I would never catch up and it turns out you don't have to catch up for one. Tech changes all the time and so, there's always something new to learn and so, you kind of just forge your own path.

The other thing is that most people, when they're four, five, six, eight, 12, they're not actually practicing programming deliberately. They're just kind of messing around and so, by the time we're all in our 20s, 30s, 40s, it seems like those early years weren't actually necessarily relevant.

CORALINE:  I remember being at a conference once and someone was talking about the importance of how you tell your story, about how you got started with programming and the path to software development via computer science is pretty well understood. You get to college, you get a degree, you get a job. But for the people who say they're self-taught, that can kind of deadened the conversation because people who are self-taught typically don't talk about the process that they went through. They don't lay out a roadmap for other people to follow. If someone is going to take the self-taught route, they may not know where to start. They may not know what practices are effective, what practices they should avoid. I think there is an importance to telling the story of how people got into software development who did come from a nontraditional background. So exactly, what were those early years with computers like for you?

KATRINA:  The first thing that I did, I think that had anything to do with programming... Oh, my goodness, this is even before I had a computer. I was a bilingual secretary for several years in France and I got really annoyed with all of my bosses who would send me Excel spreadsheets and ask for the same type of data every week. I bought books about MS... What is that Microsoft SQL database thingy?

CORALINE and SAM:  Access.

KATRINA:  That's the one. I bought books about that and I wrote an app for them in Access, where they could import the Excel spreadsheets and then, get their own data. That was super fun. I even made a UI, which was probably the first indication that I should never do that. That was fun.

When I did get my first computer, the first thing I did was put Linux on it because that sounded cool and then, I started playing around in Bash like renaming MP3 files and a script in a loop and stuff like that. In my first year of university, I had a calculus course, where one of the things we had to do was programming in Mathematica and that was kind of the best thing ever. It got to the point where they had to kick me out of the computer lab at night because I wouldn't leave. I think that's the first time that I really felt like this was something that I got sucked into, that it hit all those high points, the high notes of making me feel good about myself, of falling into flow, of solving puzzles.

I remember the day I discovered floating point problems because I wrote a program and it was supposed to come up with all zeroes and I had this page full of this massive list of 0.0000 bullshit crap stuff and I had no idea what was going on. I went to the professor and was introduced to this super fascinating idea of why floating point arithmetic is really complicated. I think those were the first steps and then, the web was already a thing, so I started playing with HTML and PHP and all those things. I think the path from playing to working was that friends of mine would ask for help and I would be able to help them and then they started paying me to do it.

CORALINE:  It's very similar for me, where I actually tried to get a CS degree and after one class, I ended up dropping out and thinking that programming as a profession would not be for me but I kept packing on side things and in 1994, the company I was working for, I knew all of the geeks there. We would hang out and have cigarettes and one of them came to me one day and said the company is going to build a website and I was like, "Oh, that's so cool." They were like, "What do you think that's going to do for your career?" and that was my first programming job.

It's interesting how we can kind of fall into these things just by following our interests and following our love for solving puzzles or whatever it is. Tech gets you curious about cracking open an editor for the very first time. I don't have an accessory but we used FileMaker, which was an Apple competitor to Access. I did some similar things. I was working in media relations and I built a system for tracking press releases. It's interesting how just trying to solve a business problem often leads us to writing a program to solve a business problem and that really doesn't change very much once you're established in this field, does it?

JOHN:  Not at all. I think you pulled out an interesting point there about discovering that thing that gets you into the flow and that really gets you that, for the lack of a better word, dopamine hit when you get the thing to work that time and then you could keep going back for that. I think one of the things that if you can get to that point, it makes programming really sticky because you can continue to search for that state and find it. It took me a long time before I actually got to that and I didn't take programming very seriously until I hit that point. Then I was like, "Now, I'm going to keep doing this."

KATRINA:  One of the things I've been thinking about a lot lately is how a lot of people talk about how you have to be motivated to do something and I think it's actually the inverse. I've been reading a little bit about some of the scientific discoveries behind motivation and the key thing is that you are motivated by success, not the inverse. The size of the success is kind of irrelevant, which means that if you design something to have lots of tiny wins, you will help people remain motivated and have that motivation grow.

CORALINE:  That's one of the reasons, for the people that I mentor, I often suggest Pomodoro’s because a Pomodoro, not only does it help you by breaking a problem down in a small chunks but it also gives you that feeling of checking something off after you're 15 or 20 minutes in accumulating those small wins that makes a lot of sense to me.

KATRINA:  It's also one of the reasons we had lots of very tiny exercises on Exercism.

CORALINE:  Yeah, it makes a lot of sense.

JOHN:  There's a book called 'The Progress Principle' that I actually used to build a talk earlier in the year about how one of the sources of satisfaction with work is progress on meaningful tasks. If you can keep that progress in mind, if you cannot forget about all the progress you've been making, your work becomes far, far more rewarding and more satisfying and it's that same thing where you keep that like, "Oh, I actually did get something done today," even if I forget about it tomorrow, if you write that down and remember it, then you feel like you're making that progress and it makes everything much more meaningful.

KATRINA:  I actually do this at work right now. I write AST parsers, so I use static analysis to figure out how many things I have to fix and then, I write a script that will output that in a mark down table, so that I can paste it into my tracking issue every couple of days. Then, every two or three days, I will run my static analysis script against master and post the new stats. It's amazing how motivating that is.

CORALINE:  I think journaling can kind of make you feel better about that sort of thing too. I used a system that I developed which is just a bunch of text files and folders organized in a certain way. Sometimes, it's Thursday or Friday and I feel like I haven't accomplished much of that week, so looking back on my journal and I’m like, "Oh, this system that I've been working on didn't have feature X on Monday and by Tuesday, it did." Sometimes, we need reminders that yes, we're for making progress and yes, we've been making things better and no, we haven't been wasting our employer's time.

JOHN:  Yes, indeed.

SAM:  Yeah, I was actually just typing into the chat that I was noticing a pattern in all of these examples of getting frequent feedback like Pomodoro’s give you a chance every 25 minutes to reflect on whether or not you did what you intended to do. Coraline, you were talking about using that as a way to rack up wins but I also was thinking of it as a way to recognize that perhaps, you went down a rabbit hole for the past 20 minutes and that's an opportunity to stop and notice that and adjust. In any event, the feedback seems to be pretty important part of that.

JANELLE:  I feel like it's more than that. When we started this conversation and going down into this track of this falling in love with puzzles and getting curious and obsessed and being able to lock into that sticky high of flow and how amazing that experience is and then, the reverse has happened and that we're motivated by success. I started thinking about this in context of cognitive science and I'm thinking, "We're motivated by history," and the history of our experiences projected through what we're experiencing in a moment of right now is the resulting feels that we get from the response to whatever's in front of us.

That initial action that you want to take, maybe in dissonance with the way that you feel about it and you may have to you know, 5-Second Rule or five, four, three, two, one, just count down and go. I'm going to override and do the thing but then, once you have a good experience, once you have history with success, then you can kind of lock into that wheel and then, these short feedback loops, I'm thinking you create a cumulative, positive reinforcement loop by adding more and more experiences rapidly to that flow wheel.

CORALINE:  Janelle, what's the 5-Second Rule?

JANELLE:  My sister actually had me listened to... I'll have to look up the reference but it was the short video on the 5-Second Rule and essentially, the challenge of motivation of I've got to exercise. I've got to do one of these things that I just don't want to do but I know I need to do it anyway. I know it's good for me. I have this vision, outcome, dream in my head that I want to achieve but trying to make myself do that when I don't feel like it is hard. Essentially, you've got about five seconds in order to switch from having a dream in your head to taking action on that thing before your body induces this sort of anxiety avoidance response toward that thing.

Then once you confirm the avoidance, once you procrastinate and hit the snooze button and not going to get up, you reinforce that anxiety avoidance. Like your brain is like, "Oh, I avoided that. I survived. Awesome. We succeeded here," and you've got about five seconds to overwrite that before your alternate response triggers. It was a simple habit rule of you want to do something, you want to get up instead of hitting the snooze button, you pretend you're in NASA and you start counting down: five, four, three, two, one and then you do the thing. You just get up and do the thing and it's that last possible moment that you create for yourself to help motivate yourself, to create that first success.

KATRINA:  I actually came across the 5-Second Rule when I was trying to figure out some of my struggles with procrastination. Specifically, there were like a five-minute video about procrastination by the woman who came up with the 5-Second Rule. She said that procrastination is not about willpower. It's about ambiguity and that this ambiguity, this lack of knowing exactly how to proceed creates this massive barrier to actually getting anything done. Her recommendation was do the 5-4-3-2-1-go and then, just spend five minutes on it. You don't have to do more, just spend those five minutes and doing whatever that might even be relevant to the thing that you're procrastinating on. Often, that will give you just enough insight into what was ambiguous, what do you actually need to figure out to make progress. It's super interesting.

JOHN:  Yeah, not knowing the next step is such an impediment. It just feels like it's impossible to get started at that point. One of the things I've used in the past is spending the time when I have high motivation and high cognitive ability, lots of willpower is spending the time breaking the task into smaller things so that the next action is really clear, so that then when it comes to actually doing the thing, that step is a smaller step.

KATRINA:  That's really interesting. I've heard another variation on this, where if you have high motivation, spend that motivation on making a system that you can use when you don't have motivation.

SAM:  That's good. One variation on this that I use, not intentionally, this is just something I stumbled into is leaving a failing test at the end of the day so that when I come back the next day, I have a single thing to focus my attention. Otherwise, I just sit there going, "Ehhh--"

JOHN:  This may be apocryphal but I think Michelangelo had a technique where he would, at the end of the day, just take the chisel on the sculpture and whack somewhere so there was a flaw that he would immediately have to focus on the next day.

CORALINE:  That's the reason that bugs make it in your production code.

SAM:  Yes, because we're all artists.

CORALINE:  Take a chisel to that complicated method and chip it. Katrina, out of this conversation about motivation, how does that tie in to the way you designed Exercism? Has any of it sort of influence?

KATRINA:  Yeah. A couple of years ago, I realized that Exercism was either going to die or I had to bring other people in to help me think about it in terms of a product and I brought in an amazing team. Jeremy Walker from the UK and his team at Thalamus. They came in with an enormous amount of product expertise and what we did was we spent the next eight months asking questions. We asked questions like, "At what point during learning you're most vulnerable? What is motivation? How does motivation work?"

We stumbled across a bunch of research around, not just the fact that success causes motivation or creates motivation but also, various aspects that go into motivation, such as what people value and that might be all sorts of things: you might value the process, you might value the social aspects of it, you might value the outcome, what it's going to give you when you're done, and the more different types of value you find in something the higher your natural intrinsic motivation will be.

Another part of this was there's evidence that anything that is the opposite of supportive, anything that is neutral to negative in terms of the environment means that you have to decide every single day to keep going. Whereas, anything that is supportive will let you avoid the impact on your decision fatigue, so a supportive environment is really important. Then, the third thing is what they call expectancies for success. You need to have a plan or see a plan. A plan exists to achieve success with this thing and then, that plan has to seem doable. You have to see all the steps, that all of those steps seem doable on their own and thirdly, you need to believe that you personally are capable of following those steps.

In terms of Exercism, we realize that a lot of the conversations that were happening on the site were not supportive. Random people giving feedback in a situation where you're really vulnerable is actually not ideal. We know this. The internet has proven this over and over but it was not something that we had thought through or that I had thought through, specifically in terms of what interactions will help support the learner.

We redesigned mentorship as the core feature on Exercism, where before it was just kind of accidental. Mentorship is something that happens between you and a mentor. People sign up to be a mentor, they sign the code of conduct, they're part of a mentor community where they can discuss and help each other figure out how to best give feedback or how to respond to something that might be difficult. Then, this conversation happens in private, so other people can't just parachute into your conversation and have opinions about the stuff that you're writing at the moment when you know the least possible about a new language. That really deeply affected the research into motivation and the importance of being supported and being protected in this vulnerable situation had a huge impact on the new design of Exercism.

CORALINE:  That reminds of me code reviews. I've definitely been in circumstances where and this is probably before GitHub put in place the requested reviewers. I've definitely been in places where I felt dogpiled by code reviews, especially early on at a given company where everyone has an opinion and I'm maybe, not doing things the canonical way for that organization. I did feel very vulnerable and the responses that I got were not helpful and just made me question the quality of my work, rather than showing me a path toward improving it or making it more canonical. Do you find that maybe, there's value in establishing those trusted relationships in terms of the people you requests for code reviews?

KATRINA:  Yeah. I think that code reviews are really tricky because they have so many layers and levels of feedback, where it's really hard to correctly set expectations for a code review. I'm on one of the code review rotations at GitHub for the API. We get dozens of PRs every week that we need to go through and we have some very specific criteria or standards for what we're looking for in an API like this is how we want APIs to be built. At GitHub, that's one thing but the most important thing for us is that we're not accidentally releasing breaking changes.

Our reviews are very, very meticulous in terms of looking at status codes, headers, payloads, etcetera, the types of things that you can't suddenly return a null if we never did that before because there are certain clients that don't handle that correctly. Some really interesting things that I've learned over the past year with respect to code review is that, I think you're right that a trust relationship, it's much easier to do a code review when you have a relationship of trust between the author and the reviewer. We received this enormous pull request a few months back that was adding new APIs, we had very many feelings. It was a really difficult review to do. We got in a group, hang out for two hours, four of us to go through it and figure out how to communicate the changes that we wanted and we failed at doing that well.

The author of the pull request felt, I think personally not attacked but felt like this was a problem we had with them personally in some way, like it felt personal. I don't know exactly but the outcome was that we were upset that our recommendations were being, I guess poo pod, is that a word? We felt like our recommendations that were coming from a place of we want the API to be the best possible thing, were not being listened to and they felt like we were requiring a million changes when they were in a hurry to get some feature out because of a deadline.

It just wasn't a good situation and it turned out that when we wrote our recommendations in a different way, it was like, "Oh," and they fixed it in an hour but the way that we had written these recommendations, we had provided all of the background context for why we think this is important, it looked like this massive change and it wasn't the right time to do that. They were in a hurry and they didn't need all that context they just needed to know what we needed them to change.

I think for code review, another thing is we talked about ambiguity motivation. I think that a thousand line pull request adds a lot of ambiguity to the review process, like what am I supposed to be looking at? Where am I supposed to begin? What are we actually reviewing for? If I review just the API, is there someone else going to properly review all of the other parts?

One of the recommendations that I'm working on at GitHub to propose to the engineering manager is to recommend to people make much smaller pull requests than has been with the tradition at GitHub. There's a ton of research that says that anything over 300 lines, you're not going to catch the errors, you're not going to look at it in detail and also, it's going to take a lot longer for someone to even start looking at that pull request. If it's a thousand lines, we're going to go do all the short ones first and so, if you're in a hurry, figuring out how to carve a really tiny piece of your change off and submit that separately for review, I think is going to help make sure that the conversation is focused exactly on what you need it to be focused on.

You can help set expectations around here's what I'm trying to do with this pull request, here's why it happened, here's what we tried and how it failed and why we're doing it differently this time and here's the feedback that I need from you, but also we're not going to put it on some wait-list for 10 days before we actually get to it, which also I think helps build that trust between the authors and the reviewers because now, you have that quick feedback cycle and you're not feeling ignored.

SAM:  And everybody gets those quick successes and more of the --

JOHN:  Yeah and I think it also is going to influence your design a little bit if you're setting up the code in such a way that you're going to carve off those small chunks that you can add on. The changes are smaller and they're easier to test and they're easier to comprehend as little bites and so, I think that's going to influence the whole process of that feature from that point going forward.

SAM:  I just want to point out that this is another example of a word Katrina, that you used when you were describing your superpower and that word was systematizing. That really to me is like, if I had to pick one word to describe you, that would probably be one of my first choices because you're better at that than anybody I've ever met. Just being able to figure out like what about this is bothering me, what about this would be cool, how can I repeat that, how can I teach others how to repeat that.

KATRINA:  Thank you. I think this is one of the reasons why I obsess about refactoring. It's because it's a system and it's a system for improving things. I actually don't care much about building features. I'm super not interested about greenfield projects and building features and product and all of that. Despite the fact that Exercism is totally a product and all about that but I really get into how can we look at all of these 550 API points and figure out how they're inconsistent and what that inconsistency says about the pattern of the bugs that we're seeing, about the things that are hard about building new APIs, like are we copy-pasting the wrong things when we code review APIs. I think refactoring probably comes out of this systematizing ability that I seem to have.

SAM:  Actually, it reminds me of something else about Exercism that I think I heard you talk about at some point. Correct me if I'm wrong but haven't you spent some time trying to figure out what questions are helpful at a particular point in an exercise? The question that a mentor could ask.

KATRINA:  Absolutely. Actually, someone who's been doing a lot more work than I have on Exercism is Maud de Vries. She's a developer in the Netherlands and an amazing mentor and she has been looking at different points in your process of learning a new programming language: what are the questions that will be helpful to you at that time? For example, when you're first getting started with a new language, it's really helpful to talk about the idioms around syntax, for example or how you typically like to loop or where you like to put your variables or how you like to name them.

If you don't have that conversation early on, then when you have started feeling fluent in the language and someone comes and complains about your variables, now you're going to feel a little bit condescended to and a little bit maybe, confused about why we haven't had this conversation earlier. She's looking at which questions at which time are going to be helpful in terms of helping you go explore the next relevant thing to you, which I think is a really interesting process.

JOHN:  Is that something you're going to work on systematizing into the Exercism platform?

KATRINA:  Absolutely. We're working on it now. We have a curriculum team who is looking at how do you put this into a system of, "Are we using levels? If so, how many? What would those levels represent?" We have been talking about progression pads, so how do you take a concept and go from simple to complicated? And then how do you analyze your track if you're a track maintainer an Exercism. How do you analyze all the exercises on your track to see where they fit into this matrix and where we're missing exercises? And then, lastly how do we provide feedback guides for each exercise to all of the mentors so that they can look at an exercise and quickly see that, "Oh, here, the most important thing to talk about is this duplication." Everything else is just details and once you've got the duplication sorted out, you can approve the exercise and say, "Here's some food for thought, things that might be useful as you move on with your next exercises."

JOHN:  It sounds incredibly helpful. I've done some mentoring on a different learning platform and there wasn't really that level of guidance but that would have been really, amazingly helpful.

JANELLE:  We were talking to Mandy a bit before the show and she brought up your prior experience in a circus. I must ask because I've never met anyone that's been in a circus before and I’m super curious about how your experiences in the circus have shaped all of these things you're doing. It seems like they'd probably have so much influence on how you think about these mentorship problems and the exercises you're trying to build, this beautiful thing.

KATRINA:  Yeah. I think you're giving me more credit than I do. I don't really think very deeply about how circus has affected how I think about learning and mentorship. Here's the deal, I failed at circus four years in a row. I was trying my best to get into the top circus school in France for four years and every single year, I failed. Now, I got a lot closer every time. The first year, I was not even a blip on their screen. The last year, I made it to the top 40 of the list who got invited to a two-week audition. Unfortunately, I broke my leg during the audition, so I spent the entire addition with my leg in a cast. It's amazing how much that affects your balance, it turns out. I ended up placing 22nd and they only took the top 15. I'd never actually end up in the circus. I was in training to be in the circus and I did not do a very good job of it, honestly.

JANELLE:  Going back to this motivation slant on things, what did it take for you to fail four years in a row and keep on going and keep on trying, keep doing better? Because instead of having a success pattern that was driving you, you basically had repeated failure and then this just high agency, "I'm going to go after and do this thing anyway." I mean, that's amazing in itself.

KATRINA:  I have been terrible at decision making my whole life and this has reflects that, I think. I was motivated by the successes that I felt that I had along the way. I got a lot better at dancing. I got a lot stronger, I got a lot more flexible, I got a lot better at acrobatics, I got a lot better at weightlifting. Oh, my goodness. I was a monster there for a while. It was great. I didn't feel like the failures were absolute rejection. I felt like they were feedback about what I needed to work on next.

But after four years, I realized that I kind of got myself into a rabbit hole where I didn't really know why I was doing it anymore. If I had gone into the circus, my career would probably be over by now. I'm 41 now and I would probably be teaching or maybe, if I ended up in choreography or something, I would be helping produce shows. But in terms of acrobatics, I was already quite old compared to the other people who were trying to get into the school.

I think that I just got this tunnel vision, where I didn't realize that I should be making choices. I should be looking, I should be broadening the scope of what I'm looking at, of what the opportunities and possibilities in my life are and really take a look at what would the outcome be if I chose to do something different. How would that affect my life? What are the negative aspects of working in the circus? And am I willing to spend the next five years? Because if I had gotten accepted to that school, I would have spent five years in training before I even could apply to Cirque du Soleil or whoever.

JANELLE:  Interesting. What I'm hearing is there is this difference in mindset between zooming in and being hyper-focused on the details in one area and then realizing, "I'm not sure why I'm even really doing this anymore like that," that vision of yourself in that future, maybe didn't make sense and when you shifted because it's sort of like take a step back and you're scanning the landscape, looking around at the different potential mountains out there that you could potentially climb and then looking around, expanding your horizons before you decide what to zoom in on. Does that sounds right?

KATRINA:  That sounds right. I love the image of looking around at the various mountains you could climb because that really gives you an image of, "Is this a worthy mountain? Is this a worthy obstacle?" I think that's really important. I think that one of the problems with tunnel vision, which I have a natural bias towards is that I'll systematize myself into a local optimum. I think taking that step back and looking at the other mountains and really asking yourself if that obstacle is a useful one that will take you to an interesting place is that if you're going to be a good one, I think that's a useful question to ask.

SAM:  We're talking about applying to the school every year for four years. It occurred to me that a year is a really long time to spend preparing to apply and improving your kills, especially in the context of Coraline bringing up Pomodoro’s earlier and this being a really short feedback cycle, it occurred to me that maybe having more frequent opportunities for a feedback on a shorter time scale would help reduce, possibly one of the factors that may have gone into your decision which was the sunk-cost fallacy. What do you think about that?

KATRINA:  I think that's spot on. The year that I made the most progress, I spent that year in a prep school for circus, so they literally were preparing students to take the various intro exams to the top circus schools in the world. There's one in Montreal that's really good. There's one in Moscow. There's one outside in Paris and there are a couple of more. There probably way more now because that's like 20 years ago. But I spent the year at the school and so every day, I was getting feedback on the various skills that I was working on.

JANELLE:  Would you mind talking a little bit about what it's like to train, say for acrobatics? What would that experience like?

KATRINA:  You probably do about 20 to 30 hours of physical training per week. Most of that is not acrobatics itself. It's preparatory training, in terms of flexibility and strength and strengthening specific muscle groups and specific types of movements. If handstands are a thing that you do a lot and if flexibility helps, there's an amount of strength that you need that is just sort of a threshold amount. Now, anything over that is helpful.

If you've ever broken your leg and had to do physical therapy, one of the things that they'll have you do is stand on one foot. At first, that's like three seconds and then you fall over. Basically, you have to grab onto something because you are so weak that you can't even stand on one leg. This is sort of the same thing with handstands is you need that core strength but then there's also all of this subtle understanding how your body falls, so there will be two or three hours a week of strengthening your shoulders, of pushing in exactly the right way, of being up against a wall and standing for as long as you can on your hands, of working in pairs where you're deliberately leaning in different directions to figure out the subtle mechanics of bringing your balance back to center when you're slightly off balance.

For acrobatics, it's the same thing. We were doing trampoline training. We were doing all sorts of weightlifting and floor acrobatics. The people who wanted to do specific types of acrobatics, for example the... Oh, I don't even know what these things are called in English, [foreign language] which are I guess aerial straps, they would do certain types of training that the people who wanted to be on the tightrope. That's again, a completely different set of exercises once you decide what specialty you want to work towards.

JANELLE:  I'm still thinking about my original thing of wondering where the parallels are between circus life and software and mentorship school. Some of the things you brought up, I think are really interesting patterns of running these experiments with your body, of deliberately leaning, feeling your body, feeling yourself to shift off balance and then, learning your muscles of how you bring your body to kind of back in center and learning that control through physical experimentation and kind of patterning that way. It seems like all the same principles apply where doing these small experiments in succeeding becomes this reinforcing loop.

I managed to stay balanced for a little bit longer in its own success. It seems like this would affect how you teach in general. When I was listening to your questions about how you go about breaking down the process of teaching someone a new skill and mentoring someone and understanding the types of questions and how they change over time based on the types of things they need to focus on in that moment, that you could do deliberate leaning, if you will. Have you bring your body back in center, when you're coding? You know, what a center would look like when you're coding? I mean, it seems like these concepts exist in software, too.

KATRINA:  I think you're probably right. I just haven't thought about it much. I think one of the more influential things that happened during my training for circus was it was always a team thing. I was always working with people. It's not something that comes natural to me, to do that well. I learned a lot of things about interacting and how to work together towards making an experience. I think that that's kind of key in software. We don't usually produce widgets. We produce experiences and I think that how you work with other people to do that is a really interesting thing.

Sarah Mei gave an amazing talk called 'The new theory of teams' at Brighton Ruby a couple years ago. She talks about how every person who is involved in the process of producing an experience has an enormous effect on the final product and the earlier they become a part of the process of creating that experience, the more of an effect they will have. It's especially interesting because not everyone is visible in the final product.

If you're doing a theater production or a circus production, a lot of the people who might have just a tiny role are not ever even appear on stage. It might have had an enormous impact on what the final production actually looks like and what that experience feels like. I think that's the same in teams of software developers, where a lot of people get credit and because they're doing the visible work and I think that there are a lot of people who do the invisible work, the glue work, the work of supporting, helping other people to get things across the finish line, the ideas, the helping think through why this is a bad approach and how to find a better approach, that is very invisible and I think not often appreciated.

CORALINE:  I think that really ties into open source too, where we think of open source contributions does code contributions and we judge people by their GitHub class and ignore a lot of the invisible labor that goes into a successful open source projects in terms of community building and outreach and mentorship and all of these things that don't translate into a pull request.

SAM:  Yeah, I was thinking at the same time as you're producing the experience for your customers. You are also producing the experience of being on that team.

KATRINA:  That is so true. How do you be a good apple? I was reading about bad apples and good apples. I think that I'm somewhere in a neutral apple where if other people are complaining, I will turn into a bad apple and complain with them but if other people are good apples, that will reflect on me and I will take their behavior and share the joy of working together and producing something amazing together. I want to figure out how do you be a good apple, like just on your own, how do you come into a team and be a good apple.

SAM:  I want to bring this back just briefly to something you said much earlier in the show, Katrina which was about how people who are programming at eight, 10, 12 years old aren't really doing... I don't know if you actually use this phrase but they're not really doing deliberate practice. I just want to point out that many of us who start programming or continue programming into our 20s, 30s, 40s, we also do a lot of deliberate practice.

KATRINA:  True.

SAM:  And I was actually telling somebody yesterday about this time that I watched you do a workshop at RailsConf in 2013 and I noticed that you were typoing the word 'initialize' a lot and I mentioned this to you later and you said, "Oh, yes. I noticed that too. I'm going to do a bunch of typing drills," which was totally shocking to me at the time but hearing now that you had this background in doing circus training where you did all of these deliberate exercises to strengthen specific habits and muscles, that actually makes a lot more sense to me now.

KATRINA:  I did do those typing drills by the way. I can now spell and type 'initialize.'

SAM:  I'm so glad to hear it.

CORALINE:  One thing that strikes me is how the appearance of expertise can seem kind of magical to an onlooker. I know if I'm at a circus and I see a performer, the thing that strikes me is how effortless their motions are and their performance has when in fact, a lot of work has gone into making it look easy. I think about how that impacts people who are new to our field, who see us accomplishing these great things or delivering this great experience and wondering like, "How could I ever do that? I don't have the natural talent for doing that. I don't have a knack of it." I just show them that there is a way forward, first of all but it does involve a lot of work.

KATRINA:  I wonder if it's about being honest when you're struggling, especially as a senior developer. I remember watching, just a screencast video of Aaron Patterson and I can't remember who the other person was. It was probably [inaudible]. They were pairing on something and at some point Aaron says, "I have no idea what's going on," or something like that. He expressed his confusion and amazement that what on Earth could this be doing. It felt so wonderful to realize that there are moments when Aaron Patterson is confused. Can you imagine that there are moments when he doesn't know what's going on?

I think that making that visible around you is important. I think that it's really tricky, especially if you are part of a group that is underrepresented in tech, especially if you are a part of multiple groups that are underrepresented because showing failure, you often have to keep proving that you know, proving that you are capable, proving that you are expert enough and competent and deliberately saying, "I don't know," might actually put you at risk.

I think that on the one hand for the people who are new, it's so important to see that the people who are experts actually have moments where they're confused and don't know how to approach something but have a process for figuring out how to approach it. But I also think that it's too easy to say everybody should say, "I don't know," because there are people for whom that is a great risk.

SAM:  Absolutely. Which is why as somebody who sits at the intersection of almost all of the privileges that there are, is that I try to make a point of being as transparent about that as possible, because it's a risk I can take.

JOHN:  Exactly. At the end of the show, we like to do reflections where we talk about the things that are the takeaways for each of us, that really stood out from this conversation. For me, the combination of the talk about short iterations and early feedback as a way of both creating and maintaining motivation is really useful. I've been thinking about the Agile process a lot lately because I'm sort of about to go to some training and so, it strikes me as sort of like I'm putting agile in your Agile. The team process is Agile but now my personal process is Agile and then down to the Pomodoro level, where my hours are agile. I think it's an interesting way to think about that.

CORALINE:  I think a lot of the themes that we talked about today, we never mention this explicitly but they have to do with creating a sense of psychological safety and being transparent about your process. The vulnerability, Katrina that you mentioned about being transparent about not knowing things, the experience of learning a new language through a tool like Exercism or through other front of practice for mentorship and code reviews that we discussed a little bit, all of those require a sense of psychological safety to be effective. There is that Google study that showed that psychological safety is one of the most important factors for a successful team.

I want to think about that some more on my own time about how to create got sense of safety in code reviews, in particular because I think that's one of the ways that developers interact with each other most frequently. I want to think about how I can make an effective code review where I'm sharing the information and to be shared to improve the code or to make it more readable or to make it more performant or what have you, in a way that is respectful of the time and energy and practice that went into creating that code.

SAM:  There's been so much good stuff today and honestly, every time I hear you talk, Katrina I'm inspired to try to be more systematic and deliberate about how I approach the things that are important to me. Before I get into make takeaway from today, I should mention that whenever Janelle joins us on a call, she captures phrases and snippets of conversations and drops them into our group chat like little bread crumbs to mark the path that we've taken and listeners, this isn't a contribution that you directly get to see but it definitely makes the show better. I just want to mention on air that I'm so thankful for that contribution. Thank you, Janelle.

Looking back at some of those breadcrumbs, one thing that really sticks out to me is being new and interesting and the one thing I should look into further is this five-second window in which you can actually change your behavior and increase your motivation. That's something that I'm trying to focus a lot on in my personal life lately, so I'm definitely going to go and read more about that as soon as we're done here. Thanks.

JANELLE:  So many interesting threads through here. The main thing that keeps standing out to me is this idea of feedback loops as almost like spirals that are reinforcing toward the positive or reinforcing toward the negative and I'm kind of associating this now with his concept of what a good apple and a bad apple means or being in a positive feedback loop space or a negative feedback loop space and how the people around us, how safe we feel, if we feel rejected and pushed away or we feel like, "I can see the steps. I can see the path to get there and I am capable doing that thing. I'm going to carry the torch and lead the way down that path," and how those positive reinforcements of success and the continuing to contribute to those spirals.

Then, you've got this whole social interaction team dynamic and this experimentation dynamic and all of these conversations, if I look at it from a systematizing kind of way is that when we're in that five-second window and we have a choice as to whether we're going to be a good apple or a bad apple, whether we're going to reinforce positive feedback loops in our environment or we're going to feed off the negative feedback loops and shut down, that in those five seconds, we can make a choice to go and decide, I guess. It's a decision about where you're going to focus. It's making a choice of how you're going to invest your energy in the next few moments, in the next five minutes.

KATRINA:  Totally meta but that was awesome, Janelle. One of the things that Sam said is that sure, we don't really practice programming when we are four and five and eight but also, when we're 20 and 30 and 40, we also often don't really practice the craft of programming. I think that's a really interesting observation and relevant because probably, a lot of people who are listening to this are sort of in that mid-career part where you are no longer panicking most days. In most challenges, they'll come at you and you'll be like, "Yeah, I got this. I know how to do this. Did it before, been there, got the t-shirt."

Your comfort zone is big enough now that you can handle most of what your day job is throwing at you, which means that you're not pushed up against the margins anymore and that means that you're not being forced to learn which means that learning or improving now has to be a deliberate choice. Now, there are definitely ways that we have of improving like quitting a job and starting another one in a slightly different industry or vertical or something or in a new language but I think that very often, we don't push ourselves to do that.

I wanted to make a recommendation. There is a course by Cal Newport, he's a computer science professor at Georgetown University, I believe. Was that in DC? Anyway, he's a computer science professor and this course doesn't have anything to do with computer science, which I think is fascinating. It has to do with the art of improving your craft. He got together with Scott Young, I believe is his name, the guy who did the MIT challenge where he did all of MITs four-year curriculum on his own in one year and also, he did the year without English where he traveled to four different countries, spent three months in each country and only spoke that language, so forced himself to learn that language.

They got together and made a video course called 'Top Performer.' I think it's TopPerformer.com and they walk you through a really well-designed process of designing your own crucible, designing your own project that is going to force you to develop valuable skills, then it also leads you through the whole process of figuring out right now in the career that I have, in the direction that I'm going, what are the valuable skills. I found that really useful.

JOHN:  This has been a great conversation. Really, really lots of stuff to think about.

CORALINE:  Yeah. Thank you so much for coming on the show again, Katrina and you're welcome to come back anytime.

KATRINA:  Awww, thank you. This has been really, really great.

CORALINE:  We should mention that if you want to continue this conversation, you should go to Patreon.com/GreaterThanCode, sign up at any level of support and get access to our Slack community, where we talk with our guest. We talk with each other, we explore these ideas in a place that is very safe and very supportive, so you should really think about supporting us.