scale.bythebay.io: Rebecca Ely, Teaching Scala to the statically challenged
Recording: scale.bythebay.io: Rebecca Ely, Teaching Scala to the statically challenged
you so as a heads up there will be a link at the end of the slideshow with all the resources for this talk so no need to take photos during unless you are really excited about the way I look when I'm talking about Scala I'm curious before we get started who is here B or who here came to Scala not knowing any statically typed language they came from maybe Python or Ruby or JavaScript cool that's actually a pretty large number of people who here has taught someone who come who fits into that category Scala before Wow that's also a pretty big number of people who here is anticipating that they'll need to in the future maybe your team just hired someone or you're looking to get more engaged and who's here just because the talk sounded interesting and they care great who's here because they just realize they're in the wrong room and they're about to run out and go somewhere else whew all right well since you're all here for me let's get started my name is Ellie I'm on the SPARC platform team at Bloomberg and I joined Bloomberg one and a half years ago knowing only Python and JavaScript never having done any Java or any C certainly no Haskell or rust or anything like that and but I do have a background in teaching before becoming a software engineer I'd had several jobs that involve teaching either officially or unofficially and so this talk is going to be a set of observations that I've collected in my year and a half learning Scala that are sort of with the pedagogy that I with the pedagogy concepts that I'm familiar with applied now I want to tell you about what worked and how I learned what didn't work and also what I've learned from other people I've talked to who have been on either side of this divide before now I hear you thinking or at least I was thinking when I got into this talk who are these people who have never taken a course on compilers well their software engineers they're just not the stereotypical kind maybe they come from boot camps maybe they taught themselves how to code they could be changing careers from one technical field to this one or they could be you know students who took a few CS courses in college but we're not CS majors and so didn't get that full suite that we starting to typically think of when we think of CS students it's hard to make a general make truly blanket statements about what these folks know or don't know because they're coming from such diverse backgrounds but you can generally guess that they're not going to be really hip to how compilers work they won't have a strong understanding of type systems they probably I had never heard of functional programming coming into Scala and because they don't know C or Java or Haskell they're the most of the resources that are out there that are introductory scholar resources are not written for them and so they're going to have a little extra trouble understanding those without your support if you have a question data scientist that's a great one yes and yeah I think a lot of the concepts from this talk will apply to that group as well and so these are people that for the conception of this talk these are people you've already hired they've proven themselves in some other way maybe they've done great projects they've had previous technical work coding and so they're definitely skilled they just haven't had a chance to turn their aptitude into application yet now you may be thinking Ely clearly you are a major asset to your team but why should my team take a risk on these people who don't know the difference between public and void and my response to that is remember this job board from last year's Scala by the bay if you can't see on this side we have the people looking to be hired and on that side we have the companies looking to hire some in addition to this type market for Scala devs you can find that this is a really rewarding experience as they say the best way to learn is to teach your team can benefit from bringing in diverse experiences and perspectives of these engineers and you get the chance to mold these people in your image make the scala devs that you want to see in the world now tell me who here has opinions about Scala exactly also the scala community can really benefit you can you may be bringing in the next scala rock star someone who's going to write your new favorite library in a few years and also let's not underestimate the value of silly questions this is mostly a community of experts even when most people are coming in and learning Scala for the first time they're already experts in a lot of the concepts that we take for granted beginners don't take those concepts for granted and so they do a good job of questioning assumptions that really should be questioned and often aren't they also you know if they're asking questions say on Stack Overflow and we're answering those questions for them that's lowering the barrier to entry for the next wave of beginning scala developers which means in a few years you'll have an easier time hiring people so I thought we could go through some tips based on my experiences learning Scala and for all the tips on this slide they I feel like they can all really just be boiled down to thoughtfulness is effective the first one I've got for you is ask how they'd like to learn personally I love seeing examples of whatever it is that I'm supposed to be doing next other people might prefer that you give them something to go and read encourage questions make sure that these people know that to you a basic question is not a bad question and make sure you know for yourself that a basic question is not a bad question you want to be their resource for the fundamentals you want to make sure that they know this stuff and also remember they come to you with the same question multiple times it takes multiple exposures to really learn something well and so make it clear to them that you will not be offended if they ask you something really similar to what they asked you yesterday check in mid lecture don't waste your time by rambling at someone for 10 minutes when the first thing you said didn't make sense to them and you lost them right out the gate questions that I like to hear when people are teaching me things are things like did that make sense to you do you want to try explaining that to me so I can make sure you really got it is there anything else that isn't clear to you stuff like that even before you start lecturing check in to see do they actually need this lecture or do they already understand this concept that you're assuming they don't just because they're a beginner dig up resources they got the job they know how to find resources making them go and find them is not making them stronger developers it's just wasting their time one time I coworker was giving me some suggestions about some code I was writing and he said this would be a good place for a map so I go and I spend 20 minutes finding resources on the map data structure and then I spend an hour trying to figure out how this could possibly fit into my code well of course he was talking about map as a method but that was a lot of time wasted for me and that was two concepts that I had to pick up right away instead of just the one that I actually needed to get the job done set timeline yep set timelines so this is make sure that they know and make sure you know for yourself timelines are not to grade someone or to judge their performance it's more about setting expectations for them letting them know I think this project is going to take you a while or this should be really fast if it's not really fast come talk to me because there's something else we need to figure out model good code this means writing tests this means writing clean clear readable code this means being explicit about your types if there's some uncertainty in the beginners eyes this is good documentation and examples all these things that are really good for you to be doing anyway but are especially meaningful when this person is not going to be able to make all this the assumptions that you would expect a expert developer to make and also it's modeling good code it's teaching them how you want them to be writing code finally introduce them to the community this is good because it lightens your load it also exposes them to a broader range of topics than they would get just at work with you and it's a good way to convince these people that you have friends so those are two ideas let's get into just a couple of don'ts the first one is don't say oh oh dear ski has a great course on Coursera and then disappear for two weeks it happened to me I've seen it happen to other people it's not a good way to start never say just and what I mean by this is be really careful about the tone that you use to tell people to give advice to people there's a huge difference between someone saying but it's so simple which feels really awful or it's actually simple let me show you the second one is I know you can do it anyone could do it but I'll show you how so that then you're strong at it don't mistake inexperience for incompetence and relatedly don't mistake vocabulary ignorance for conceptual ignorance so let's talk about the first project that you give one of these new coders on your team I'm speaking completely from experience here I feel like I sort of had about three first projects some some of them went excellently some of them did not one one excellently two of them did not and yeah when I say first I actually mean the first few projects the in my experience and in my opinion the very best way to start someone out is writing unit tests you can have a couple there that they can use as a model and then it's a way to introduce them to your code base you're giving them quick wins because unit tests are quick to write and it's instant feedback loop if they can get the tests to pass then they know they've done things correctly next best would be partially complete projects something where you've already determined the structure of the project you've made all the big decisions and you've even written some of the code so that they can look to that as an example for what to do and you have a strong idea of where it's going so that you can support them if they come to you with questions also great can be warm-up exercises although there you lose the awesome experience for them of contributing right away to the codebase and you also lose for you the lessening of your workload that that can be small projects just in general keep things small you don't want to let people go down the rabbit holes that like behemoth projects can give you I have found and this was one of my first projects that didn't go great dependency upgrades seem so simple and yet they're simple to you they are not simple to someone who doesn't know the dependencies who doesn't know the code base who doesn't know your deployment system it's just don't I don't recommend it because what takes you half an hour and feels like nothing could take them a week and they're spending that time knowing you expected it to go faster also bug fixes and just bad code in general first of all you're not modeling great code for them and also those are the sorts of things that if it's tough for you to find it's gonna be super tough for them to find and even if it's easy for you to find they're not familiar with their code with your code base so they have to learn a whole lot just to solve one small problem I also don't recommend concepts new to you both because who are they going to go to when they have questions and then also because in working through this problem they may hit a point where you would have realized this is not going to be possible to do and they won't know enough to say that and so you can send them some some down some really deep and unpleasant rabbit holes just in general the category of like stuff you don't want to do I find contains the best possible projects to start someone on and the worst possible projects so don't use that as a guideline for what you should give people but do you know be really grateful if the stars align and this thing that they're going to be really excited about and learn a lot from is something that you would just as soon not do because it feels tedious so I know I know this is a Scala conference where's the Scala I like to give you this quote from a friend of mine he said it to me when I found out that I was going to be learning Scala and had no idea what it was he said Scala is a language written by academics it's very clever don't try to learn every funky feature now if you focus on the core the funky stuff will come with time and I have found that to be really great advice really true I think it's also a great advice for people who are planning on teaching Scala to consider so going into the specifics of what that means these are my suggestions for what you should start with right out the gate it's cool if y'all disagree if we have time at the end we can have a bit of a debate about it but I really encourage you to start with types and type signatures this is just not necessarily going to be clear to people who come from a dynamic language also tools like I said this is your chance to mold someone in your image if you have a favorite tool they will have a favorite tool and it'll be your tool my one exception to that or my one caveat is please don't make them do vim or Emacs even if you're a BIM or Emacs wizard there are so many awesome things that IntelliJ gives a beginner that it just it can speed up their learning so much functional programming basics like valve not far feel free to just give orders here and and you can do the explaining as it comes up or as they ask questions what is an object versus a class versus a trait versus a method versus I type these are things that probably feel really obvious to you but and at this point they feel really obvious to me but a year and a half ago very confusing to me in a couple of a couple of talks with some co-workers who were more comfortable with it really like set me on the right path and made coding in Scala a lot easier compiler basics and by basics I mean what is a compiler not don't have them writing compilers and finally options this is a personal opinion right so now let's jump on to things that I wouldn't recommend right away monads implicit scurrying anonymous functions case classes recursion compiler intricacies you may be looking at this list and something on it might feel like but that's a core feature of Scala like my life is so much better because I can you know use implicit cert case classes or something and I have a little story for you to make my case for why you should hold off on these which is that when I joined Bloomberg I was I probably had case classes in the first like eight months explained to me maybe three times and you know no long explanations but enough that I it was clear to me that the person explaining it was really excited about case classes and I just didn't care and you know I I knew what they were if I saw them in code but I would never write them into code myself because it just wasn't clear to me why one would do so then of course I submitted a pull request that had a type that looked something like this in it and my coworker sat down with me and said you know I think this would be a perfect case to use case classes and so he spent five minutes with me went through and we replaced this with case classes and it blew my mind and I was so excited and now I love case classes and I you know I recommend waiting for those moments where you can actually make make the person you're teaching feel really great about the thing because you're going to be making their lives easier so that's pretty much what I've got this is the flood that I recommend you photograph if you'd like to go to this link up here that there's a write-up of this talk there there are also a collection of resources that I have been you know putting together over the past year and a half as I've been learning that are things I have found you don't need to know Java to understand and so if there are any learners in your life I totally recommend sharing those resources with them I welcome contributions to here if you'd like to go in and add some of your own learnings or add other resources that you've found and I just want to close by saying that you know most of us aren't full-time Scala instructors and in the short term putting effort into pulling junior devs into the Scala fold can feel like a trade off against other urgent demands on time but if you approach this process with intentionality that can mean a smoother ramp up for your learners now and then a more effective appreciative teammate in the future so that's what I've got [Applause] do you have any questions or does anyone want to debate me on monads you want to stop smelling something or do something exciting typically that all summer Jason stop does not have something in the standard library is so much to choose from existing libraries allow these functionalities talk to you recommend a beginner chooses I think I have two answers to that question one is my answer for beginners which is sort of do what's sitting right in front of you as you get more into things you'll have a better understanding of the space and so you can make more decisions but if you've got a co-worker who says we need you to ramp up on this like they're ready to give you the support and resources to learn this whatever it is as the mentor as the teacher I would say remember that like to these people all of this stuff feels really new so writing tests may feel really dull and like something you have to do I mean I don't really feel that way still but I know people do but for a beginner and when I was a beginner it was so gratifying to you know I have this tiny little thing done and so it was less about learning the hippest new technology and more about getting a sense of mastery of something as quickly as possible so that answer your question so too much yelling ouch okay so about taste glasses how they are supposed to Anna model data structures if they they don't know the case glasses with a chest I guess I have two answers to that one is what are you asking your beginners to do there are ways to get around case classes for example ugly stuff like this if you have a specific use case where you really can't get around it go ahead introduce them this is more a suggestion about not introducing concepts because you're excited about them but introducing them when they are useful for the situation at hand [Applause]