video-transcript.txt

  
   
  
  Growing an Elm project with the whole team
  
  Katja Mordaunt
  RICHARD: All right. Welcome back for our final talk of the day! Who is excited?  Yeah!
  [ Applause ]
  As previously mentioned, this is our final speaker and our other international speaker. And Katja traveled from the UK which is a serious amount of travel. Please thank her for coming all this way to speak to us. A quick bit of background, with neon tribe.co.UK. She works with small charities. Frontend when she has to, Elm when she can. And she produced independent films and believes that sharing stories makes the world a better space. Make a final welcome to our final speak, Katja!
  [ Applause ]
  KATJA: I have been developing software in small teams for over a decade at Neontribe. We work with non-profits to make digital tools that complement their overstretched services. And I have been raising children and dabbled in the film industry. And over this time I've noticed how people work together and behave in groups and how they treat each other. And I have been involved with projects where they break down because of a lack of communication.
  I'm going to their practical tips and talk about how and why I think Elm makes happier and more productive teams. Much of my talk is probably things you know. But I think it's important to give teams and people the confidence to make a be nice atmosphere. And maybe I'll say something that you didn't know too. But anyway, if you would know all this stuff already, hopefully I'll make you feel good about what you're already doing. So, usually our projects at Neontribe have a lead frontend and a lead backend developer. I was a backend lead. About two years ago I got assigned to lead a project and they only had enough budget for one lead developer.
  And after this discovery, it turned out there was no backend. So, with our other projects I had been down the jQuery, handlebars, Vue route and I was really suspicious of JavaScript. That's not fair, I wasn't suspicious of JavaScript. I was suspicious of my ability to write good JavaScript. And I was not confident that I wouldn't make a mess without a frontend lead to help me.
  So, at the same time I was playing can Clojure and Haskell and feeling like functional was a safe, predictable space. And then someone mentioned Elm.
  So, the app that I was building was basically a tool that uses stories and illustrations and some bitesize information to help victims of domestic violence gain the confidence to get in touch for help. And it was essentially a really simple structure. So, we built it over a year in short iterations. And we had our ups and downs. We had a lot of conversations at my company with other senior developers about Elm being the wrong tool and it was overengineered. And ironically, the experienced developers had ha lot more trouble reading the Elm than the beginners. They found the syntax really confusing. And I think it's because when you're used to reading a language, you can look at a block of code and understand what it's going without having to think about it. You don't have to manually pass through it. And a few of the languages they have been working in are structured in the same way. And they are superficial and didn't than Elm. They looked at it and said, pssst. I'm not going to look at that. We need to trust each other's tech and our ability to evaluate and make choices in good faith. And I tried to plain explain that Elm can make more complex apps safer. But it's a solid foundation for every UI. Unfortunately not everyone agreed with me, but we shipped the product and everyone mostly forgot about it.
  A year later we got a phone call from the women's charity who we made the app for. They had really good feedback from a lot of women. They wanted to translate it into a couple more languages to see if they could reach more people in their area. And around the same time we got a call from the funding body who funded that charity to make the app, and they were so happy with the success of the app that they wanted us to white label the format and roll it out to three or four more charities to see if it would help them as well.
  I spoke to my manager and decided between myself and the original developer who was supportive of Elm, we decided between us we could handle the upgrade to 19 and the translations but we wouldn't it have time to roll out the clones. We didn't have time in the months to deliver it.
  We decided to port the original format into HTML and JavaScript so other people could work on it. And my manager was thinking of the labels of the people he had available. But precisely because of it being in Elm, I would be able to rely on people that didn't identify as coders. When Holly who was with us three months stepped forward after stand yup asking if we needed help with anything, I said, yes. There is something I need help with.
  So, historically there are a bunch of developers from different developers, some change careers, some have computer science degrees. Some have been selftaught. And between us, we took care of all the nondevelopment work. But recently we hired a few people with little to no coding experience to support us with those tasks. And those new hires, they had a bit more time on their hands because they weren't like deep in the company already.
  So, we set off with myself and the other developer who had worked originally on the app who, like I said before, only had like two or three days out of a whole month available. A user research we are a maths degree who had done a bit of coding and loads of experience in the charity sector. And she was going to run the sectors and work with the clients. And Holly, our new illustrator who wanted to help. So, of course, we hit all the same problems that every software had. It didn't go swimmingly by any stretch. But this worked well and how Holly helped me reflect on where our process could be better.
  So, now that we had Holly on board, I wanted to come up with a commonsense framework to some guidelines so that we could help her do the project without us interesting available. The first thing that we decided was we needed to keep  like what the team members need to know. It was minimal. Don't need the intricacies of Git or how powerful the type system is in Elm. Show them the tiny bit of code they are going to be working on to begin with and they can build their way out of that. You need to have short conversations with them often. So, even though we were really busy, we could find like five minutes every day or ten minutes or once a week to check in with Holly to see how she was getting on and check on code review in between.
  This is another important one that we didn't actually get around to doing but I think it's a good idea. And I can't say for your situation, but I think it's really important to set guidelines for code review because that was one of the things we had trouble with new people to coding. There was a few talks that could help you design this format. One of them is Richard Feldman's talk last year, elmconf, he talked about some changes to the model. Could they be introducing demarcation?  That would be good to check through for somebody who didn't understand the whole thing. Another is Alley McKnight's talk. And there was a talk at Elm Europe where they were talking about onboarding the biggest Elm app in Japan. This is where I got the idea from. They had a matrix, if you're reviewing the model, review these times of things. If you're reviewing the view, look for these types of things.
  And the last thing this I think is really important is to talk to each other about how to pronounce the code. I saw a good talk by the keynote speaker tomorrow at Strange Loop, that's how code sounds. And about how she's been teaching children how to code. And it's about if you don't know how to pronounce the symbol that you come across in something you're reading, it stops your brain from being able to process anything else. You probably have the experience, if you're reading a novel and don't know thousand pronounce a name, I pronounce it a random way and stick to that. But it usually has no phonetic relationship to the actual word. The same thing can happen reading code and you have to get past it. A dash could be a hyphen or it could be contextual sometimes. It might be minus. And you just need to discuss before you get into curly braces and square brackets. It's very confusing when you're trying to talk to people about it.
  So, just like organizations and projects and teams need new people with fresh perspectives, how communities need new people with fresh perspectives too. And I'm really proud to be a member of the London Elm code meetup. Because Mario does a really great job of welcoming newcomers. And he always tailors the content to whichever people turn up. In the, the invitation is so welcome and opening that people don't know what Elm is. But they want to get into coding or back into it from a break 20 years ago. They turn up and we like that and help them.
  When Holly first joined the project, she didn't have a development environment set up. I didn't think that should be a barrier. I got the testing manager to submit to GitHub. I was trying to get as many people as possible to submit something. He went to GitHub online and pressed new file and copypasted an issue template from another repository and named it bug and date and got really excited. Because he made a thing that he could see. So, often first issues are like about editing copy. Or, you know, making some sort of trivial change. And anyway, even if they're not, we're editing plain text files. So, to think that you need this whole massive setup just to contribute a little bit is not right.
  So, with Elm, new developers and nondevelopers can be productive really quickly. And the framework doesn't get in the way, it's really easy to set up, there's no massive boilerplate to navigate around or be scared of, no complicated tool chain to understand. And this reminded me of something my colleague said recently. He thought it was a real shame that younger and new programmers could not configure a post fix server. And I was like, surely that's a good thing that they don't need to worry about configuring a post fix server. It's great that that we don't need to write JavaScript in order to be good at our jobs.
  So, once Holly was set up, she started submitting more than just copy changes. And I remember a time that another colleague had been coding for about a year. He wasn't really writing code before he came to us. He said all we do every day is go round in circles rewriting each other's code in our own style. And I looked at what had been happening to him. He was right. He had been writing a feature in CSS and getting it through review and merging it into the release. And a week later, someone else would write another feature in the same area. And they didn't quite agree with his style of CSS. They would write his CSS, again, in their style and add their own bit with their own CSS. And it kind of turned out on a three week cycle everything that the one developer was writing, the other one was rewriting it at the same time that they were doing their new work. And there wasn't really any reason for it.
  So, sometimes these kind of refactors are really important. And sometimes they aren't. So, as with everything I'm saying, the most important thing is to consider what you're doing and why you're doing it in the context of your own circumstance.
  So, because of that experience with that developer, I was really careful to let Holly do it her way and not tidy up after her if it wasn't a critical thing.
  Collaboration means everything shouldn't be nor your own style. And you should let the project style evolve with everyone having input.
  So, I mentioned code review guidelines earlier. And that's because when Holly first started collaborating to code review, she didn't say much. And I think that's a common experience. People are scared to, like, let other people know maybe what they don't know, you know, what they're ignorant about or what they don't understand. So, I talked to Holly a lot about not being afraid to write more than like, hey, that was good, in her code reviews. And just see  observe things and make comments about them. And she got a lot more confident in her responses. So, for us, and like for experienced developers as well, sometimes you will come across code that you don't understand. And you shouldn't just rewrite it, which is what some people do. And you shouldn't ignore it. You should ask about it. And have a conversation with the person who wrote it. If you can. If they're still in the company, still around. I like this conversation that Holly had with that user researcher that I mentioned earlier. You probably can't see it, I'll read it to you. I can't see it well either. It seems to have added a double quote instead of a single quote. I don't know if that's important. Oh, it's just my prettifier making things pretty, not. Oh, that makes sense. It makes it look more pretty, but apart from that, it looks good. I know, it's really odd.
  And there was after that another comment from another developer explaining the whole situation. But I thought that was great. That those kind of conversations are just happening in our codebase. So, the declarative style of Elm allows people to discover their own hand. There are many reads to get to the same endpoint. And if you give even ownership of their own journey and don't instruct them on how to do things, just give them a framework that guides them, they will be happier. So, when Holly comes back to this codebase in six months, she'll appreciate she had a hand in the decisions and wandered around a little bit. We don't often take the perfect path the first time round. Nor do we probably ever take decisions without thinking about them.
  And my colleague, Rupert, sum this is up nicely. You must have faith in your colleagues' competence and their good intentions. It's very likely that the problem that you perceive is an indication of tradeoff that you don't yet understand. You can have a lot of people in the team. More people in the team is less burden on the individual. Or people outside the core team for bouncing ideas off of. And occasionally jump in when deadlines are looming. Especially if you're outside the core team, sometimes things get made a long time before something existed or before a certain tool chain was in place. And sometimes things get made in a hurry. And sometimes things, like people, make mistakes also. There's always a story. It's really important to remember that when you're looking at the code that other people have written.
  So, hi a really valuable learn experience with a colleague from the original Elm project. Because it was about people or for people who were in violent or abusive relationships. We had a safety feature that was a time out. If you had gone idle for more than a certain amount of time, the app would turn off and go to Google. And in order to implement this, obviously this was my first Elm app. And I was superscared of time and Elm. In order to implement it, I kicked off sleep timers. When they reached the time limit, I checked if it was the most recent and kicked the time out function. It was complicated and really buggy. And my colleague who at that time had been with us for a sense. See the pattern here, I take people that come in new and bring them over to Elm.
  He was with us for a month and was a game developer. Had no JavaScript experience and he wasn't very confident. And he said, you know, this like seems really complicated. If I was doing this in C#, I would do it like this. And it was like really simple. And I just immediately said, oh, you can't do that in Elm. And, of course, I didn't even know whether you could do it in Elm or not. So, because of that  so, sorry, then what happened was I went to Elm Europe last year. So, this was a year ago. And there were loads of talks about game development in Elm. And around the third or fourth talk where people were saying, what you do is you make a subscription to time and have a tick and in your model and keep track of it. And sync it. Wait a minute, that's what my colleague was saying a year ago. And I came back and implemented it, no bugs. This is me being really excited in a commit. So much better time out function, exclamation mark. That's how excited I get.
  So, because of that, I'm not too quick to dismiss the thoughts of newcomers to the project, no matter their experience. And we need to remember that everyone's voice is valid up. And sometimes with less knowledge, you see more. Sometimes more overview and more  the more entrenched you are in something, it's much more conflicted than it needs to be. So, those people who have the new  those new ideas, they might only say them to you once. And they'll probably say them like really, really quietly. So, you need to listen up.
  It's important to remember to trust your team and by that, I mean, trust everyone in your team. No matter what you think their knowledge is.
  So, remember that picture of my team?  If we had stuck to thinking of Holly as an illustrator, we probably wouldn't have been able to deliver the project on time. If you label something as X, people are lazy about assigning use cases to it. But if you don't, they can use their imagination and intuition to assess that person or thing in the context you're in. And sometimes our job titles can erode or inflate our selfesteem as well. One thing we had success with on a project was to remove vocabulary from job titles diminishing their identity. And job titles like junior or trainee, which in my company, assigning to people who were like 35, 40 years old. They're bad because the accounts department needs to justify charging more for a more senior person and less for a less senior person. But I think that if your company will, like, is on board with this idea, then you should be able to get rid of those labels. You should be able to get everyone into a position where words like trainee and junior no longer apply. Within months of them joining your project or company. They can just be developers. You can have loads of developers, right?
  So, one thing that we like to do in this industry as well is like call people rock star developers or JavaScript ninjas or other terms which are maybe more derogatory, like being a server gnome. You can see those ones in my picture. I want to focus on the rock star one, that kind of concept. It is a real concept that someone can have a lot of knowledge or a lot of experience. You can be a veteran who has learned stuff over time, right?
  You can learn like tiny bits of knowledge bit by bit that you never forget. And like an example of that would be a concept in English grammar which is a  which we work with a allot. We come across in our industry. And symptom people don't know what it is. And basically, you have a really, really long word, you can drop all the letters out and count them up and number back into the middle of the word and get something like A11y for accessibility for I19N for internationalization. And there are experts that don't know that. And they are saying, a11y, but they don't know what it means. And it's just really important to remember that nobody knows everything.
  And there's another type of, like, knowledge or skill that people are gonna have that's just a natural skill. Some things come much easier to some people than other people. And, again, I've got a really good story about that for me, my personal experience. I was at a conference and I met somebody who I thought one of my friends should meet. I went back to my friend and said, I've met this man. I think you should meet him. You have similar interests. I'm bad at recognizing faces. I can't recognize my own children sometimes. Sounds silly, but it's true. He's wearing a black Tshirt, at a tech conference. That didn't help. Help me kind of look out for him. And someone was overhearing it and he piped out and said, oh, that's really stupid. Even a female baby can recognize faces. That's like scientifically proven. And I'm not sure if he was saying that I wasn't a female or stupider than a baby. But either way, it wasn't really a helpful thing to say.
  So, just in the same way that  you should respect like people's knowledge or lack of it, you should respect people's natural abilities to do things. And labels can be put there by yourself or by others. Someone selflabeling themselves as a rock star. They probably don't realize the expanse of the domain they're in. There's a famous saying like, you don't know what you don't know. That's probably someone who calls themselves a rock star. If your boss says you're a rock star. If he introduces you to a client, you're lucky. You have a rock star developer. That's a huge amount of pressure on you to keep up the appearance of having a deep knowledge. And honestly, every project you're learning new things you don't know what's going to come up inspects project you're working on. It's unfair to put that pressure on your colleagues or on people.
  I'm really guilty of that with Holly. Because she did the illustrations of the slide of our team. And I was like, can you just make a slide that has like some people just going about their jobs, not happy, not sad. And another one where they're angry and not sad. And another one for the end where they're happy. She went, well, I could try. But I'm really bad at doing people's faces. And I just made the assumption that she was an illustrators. She could draw anything. That's not true. The same thing that someone who writes code can't just automatically do every kind of code. Sometimes labels are a useful part of the picture. But you have to be careful because they're not the whole picture.
  Neon tries to do a lot of prioritizing in paper. And it democratizes designing something. You can get everyone involved whether they're an artist or coder. You don't have to get it right the first time. Elm has that too. You can let someone who hasn't been trained and let them loose. Let them play around and they'll figure it out. It's got, as we know, a really supportive compiler. And I won't go into details, but Emma Cunningham did a nice talk in Europe about how that compiler works on the fear of failure and makes us more equal. And there was a talk in Europe this year, I'm sorry, I don't think the videos are available online. I'm not sure if they will be. But he's a visual designer and he was talking about how amazing Elm was for using the data model to communicate with like members across the team as like a common interface of language so that the developers could speak with the designers and they both understood what the model was.
  And basically much of the engineering constraints is taken care of by the constraints of Elm. So, we can use it in this like really cool way for like simpletons to be able to manipulate stuff. So, my daughter likes to remind me that I'm not a robot. But from the list that I made when I was a kid, I'm not so sure. But there are certainly times like when I was talking to Holly and saying things like, oh, that's just a type and you can use it like this and I had to pause and say, you're not following me at all, are you?  And she was like, nope. and it's really important to acknowledge that. They won't admit it. They slowly get a more and more blank look on their face. If you say that it's okay and you talk to them about it. That's better than them going away and not understanding anything you said. We need to remember we're humans, not robots. And when we speak to each other and when we're writing the code. Our efficiency needs are different to theirs. And that is like too  I mean, different to theirs in the future readers and writers of your codebase. But also different to the computer's needs. When you're doing refactors and review make it easier for everyone. By that, I mean, easier for the people looking at your code. And not worry about how clever the code is. Your computer can kind of handle it.
  So, it is true, decisions are really hard. And I encouraged Holly to let  to let her name start off however she thought of them and let them evolve naturally. Instead of saying make a thing that does this that is call that. And I encouraged her to name things without hesitating. I could see how much she understood about what the code was actually doing. Besides renaming stuff in Elm is really fun, it's not scary.
  So, remember when I said it didn't matter that Holly had no development environment when she started?  Well, that's not entirely true. And we had two kind of experiences that happened at the same time in our company. We had a Vue app that we were internationalizing at the same time that we were internationalizing the Elm app. And in that Vue app, someone left a curly brace off of one of the JSON files and it got reviewed and released to staging. And one of the testers visited in that language and saw a white screen. The same thing happened in Elm, it got reviewed and merged in and pushed. But it didn't get to staging because obviously it didn't compile. So, I don't know about you, but I prefer the bottom one of these pictures. Because the other one would have made it into the actual production release.
   so, I guess that there will be bugs is the point. There will always be bugs. But catching them at compile time is really great. But for all of us, not just Holly, new to coding, it's important when you come back to the code or pass it on, you're able to understand it. If your code confuses another developer, no matter their level of experience, consider adding comments about why you did it that way. You need to remember that we don't have all the knowledge or the domains that we work in all the time. In Elm, it helps that they can implement it without knowing the whole. And there's no behind the scenes magic. There's predictable and encourages us to be deliberately verbose. The only one with Elm is turning it into amazing JavaScript. That's not just the only. Mainly that's not our problem. Elm makes peoplefriendly code which is good for beginners and good for teams and it's good for the future us, right?
  So, when I was at Elm Europe, I was trying explain to somebody who didn't already use Elm why I liked using Elm. They asked, with why do you like Elm?  You write some code and then it starts to make you happy. They got really excited. Oh, that's so nice. It starts to make you happy. I was like, okay, well, maybe thing it's so exciting that it starts to make you happy, I'll use that. I said to my colleague, I'm going to use it in my talk. Starts to make you happy. And he was like, hmm m... it's nice. All code make use happy. Doesn't matter the language or framework you're using. And I was like, oh, yeah. Oh! But Elm starts to make you happy sooner.
  [ Laughter ]
  So, there's a lot less head bangs and theory before we can reach that happy place. And in my company, Holly isn't the only person who is feeling that joy right now. Those were all like first PR excitement things. Lots of people in my company like emojis a lot. When they get excited.
  So, before I get to the next bit, I'm pretty sure that everybody in this room has had the experience where they've gotten upset or made someone else upset or even cried or made someone else cry just as a result of how a project was going or how your team was communicating, badly or otherwise. I'm going to share some questions with you that I have been asking myself since I started this exploration of how to work better in teams. I can't tell you the answer for you and your situation, but it's worth thinking about this in your teams and projects. How can we create spaces and cultures where with don't feel pressure to appear to be the best at everything all the time?  Or be the best at anything?  We're all trying to be the best, give yourselves a break. And confidence is arbitrarily determined. I don't know what you know what I mean, but Trump?  Why  why do we try to intimidate each other?  Why don't we just encourage everyone to speak their thoughts?  I think like single track hierarchies are totally meaningless. Because we all have parallel skills. And we're building a compilation. We're not building a tower. So, I think we all want to be great at something and it shouldn't matter what this something is.
  How can we approve the democracy of our collaborations?  I think we could start with removing the dividing lines between those who get and those who do not. And that includes clients or product owners if you're  the product is within your company. If you share your code with your clients, they like  they light up. They appreciate you. Just go, oh, it's really simple. You know the bit that does that thing on the screen, it's this bit of code. They don't need to understand it necessarily. They can see it and relate to something about it. I've tried it with two clients. They get excited. Oh! You're letting me see the magic part?  Everyone has skills and knowledge and experience to bring to the table. Encourage them to try stuff and showing them how to do stuff, not pretending it's too hard for them. And we don't put user needs of Devs to the top of priority and scoping. If you show them the code, they will give you more money to do things like tech debit.
  And the last one is do labels and job roles parentheses us from sharing knowledge openly?  It's really easy to hurt feelings and judge each other and tech choices. If everyone had to know everything to achieve success, it would be a total nonsense. You don't need to know chemistry or physics or whatever it is you need to know to bake a cake. You don't need those but might help you invent a new or better cake. We need better cakes. We need engineers in our industry. But we don't all need to be those engineers in order to be productive or do our jobs. One of the things I'm thinking about as well, why does our community and the academic community as well seems to suffer the same thing. Why are people trying to hide their knowledge, or hide their lack of knowledge? I don't understand where we aren't just sharing everything when people ask. what can we do as a community?
  We all feel dumb and vulnerable sometimes. So, the important thing I think is not to box people in and not judge them or jump to conclusions or make assumptions.
  Ignorance is a universal condition. Nobody  nobody  even people outside this room  nobody knows everything. So, within this community, at least, and I guess like by community I mean, like planet Earth, people. I'm pretty certain that we all mean well. Listen to anyone that finds themselves next to us in the space, no matter their journey to get here, or no matter what it is they're wanting to say.
  And that's all I got.
  [ Applause ]
  RICHARD: All right. Thank you, Katja. That concludes 2019 edition of elmconf.
  [ Applause ]
  So, who learned things today?  Yes. All right. Who enjoyed themselves today?  Ah, excellent. All right. So, I just want to take a moment to appreciate the fact from the reason we learned and enjoyed today was in part because of our amazing speakers. Could we give them the biggest round of applause that you could imagine?
  [ Applause ]
  And then I know I just said the biggest round of applause you could imagine. But now I want you to stretch your imagination and give an even bigger round of applause for the organizers. Because without them, this conference would not exist. Thank you so much.
  [ Applause ]
  
  >> And one more for Richard. All right. Just some details of this evening before we get going. Uhoh. All good?  Yeah. Elmconf 2019, the one where they killed Feldman. Oh, no. Okay. So, just a couple of things. The Strange Loop party tonight starts at 7:30. You don't need your badge. If you brought a spouse, significant other, partner, friends, anything like that, they're welcome. The shuttles will start running here at 6:30 from the hotels that is. And they'll go up and back to the City Museum until 10:00. There's no dinner there, eat first. But there will be desserts. It's basically a giant jungle gym. If you want to climb and stuff, bring sturdy shoes and pants and stuff or you're going to get all bruised and stuff. It's good fun, though. Highly recommend it. Badge of honor.
  Cool. So, I would like to just say thank you, again to you all for coming. It's been so wonderful to see everybody year over year. Like, we're in the fourth year now. The fifth year coming up I'm superexcited to come back next year. However we do it. Thank you so much to Luke, to D and to Emma who could not be with us here today for organizing. It's just been so wonderful to work with awe you. Well done.
  [ Applause ] 
  >> Thank you so much if to Brian and Luke for allowing me to coorganize even though this is my first elmconf that I've ever attended.
  [ Applause ]
  And huge, huge shoutout to all the first time speakers up here. It's terrifying. But also you did such an amazing job. So, proud to have like read all the proposals and then like see them on stage and I'm like, closest thing to proud parent that I could ever feel right now. Thank you.
  [ Applause ]
  
  >> And I guess, you know, folks, elmconf. We love to see it.
  [ Applause ] 
  >> See you next year! 
  >> Thank you Richard!