technical, unfortunately, sorry, not that many code examples. So my name is Mikola, I work at Pocket Math, but everybody just calls me Mik because it's shorter and easier to pronounce. So we're going to talk about some code review stuff. So as you can see, the title of the talk is actually, do we do it right? And there's a question mark. So it's not the best way to do code review. It's not the only right way to do the code review or not just let's do it because it's all irrelevant. And we still learning how to do this, right? So it's still learning. Nobody knows how to do perfect code review. Some people don't do code review altogether. Some people do it occasionally. And there is always more than one way to do something, right? And of course, we all have different circumstances and we always have to remember about it. So what is this talk actually about? It's about how do we do code review? What are the common issues that we are facing while doing it? Tools that can either simplify or help us with this process make it better. A lot of communicational aspects which are involved in this process, and this is a very important bit. And how can we become better as the authors who are creating the pull requests and the reviewers who are doing the code review? Okay. So let me share some of the emotional feelings for myself because I'm sure everybody, when you start this career and you're like, okay, why do I even need something like Git? I just push the code to the files and that's it. Like why anyone has to review it? So I was not using Git for first couple of years in my career or any other version control systems and I was happy without it. I didn't felt like I needed it unless I started working without the engineers and then I felt the need. At first, I really, really hated the code review. Like it was always pain. Like you have to deal with comments. You have to convince your team members that whatever you're presenting in your code review actually makes sense and you want to have this in your code base. Pretty much you're asking people to commit for your changes. At some point, I've become kind of okay with the code review as a general thing. I started to understand why are we doing this. I was still not happy when doing it. I was still struggling but at least I saw a value and I finally start to understand it now. I think this is why I'm doing this talk because like I finally feel like I'm at the place where I know why I'm doing this and I see that other people are having the same struggles that I had previously. So maybe by sharing I can help them out. So we'll start with the like the previous talk was very technical and you go so fast. I'm sure people had some issues understanding all of it. So I would like everybody to be involved in this one. Okay. So we'll start with some questions and I also will be answering the same questions so you can just use your hand to show yes or no. I always use version control and again like let's not say about the first day when you just started doing this. Let's only consider, I don't know maybe last year or last two years in your career. So I always use version control for all the work I'm doing. Cool. Cool. That's really good. That's pretty much everybody. That's very good. All my changes go through the code review process. Okay. I would say maybe 15, 20 percent of people. Good. Good. At least we are honest, right? That's good. I said no by the way. I don't do code review all the time. I review and read every pull request made by my team. Okay. I see like five hands. This is terrible. Okay. We definitely have a room to improve. I enjoy doing code review. Oh my God. We're going to be here forever. I have to convince all of you that this is a good thing now. I feel great about getting some feedback and comments. Okay. This is better. People are happy with comments and feedback like maybe 50 percent. This is good. This is good. I review code by checking out the branch and doing the review actually on my machine, having access to the whole system, not just the diff that GitHub will show me. Okay. Like two hands. Nobody does this. We'll talk about this one. Okay. Cool. So my talk also makes some assumptions about your circumstances because what we're going to talk about here cannot apply in all the circumstances, of course. So I assume you are not a solo developer in your project because if you're a solo engineer, sorry, most of these things wouldn't apply. And I also assume that you have less than N engineers in your team because if we are saying let's try to review all the pull requests that are created and our team has 15 engineers, we're going to waste all of our time sitting and doing code review. So of course you have to have a reasonable number of engineers in your team. If you have more than, I don't know, five or six, maybe you have a different problem, not a code review problem. I also assume that you are using Git or other similar source control version systems and that you are using GitHub or again something similar, Bitbucket for example. And you're using pull requests as the main mechanism for doing code review. Okay. So why do we do the code review? This is again a short question. You can just scream your answers. Like the first thing that comes to your mind, like why do you even start doing code review? Don't break production. Okay. So it's partially QA stage of work, right? Okay. Anything else? Learning. Great. Knowledge experience, sharing. Awesome. Anything else? Come on. Don't be shy. Couraging mistakes. Okay. So again, it's partially not breaking, right? So we're kind of trying to do the QA work while doing the code review. Okay. Let me show you what I have in my list. So catching issues and bucks, make sure code follows our style guide, checking for performance issues or any other issues, like who knows what are your circumstances, what kind of requirements do we have to your project. Suggest alternative solutions. Even if we do something that doesn't break production, it doesn't mean that this is the best way to go, right? And knowledge sharing as usual. Okay. So we're going to go through some of those into more details. So first of all, one of the whys is catching issues and bucks. And usually when I have this kind of conversation, this is what everybody starts with. Everybody's like, yeah, we're doing code review to make sure our code is better. It doesn't have issues and bugs. Unfortunately, it's not true. In most cases, the level of QA that you are getting out of doing code review is very low. If you were like most of you said that you are doing code review, how many issues are found by QA? A lot, right? How many issues are still found in production after the code review and QA? Still a lot. So code review, we want to believe that by looking at code, we are smart enough to see the issues. Unfortunately, usually it's not true. When we do code review, we can see just small diffs. We don't see the whole workflow. So it's kind of good to catch something like syntax error, like someone forget to close. Yes? One of the distinctions that you may want to consider making is between code review for production code and code review for the tests against production code. It's been our experience that if we have our automatic tools fail and deploy if code coverage is less than a threshold, which is generally in the high 90s, then we spend our time reviewing the tests to say this is what we're testing for. These are the conditions that we're testing for. Mr. Domain Expert who's sitting on the other side of the virtual table participating in this. Mr. Domain Expert, do you know of any business rules that were violating or that were not catching? And that is far more productive for us than manually reviewing actual code. Yeah, sure. I completely agree. And again, this doesn't mean that you don't have to review and you don't have to try to find issues. This just states that even though we try, we usually are, we don't have the whole picture.  We just look at the dips. So catching like a syntax error, I forgot to close the parentheses or like maybe I have a possible nail and I forgot to check for it. That's kind of easy and can be done in during the code review. But catching integration kind of issues, like we don't have the system workflow. So it's kind of kind of hard to catch those. Okay. So another thing is we try to follow the style kind, some style guides. And this is a lot of comments in our code review comes from here. And I really, really hate when people start doing this because it's like, especially when someone new joins the team, nobody tells him, nobody on boards him about the style guide. And everybody jumps first in the code review to say like, oh, this is the wrong number of spaces you are using here. Like, oh, we don't use open and close parentheses in this way. So this is something that you have to do. But maybe code review is not the perfect place for that. You can onboard the person, you can have a separate repository with your style guide. And we'll talk about the tools that can be used for this one. Okay, so I'll show you a couple of examples of this. This is the only code that you will see in this presentation. This is just a couple of simple examples where we can just see what kind of issues can be highlighted during the code review. So does anyone see any issue in this one? Yeah, just typo, right? It's supposed to be a box. And we have a backs. So this is simple. We can easily look at this method. We don't need to see anything else in the system. We don't even care. Is it like a bab application or whatever? It's fixable. This one is a bit trickier. Again, anyone wants to guess what's the biggest issue here? This is not about syntax, by the way. Yeah. Well, the tricky part here is the map. As you can see, we're using where. So I assume it's an active record model. And we only need ID so we can use block, for example. Another good issue here is the name of the method says items. But we're actually only returning ID of the item. So maybe the naming issue here, maybe the method should be called item IDs instead. This one is just everything. The name of the variables are wrong. We use different parentheses and multi-line code and it's just crap.  And we can use a lot of tools to automate this. And it makes our life much simpler. We can use RuboCop. HoundCI is a great tool where you can specify your own style guide or use just the default one that Hound specifies, which is pretty good. We can use code climate, etc. And believe me, receiving messages from the bot is way, way better than receiving them from your team members. Because if you forget to put the space in the right place and the bot highlights this, you just go and fix it. You don't have any emotions around it, right? But if the same person comes again and again and says like, come on, Mick, how many times do I have to explain, put the spaces before and after and whatever. So yeah, use tools for that. For tests, hopefully you have continuous integration. So when you look at the PR, you already know if the tests are passing or not. You can also use GitHub templates. You just have to put the file called pull request template into the root of your Git repository. Every time you create a GitHub pull request, it will just automatically pull in a lot of data. I have a screenshot of an example that we're using currently.  I can do a checkbox to specify which parts of the system I have changed. I can put screenshots, et cetera. So let's try to make our pull request as descriptive as possible. So this is a different type of example. And you can try and find some issues in it. But I would have to say it's completely useless. Why? What can we tell about this code just by looking at this one small bit? Just imagine this is a pull request and this is the diff. This is the only line added in this pull request, for example. Unfortunately, we cannot tell what's going on here. We don't have the context. Why are we skipping it? In which cases do we not want to skip it? Why we only skip it for the delete? What's going on? So some of this context we can get out of the pull request description, maybe from the git commit message. Maybe you actually have to go and look up the ticket assigned to this pull request. But in general, it means that you need to get some context. Whether you get it, it depends on your case. So another good example. I have existing methods and for some reason I've added this line at the top. Same scenario. I don't actually change the business logic. Code looks legit. It will definitely work. I don't think it will crash. But why I'm doing this? What would be the end result of this? Maybe some of the workflows will stop working because it's okay to skip name in some of the cases. Who knows? So it's all about the context. When we are doing code review, in order to do it properly, we need as much context as we can get. So pull request is just a diff. Usually it doesn't have any context. Or you are really lucky if it has a context because, let's say, you're building a huge feature and all the code changes that you need to care about are actually present in the same pull request. And hopefully you don't have to deal with huge pull requests. It's a big pain. So unfortunately diff usually, I'm not saying always, but usually doesn't give you enough context to make the decision. This is why we have to get this context from somewhere to be able to produce a good quality of code review. So let's now switch to the actual process and who's involved in it. So we have the author of the pull request. It may be a couple of people. Usually it's just one person, but can easily be a couple of people. And we have reviewers. And as you can see in parentheses, they put that preferably it's the whole team. Again, we'll talk about this in the later slides, but preferably everybody can take a look and still manage to get some value out of it. Either this is a passive value, like me just understanding better what's going on, just to get to know what other team members are working on, or actually be able to suggest a better solution or find an issue before it actually gets deployed. So for the author, you have two main responsibilities. You have to provide what and why. So what is kind of easy? It's the actual code that you put into this pull request. This is actually what we see in the diff. But the why is a bit tricky. Expressing the reason why we're doing some changes. Usually you don't get a lot of those. And we'll try to go deeper into the details of this one. So improving of the what. So if you're doing a lot of commits, it's really cool if you can group your commits by type of changes you're doing. So especially like if you ever went through the code task before your interview, every time you would see the description and it would say like commit as frequently as possible, because your commits actually show us the history, what you were thinking about when you were doing this, in which order you were implementing features, etc. So the order of your commits and how you group the changes in the commits might be interesting. Move refactorings out of the feature changes. I try to do this as much as possible. Unfortunately, it's not that easy. Usually when I'm working on a feature and I look at the code and I try to realize what exactly what I need to change, it looks like this. Oh, I can just do 10 different things and make the code simpler. And then my actual feature would be just one small line over here, or one additional small tiny class over there. And if you produce this refactoring and implement a new feature in one code review, it's kind of tricky. It might be tricky to understand why you're moving the bits from one place to another, etc. So the perfect case scenario, you split those into two. You do refactoring first. It should be very straightforward. You don't change the logic. Perfect case scenario. You don't even change the tasks. Everything is still passing. You're just making the interface cleaner. Then the next pull request, you do the actual feature change. And hopefully this pull request again will be unbelievably simple because your refactoring prepared us for this change. Moving other fixes or improvements into separate pull requests. So again, unfortunately, we all have to deal with some old code bases and they're not always in the perfect shape. Perfect shape. So as you go through the code, you usually find some low hanging fruits like, Oh, I can fix something here. I can improve performance there. Maybe I can update this jam. So you end up pushing a lot of small tweaks and changes into your feature branch. And sometimes it's okay. If it's still logical and simple to follow up, it can be okay. But again, in the perfect world, hopefully you can highlight like, Oh, I can move this into a separate commit. I can move this into a separate pull request. Again, it helps us to create the smallest pull request possible. Because I'm sure when you have to review something, the first thing that you go and take a look in the get is like, how many files have been changed? And when that number is around like 40 or 50, you're like, Oh, my God, I'm going to get stuck with this pull request. And other people would just say like, Oh, my God, it's 50, 50 files being changed. There's no way I can review it. Like I'm just going to scroll, scroll, looks okay. Done. This is not a good code review, right? So in order to get a good feedback, and we want to get a good feedback and get some sharing, we need to make the size of the pull request to be manageable. It has to be reviewable in a small chunk of time. Like I have a time between my features or between my meetings, I have 15 minutes, I jump in, I do the code review. So now we'll talk about why and like, so why are we actually making the change and how to express this in the best, in the best way.  Maybe they're not that important during the code review itself. But what happens after it's already merged? And like, two months later, we have a bug in production. And we go back and we take a look at the, at the git blame. And we see a commit message.  And the commit message is like, fix spec or fix that fix again, fix broken spec, et cetera. You know all of those commit messages, right?     In pull requests, you can do this in the UI, which is unbelievably easy, or you can do this in using your git, you can actually squash them and change the commit messages or provide completely new one or just combine all of the commit messages into one. Sorry. Again, so with the commit messages, what I usually recommend people doing include the ticket number. If you're using Jira or something similar, usually your tickets would also have a lot of useful information for the reviewer and for the people who would have to support your code, right? So put the number of the ticket into your commit messages. It will make it that simple to find and understand why the particular change was made. You can also add your comments to your own pull request. I do this all the time. I create the pull request and I look at the diff and I'm like, hmm, this bit, I'm sure someone will be confused by it. And I forgot to put any comments into the code itself. Maybe I can just comment on the pull request. And this is more than fine. Use the pull request as the place where you can express your thoughts. Some people would say you that leaving comments in the code itself is bad because as you change the code, you usually forget to change the comments and now your comments are expressing your previous thoughts and the code already moved forward. So yeah, comments in the pull request are more relevant because you're making them to the actual change itself. But still you can of course use comments in your code. I know a lot of people don't like to do this. A lot of people would start screaming like if your code needs comment then it's a bad code. The code should be unbelievably readable and easy to understand. Yes, in ideal world that might be true. Unfortunately, we are not in ideal world. So don't be shy. Put some comments in. And small versus big changes. Again, the smaller the change, the easier it is to understand why it's made, what are the implications, etc, etc. So try to always keep your change as small as possible. It's easier for you. It's easier to whoever is reviewing your code. So when you're doing the review, you're the reviewer, your main thing is your feedback. This is your your sword and your shield. This is what you use in order to go through the code review, your feedback. So feedback is a key here. And feedback doesn't mean critique. A lot of people think that if I'm asking you to review my code, it means I'm asking you to tell me what's wrong with it. That's usually not the case. Code review is not just about finding issues. It's about a lot of things. It's about providing positive feedback. Like, oh, today I've learned something new because I saw you used it in your pull request, right? Oh, this. I don't like this. I put in the comment and the guy responds and I'm like, yeah, he's right. My initial idea was wrong. He's actually right. I learned something, right? And then again, sometimes we use we use comments, right? So we usually write and unfortunately written communication is very hard. Okay, it's unbelievably hard. Like, imagine we are sitting together and we are pairing, right? And I look at the code that you just put in and I'm like, Oh, my God, this is terrible. I have a great idea. I'm excited. You're excited. We are sharing no issues whatsoever, no offense, right? Now imagine I come into your pull request and I'm saying, Oh, my God, I have a much better idea.  The first reaction would be like, why are you offending me? And like, you don't see my smile. You don't hear the tone of my voice. You just see the bare words. And usually it's really rough, especially if your team member doesn't actually select the proper words to do this. So sometimes written communication is very harsh. And we just have to remember this because it's very, very easy to forget. You're just like, Oh, this is wrong. And you just put like, this is wrong. Do it this way. You're putting the command. You're not giving any alternative solutions. You're not asking. You're just saying what to do. This is not a feedback, right?  And because we usually only leave comments for the bad things, it looks like we hate your pull request altogether.  When you review, there's a lot of good bits.  It's okay.  They look at you and they hope that you would give them some feedback. And of course, you need to have a checklist. Like the checklist, I don't care if you put it down somewhere on a piece of paper, or you use the GitHub pull request templates as we do, or you just have a verbal communication about this checklist. But checklist is very good. And what is checklist? So for checklist are some critical aspects of the change that you can do in the code base, which definitely require a more deep review. So like any DB changes are usually very critical because what if you do migration, which is not reversible and something goes wrong? Like you have a downtime and now you have to somehow manually restore your DB, which is terrible. What if you're doing data migration? This is always very, very sensitive because you can lose data, right? So there's definitely aspects of review where you need to pay more attention. Rake tasks, again, whatever you do, at least don't forget to write them if you have a post deployment rate task or something. Upgrading any libraries. I don't know about you guys. I've been in a hell with updating of some of the libraries, especially libraries which would have some kind of third party integration, like uploading files, for example, like paperclip or something like that. When you upgrade the libraries, usually what I do, I actually look at the change log between the version we were using before and the version we are trying to use now. And sometimes I do find some breaking changes. So it kind of works for us, but there are breaking changes and who knows what will happen when we deploy this. Any API changes? Again, like your API is your contract with your customers or clients or third party integrations. So whenever you're doing any API changes, you always want to check if you are not breaking any compatibility. Any deployment or infrastructure changes? Again, like ops process is different everywhere, but it's always critical. It always means you can have a downtime which is terrible. And like cleaning up the related code, like imagine, again, like I went in and I updated the version of the gem, right? Everything's fine. The review went in and then suddenly someone says, like, oh, we actually had a monkey patch for that library because we wanted this feature, but we were not ready to upgrade the gem. And we still have it, unfortunately, right? So sometimes, again, you do need to have a context because you don't see those changes in your diff. So you need to check out the branch. You need to go in and say, like, oh, we're changing something. Like maybe there's some code that was depending on it that now we no longer need. We can clean it up. And those are usually very, very hard to do. And like, believe me, nobody can do this properly, unfortunately. And yeah, keep updating your checklist. Our checklist has like maybe 15 items. And we kept keep adding in as we are facing some issues. So this is like the hardest part of all of this, like dealing with a negative feedback. When I was starting the talk, you all said that you're using pull request, but only 50% said that they actually enjoy the process. And in most cases, we don't enjoy this process because of a negative feedback. So try not to judge. This happens to me all the time. I read the code. I'm trying to investigate an issue.  Like, like, what was he thinking? And then I do get blamed. And of course, it's my code. Yes, that happened a lot. And it will keep happening. So yeah, just don't judge because you don't have all the context yet. Try asking questions.  Do it this way. But this is this will be very, very harsh for that person. Maybe that person was in a rush. Maybe that person is very inexperienced yet. And by giving this feedback, I'm pretty much killing the morale, right? But it's so so much easier and so much nicer just to ask a question saying like, Hmm, what do you think about changing it to and you present your solution? Or have you thought about this way of doing this? Or what was your reasoning behind this idea? Try to engage people into conversations. Don't just say no, and give options. In a lot of cases, what people would do if they see that something's wrong, they will just scream about it. Like, this is terrible.  Or this is terrible. This opens up some security vulnerability. But in a lot of cases, the person who's leaving that comment doesn't actually have a better solution. And if you don't have a better solution, you have to be very, very delicate with this.  I know it better. When you actually don't know it better, right? So you're not sure. Maybe the person is already aware that this solution has some drawbacks. But because there is no better solution, and nobody can produce a better solution, this is what you end up dealing with. Okay, suggest alternative solution. If you see that something's wrong, and you do have alternative solution, present it, say like, send the links, it doesn't even have to be your solution. You can just say like, Hey, I'm following this cool guy and he posted this cool blog post that actually highlights the better way to do this. Share this, actually post a link, let the person get to your level.   No, share. Start the conversation instead of just commenting on each line. So sometimes when you look at the diff, the number of things that you would like to change is so huge that you actually end up commenting on pretty much every line of code. This is a very bad sign. This is a red flag. That means stop reviewing right now and go talk to that person. Maybe there was a big misunderstanding and the person is actually trying to solve a different issue or the requirements that were set incorrectly in the ticket or something like that. So if you see that the amount of communication will be huge, it doesn't make sense to continue it with the comments. First of all, because it's non productive. Second of all, as I said, written communication is very hard and having a dialogue in a written communication is just terrible. So just go talk to person. If the person is remote, thanks God we have a lot of tools to deal with the remote calls, etc. So usually if something's wrong, it means you don't have the whole idea or the whole list of circumstances around you. So you always have to take circumstances into the consideration. So again, circumstances are part of the context. Imagine we have a terrible deadline. We have to deploy it right now and you start telling me like, maybe we can change because I don't like the naming. This is not the time. I need to deploy right now. We can change the naming at any point. Just come back to me later and we'll talk about this. So circumstances are very important and they build this context around your change. And the context can be very different. What is the source of the original code? Let's say I'm backporting a feature from a newer version of Rails back to my old project. Right? I'm actually introducing this code but I am not the author. I don't want to change it. I want to keep it as it was in the Rails even if I don't like the naming there or the space and not in the right way. Who cares? This is not my code. I'm just moving it so I'm not going to change it. Time and complexity constraints. Sometimes we just don't have time to deal with something better. Sometimes we have to rush and produce the value right now. Sometimes the complexity of the change is too big and we don't want to spend too much time on this because every change has its value. If I'm going to go in and say like, oh, we have tabs in our code, I'm going to remove it and put spaces in, maybe it's a good change but does it actually produce any value for us? Does it improve our quality, stability, performance? No. So if you made a mistake and put a tab instead of two spaces, it's okay to fix this one line. But asking someone to go back and do a bunch of crazy changes just because we would like to see it this way might not make sense. So always think about the return of investment. What we will actually get out of this change? Is it going to be more readable, more maintainable, more testable? Those might be the values that we might spend some extra time in order to get those. What if I'm building just the proof of concept? I'm sure that the level of review and your comments would be completely different if I would just say this is proof of concept. I might just remove this completely tomorrow. Or if it turns out to be a nice idea, I will keep working on it, I will keep improving it. Same with minimum valuable products. The level of your review would be, again, different. It's no longer just the proof of concept, so it has to work. It has to be somewhat readable maybe, maybe not very readable but still. It has to actually perform because if it's going to kill our servers, it's not a good value. So there's a lot of danger of giving this negative feedback if we don't take into the consideration all the possible aspects. So we are demoralizing people.  People start being afraid to do this. It's counterproductive because instead of actually getting the value out of it, you're demoralizing people. It doesn't encourage an open environment. So by open environment, I mean environment where you can easily express yourself, where you can submit a pull request and if it's crap, people will give you a proper review. They would say like, I like your intention. I like what you're trying to do here, but this is not the right way or this is not the right time. It also limits the knowledge sharing because if you're just saying no or just blindly suggest another solution without explaining why you're doing this, then technically that person will do the right thing, the right thing, but it might not actually share the knowledge. So the person might do the code change without actually understanding why this is a better way. Another problem that I see a lot is the senior versus junior. So by senior and junior, I mean it can be the level that you are on or it can be number of years that you have spent working on the project so you know the domain or you know the product. So for seniors, seniors usually feel like they have to provide a lot of feedback. They kind of feel like that if a junior engineer submits a PR, it's their responsibility to come in and just crush them, to show them that they know nothing, they have to learn, learn and learn. And it has to be negative because positive like he's learning, so he needs to produce some positive results, but I'm going to highlight the negative stuff. And they feel like they have to find those issues. So even if the PR is kind of okay, maybe it's not perfect, it's kind of okay, we still get this feeling like this can be improved, this is not perfect, this is not perfect, and we keep pushing those comments. And it can be okay, but in most cases it's just too much. For juniors, they're just kind of afraid to provide the feedback. So imagine I'm a new comer in the company and someone submits the pull request and I see something that I don't understand or I don't like, but I don't have a strong feeling about it. It's just like, I'm not sure. In an open environment, I would just freely just stand up and say like, sorry guys, maybe I don't understand something, can you explain this? In the closed environment where everybody only communicate via these negative messages, it would be pretty much impossible and people just close down, they're too afraid to ask those questions.  And they are also afraid to look smarter than the senior engineers.  So we have to remember that code review is not a competition because a lot of people try to compete in code review and this is a terrible idea. So the speed of code review is irrelevant. If your code review is getting merged after five minutes, it's cool. If my code review stays in code review for two days, it doesn't mean that it's terrible.  So just keep remembering, you don't care about the code review speed and you don't care about number of comments. If someone posts a lot of comments in your pull request, hopefully you learn and you don't just submit negative comments, it's a good thing. It might be a great knowledge sharing. It might be a great discussion. You might actually produce a better value. So the fact that nobody comments on your pull request doesn't actually mean that you're super cool and nobody complains so your code is perfect or something. And yes, some people use code review just for showing off and I hope you don't have to deal with people like this. But unfortunately, sometimes you do have people like this, people who don't care about most of the values and only care about showing that they are better. They will produce a very complicated solution. They will send you articles to some really, really fancy algorithms, et cetera, et cetera. They don't actually care if you listen to them. If you implement those changes, they just care about showing that they know better, that they know more, et cetera. So this is a red flag and we'll talk about this a little bit later. And code review cannot be personal. So if I'm putting a lot of comments into your code review, it doesn't mean that the next time I'm opening the code review, you have to go and say, like, hey, it's revenge time. Now I'm going to leave comment for every line of your code.  It doesn't have to be personal. But it becomes personal because we only do negative feedback. So we are hurting other people and eventually they want to hurt us back. And this is very, very terrible. This is killing the culture. This is killing the spirit. So it cannot be personal. If you see that something's personal, it has to be managed. It's not a code review issue. It's your team issue. You have to sit down and talk about it. In some cases, sorry, I have to drink too much talking. In some cases, people have issue with domain expertise. So imagine you're working on the product and only one guy knows how the payment system works. Come on, I'm sure you all have examples of this, right? So what happens when you need to touch the payment system? You either ask that guy, and when he does the change, nobody wants to review it because nobody knows how it works, or you're doing the change. And the only guy who's doing the code review is your domain expert, which is a bad position to be in because first of all, come on, buzz factor, right? The guy can move, can get sick, can go on vacation. Second of all, the code review is supposed to be open and everybody in the team is supposed to participate. So if you only have one guy knowing something, it's terrible and it already kills this idea. And again, code review is supposed to help you fight this problem, right? If I'm doing the change to the payment system and that guy comes in and crushes me, I'm actually learning. And everybody who's looking at this pull request, even if they don't have any comments, they can see my change, see the feedback from the guy who actually knows what the payment system is about, and they can learn. They can figure out how it works. So during the discussions, again, like there's no silver bullets, there's usually more than one way to do something. So we have to agree to disagree. There's more than one way to do stuff. And it's all about trade-offs.  We learn as we go. So hopefully if you, let's say you have a junior engineer and he does something not very smart and you highlight this and he fixes this, you should be fine, right? Because hopefully the next time he does the same kind of change, he will already apply the knowledge that he got from the previous code review. If he doesn't, it's a different problem. It means maybe this person doesn't care, doesn't want to learn or can't learn. Again, it's not a code review issue anymore. And yeah, we learn by asking questions. If you see something and the code is perfect, it doesn't mean that that's it. You can still ask questions to have a better understanding, to ask anything. Seriously, I try to keep asking questions. It doesn't actually have to be a comment in the pull request. You can just walk to that person and say, like, hey, I actually enjoy your pull request, but I'm not sure I fully understood this part. Maybe we can walk through it, just talk about it. And yeah, if you ask questions you learn, but if someone asks you question and you answer, you share your knowledge, you're building a better team around yourself. So it's always a benefit. So of course, there are some complex cases and the things that I shared in this talk cannot cover everything. Of course, I'm sure there's a lot of cases in which this doesn't apply. But there are some complex cases which you can still deal with. So if you have a very, very complicated change and unfortunately you fail to split it to multiple pull requests or you fail to make the code change small and it's, as we said, like it's 50 files, 40 files of change, code review won't be effective. Even if people go through it and say it's a proof, usually people didn't actually pay much attention. It looks okay. So what you can do instead, you can do a code walkthrough.  And it's really cool and it's a really powerful thing. In-person communication versus flood of comments. Sometimes I receive an email every time there's a comment in pull request. So if I see there's a pull request and there's like more than, I don't know, 10 emails already, it means maybe we need to discuss this outside of pull request. Because again, written communication is terrible. A lot of people asking the same questions. It's not real time. So I can ask you a question. You respond in an hour. I already forgot why I was asking this, etc. So just taking everybody involved in this, spending 10 or 15 minutes talking to them is usually way more efficient than continue this huge discussion. And again, maybe this PR is too big and this is where your issues are coming from. So try to keep it as small as possible. In other cases, you might have suggestions or questions which are not actually in the scope of this ticket. Right? We cannot fix the whole system. We always try to produce the best possible code, but we cannot fix the whole system in one pull request. So sometimes if your pull request is touching too many parts of your system, people start suggesting some changes which are not actually in the scope of this ticket. Maybe they're suggesting the refactoring that can be introduced later on. You can just fill in additional tickets for this refactoring. Thanks. So red flags are just things that would highlight that code review doesn't work in your team for some reason. So people committing straight to master. I don't think I need to explain that this is a bad idea. Ignoring comments on pull request, unfortunately this happens. People might just ignore your comment or your question and just merge right away. A poor communication in pull request, meaning that it's mostly just negative feedback and I'm suggesting something and the person just responds, no. This is a very poor communication, right? The person might have a great idea and great reasons why he doesn't want to continue this or why he doesn't want to take a look at my approach, but by not expressing it explicitly you are just killing all the communication efforts. So code review is a team effort, right? We want everybody to be involved. It's not a one main game. If it's a one main game then we are losing pretty much at least half of the benefits. We're not getting the sharing of the knowledge, etc. So it's a team thing. Everybody should be engaged and this is why I said that if you're a solo developer or your team is too big, those things wouldn't apply because you cannot expect the team of 25 engineers to all participate in code review. It would be just crazy. Code review is a team responsibility and by this I mean that if you do the code review and it actually passes, it means that it's a team decision. If I'm reviewing and I'm emerging, this is my decision. If the whole team is reviewing, it's a team decision and the difference is very, very important. If something goes bad, if something turns out to not work or breaking production, there is no fingering anymore because we all did this decision. We all participated. We all had our chance to express what do we feel about this code. So as a result, the team owns this code, not the pull request author. This one is very hard because most people would never say yes to this. Most people would say like, I don't like his code. I don't want to be responsible for his code. But again, this is not the issue of code review. This is the issue of your team members and communication. This is a team sport, so the best case scenario, everybody's involved, everybody commit, everybody's responsible. If something goes wrong, everybody just jump in and fix it. There is no fingering and saying like, this is your issue. I don't care about this. So as a summary, sorry, I didn't expect this to take so long. We have to try and learn to understand each other. We have to respect each other. This is again about negative and positive feedback. We have to respect each other and we have to help our team. By helping our team, the team is helping you. Code review is a team sport. Thank you. Do we have some time for questions? Okay, one question. Two questions. Sorry, that guy was first. Go on. Okay, cool. So I think we need to cover the topic of having PR and speech. So yeah, obviously my team has the same issues and what happens is one person will get it and the other person will get someone else to say, okay, we will come in. So I think we need to cover one of the ways to look at such PR is to review the work together to walk through. I'm just wondering if we have other and I'm sure this is something unavoidable. We are bound to be some teachers who are so huge and we have to think about it. Okay. Let me repeat the question because I'm not sure everybody would hear it. So the question is what do you do when unfortunately your PR is too big and people are struggling to review it? So if you already are in this situation, I would say it's too late to change anything. So this is something that you have to do during the planning. When you are planning this feature, when you even start thinking about it, you have to think is it possible to split it into the chunks? Is it possible to implement this in phases? What would be the minimum possible and valuable piece of software that I can deliver that would produce some value without building the whole thing in one go? If you have to build the whole thing in one go, then again, sometimes what we would do, we would do PRs for other PRs. So you create a feature branch and let's say you have to change, I don't know, you have to do database changes and your API changes and some business logic changes. So you create a feature branch and then you only do the DB changes. You create the PR against the feature branch, not your master or development. Then on top of that, another person can do a change for API, another pull request, another pull request for something else. So you kind of artificially splitting the work, even though it's not deliverable as a small piece, but you split the PR into three phases. It's really tricky because usually it means that when the first PR is merged, you have to rebase all the other branches to take those changes, etc. So it's not a very nice and convenient way, but at least it's something. So sometimes we would do this. We would actually create multiple PRs against the feature branch and build it step by step. But yeah, try to fix this issue during the planning. If it's possible, try to plan ahead. You can actually see, oh my god, it's going to be huge and whenever we get to the testing of this and code review, it's going to be just unmanageable. Thank you, Mike. So we're running short of time. Yeah, sure. If you have any questions, just approach me after this.


Hello and welcome to Dataversity Talks, a podcast where we discuss with industry leaders and experts how they have built their careers around data. I'm your host Shannon Kemp and today we're talking to Dr. Wendy Lynch, the founder of analytic-translator.com. With a robust catalog of courses offered on demand and industry leading live online sessions throughout the year, the Dataversity Training Center is your launchpad for career success. Browse the complete catalog at training.dataversity.net and use code DBTOX for 20% off your purchase. Hello and welcome. My name is Shannon Kemp and I'm the Chief Digital Officer at Dataversity and this is my career in data, a Dataversity Talks podcast dedicated to learning from those who have careers in data management to understand how they got there and to be talking with people who can make those careers a little bit easier. To keep up to date in the latest in data management education, go to dataversity.net forward slash subscribe. And today we are joined by Dr. Wendy Lynch, the founder of analytic-translator.com. And normally this is where a podcast host would read a short bio of the guest, but in this podcast your bio is what we're here to talk about. Wendy, hello and welcome. Well, thank you. Thank you, Shannon. I am so happy to be here. Thank you. We're excited you could join us. And so you are the founder of analytic-translator or analytic-translator.com. So what is your company and what is it that you do? Yeah, I have two jobs. So I am an independent consultant. So I consult with large organizations about applying big data to human capital management issues. So that is sort of my day job, I would say, where I actually act as an analytic translator most often. Then as I realized how much we need this role, I launched analytic-translator.com and have a book to help other people learn those skills to try and fill the need. So what is an analytic translator? The easiest way to think about it is it's a person who speaks nerd and business. That's the way I explain it to people who aren't in the field. But it's really three basic skills. One is that you have the ability to understand and listen to a business person or a business team in a way that you can hear and define what problem they are trying to solve that perhaps data could actually contribute to. And that you will translate that into words and tasks that data people will understand. The second thing is that then you know how to understand what the answers are or the problems are or the challenges have been and translate it in such a way that the business can make use of it and really comprehend what you're trying to tell them. And then the third thing that happens as a side effect is to build alliances between these two teams. Because I'm probably not the only one who has watched those relationships start to get tense or worse when you have the business and the analytic team not understanding what each other needs. Makes sense. Very big need for that indeed. I'm sure as we'll talk about more. So but tell me before we get into that. So when you were very young just a child.   I was raised in a family of real nerds. And so I had a theoretical nuclear physicist and a microbiologist parents. So I think I only kind of new science and so I thought I wanted to be a marine biologist. That was what I thought I wanted to be because I thought dolphins were cool. That was that was where I started I think so. Yeah. Unfortunately, I get seasick looking at boats so that. Oh no. Yeah, that wasn't going to work so yeah.  Um, let's go to college. You know what did you where did you go and what did you think about what was your initial major. Yeah, I one theme that you will hear today is that I changed my mind a lot. So, one of the things that I was really into as a younger person was I was very into sports of different kinds played every sport I was allowed to play. And I really was interested in exercise physiology and those kind of things but I first I changed around to a variety of majors from pre med to engineering to this to that and the other. But I did land on what was called kinesiology which is the study of human performance, and I did an undergrad there and really thought that that was going to be my area. And when I went into a master's program. This was one of the first of two mentors that changed the course of probably my life at least my career. I ended up doing work with the person who was the chair of the department, and he was the stats and research design guy. And what I figured out was if you worked with as the stats and research design person, you got to do research with everybody. And I wonder if this was the person who studied enzymes in muscle tissue, or if this was the person who measured push ups or this is the person who measured VO2 max and, you know, endurance performance. This guy got to be the one that analyzed all the data and could look at everybody's project. And I went there for somebody who changes their mind a lot. And this was the perfect skill. So that's what I ended up doing was getting into the measurement part and the research part and the stats part, and then went to a doctoral program called research and evaluation methods, which was really cool and disciplinary so you did stats from epidemiology and stats from econ and stats from meteorology and stats from all these different things and to non nerds that won't sound exciting but to me. When you got to know all the different languages, you know, an epidemiologist calls it something and educator calls it something else. One will always use logistic and one will always do an over, you know, I mean it just is how they're taught, but when you understand how all of them do it, then it makes even more sense I think. So that was, that was my sort of college trajectory. I like it very impressive, very interesting, because you're right. Yeah. I love it. So, after school then. See, you've, you've got this now deep dive into a lot of data. Yeah. So where did you go from there. Well, continuing on the theme I wandered around a lot. I, I actually have been in large business like a large insurance company. That's where I went first where they were doing the first on site health and fitness facility that ever was put together I think. And they wanted an evaluator on site to look at the impact of that on business outcomes and health and costs. So I started there, but I have since been in pretty much every different type of location. So I went from there to academia, because I wondered if maybe that would be a better fit for me. And what's what you find is in academia you can ask any question that you want. So you get a lot of freedom, but you don't have a whole lot of money unless you can get a grant. So in business, when you're starting out you don't get to ask everything you want because someone tells you what to ask, but at least it's funded. So I bounced around a lot so went to academia, worked in startups, worked for large consulting firms, worked in big industry, worked on my And it was funny because people would say, I thought you worked in healthcare, or I thought you worked in insurance. I thought you worked in HR. And my mom would be like, I can't explain what you do what do you do. And it was the same thing that happened to me in school is I was just interested in so many different things. And I didn't realize that what I was doing was actually the same thing all the time, which was, I'm a sense maker, and a translator. And it doesn't matter what the topic is. If there is somebody there that can help each side talk to each other. It starts to make it adds value to the situation and I didn't even realize that until five years ago that that was what I was doing. So what did bring you to that conclusion. The other mentor that I'll mention that changed the trajectory of my career is a person who was in the Department of Family Medicine with me. And her role was to help new physicians, the physician students learn to talk more effectively to patients. And she had studied all of these different aspects of effective communication. I mean, just about, you know, 100 different theories of communication. She was so good that I just glommed on and said, could you tutor me, could you help me understand what it is that you do that makes it work so well. And we've ended up being lifelong friends. And she, and I co authored a book that came out in 2017 called get to what matters which is a communication book, which feels very adjacent to what it was that I was doing and I felt compelled to get it written and disseminated because I feel like those skills have probably been as if not more valuable in the field that I was in than the analytics skills. It wasn't until I heard a podcast actually in 2017, and the podcast host said to this woman her name is Greta. I'll get it to you anyway. I was listening to this podcast, and she said that the host asked her, are, will we not have enough data analysts, you know, good data scientists to fill the need. And she said, Oh, no, no, no, we're going to fill that need just fine. What we don't have is we don't have people who know what questions to answer and know how to figure those out. And I just went, Oh my God, that's me. That's what I've been doing. I've been translating this is so cool. So that's how I figured it out. And then during COVID. I actually was thinking about what I wanted to spend my time doing while we weren't traveling and doing conferences and stuff. And I really thought, you know, it's time to put it into a format that people can use and learn from. It's very cool. So, and just a couple of highlights here, I mean, I love that you have so many interests. And of course, data enabled you to explore so many things because that's what it's so great about data right is everybody say everybody uses it. And the diversity of, you know, companies in our conferences, it's just amazing always it just, I love, you know, some of the companies that we get a chance to work with. And then, you know, what brought you here is being curious in exploring and being open to new possibilities, because I love that I love that. I found somebody who just inspired you and motivated you to reach something for something new and tie that back into to data. Yes, I think I, I think it's important, especially if people are just getting into their careers. I realize that there are so many people that you will run into who have something incredible to teach you. And you will learn from what they offer you. And you will learn from what it is that they are doing and what they've accomplished. So it's, I think we often get into our own heads about what we're doing, and we can learn from what I mean, learning from you guys at Dataversity, the incredible things that you guys are all doing. That's what's so wonderful about your platform. Oh, and likewise. Visit Dataversity.net and expand your knowledge with thousands of articles and blogs written by industry experts, plus free live and on demand webinars covering the complete data management spectrum. While you're there, subscribe to the weekly newsletter, so you'll never miss a beat. Wendy, with your background, so what is your definition of data? Yeah, yeah. Data to me includes signals signals of an event or of an amount and something that's detectable that documents that a behavior or an event or a occurrence has happened. And usually that ends up being collected and put into a format that's usable. But I want to expand that just a little bit, because if I'm having a conversation with you. And you are telling me what you need to accomplish with a particular business question. I noticed that Shannon has a confused look on her face. Or I noticed that Shannon doesn't sound completely confident that we are getting to the point that she's trying to make that that is that is also a piece of data. And so we are always observing and whether I record. Yes, I think she gets it or no I think there is more for us to talk about that is still data. So it's, I was thinking about that question. And I know that there are official definitions but any signal is a piece of data. I think that's very true. I love that definition. So any signal, and you may use it or you, you may not you may record it or you may not but recorded structure data obviously are the things that we get to make sense of and connect with other pieces of data and those are the things that are so important and useful. And so these other human ones that we have to make use of too. And we do whether we know it or not right processing so much, right, right every day. You may find yourself very irritated with somebody and whether you're noticing exactly what signal irritated you or not. We do take all those signals. Yes. I love it. So, and you see the importance of data management and the number of jobs with data increasing or decreasing over the next 10 years, and, and why I think that it will increase for sure. I think the reason why jobs that need to incorporate data will increase is just because it's becoming ubiquitous and every organization is understanding and learning how to make better use of the data that are available to them. The difference that I'm hoping will happen is that we won't necessarily silo the jobs into data jobs. I mean, I know that we all get irritated that data sets are siloed makes us crazy that we can't put these data with these data and I mean it just makes you nuts. In some ways, we silo the data people to. So there's a group of analysts who report to a lead analyst and those analysts, then get, you know, deployed to go work with other groups. And in some ways, wouldn't it be better if you had folks who have dual roles. Rather than just being data people and some companies have that to a certain extent or you may have a data division that's within one group that's different than in another group. But I do think we're going to have to be dual trained in the future, much more so than we are now, because it doesn't work data aren't useful, unless they're in the context of people and the organization. And you don't have. You don't want to have people only certain people who deal with people and only certain people who deal with the business and only certain people that deal with with data. So I, I'm hoping that as we grow. We ask for people to find two things, let's say, or, or more that they, they want to do. So what advice then would you, and we've kind of touched on this a little bit but what advice would you give to people looking to get into a career in data. Well, I think. First of all, realize that no matter how smart and trained you are today. Everything that we know and do today is going to be outdated tomorrow. So that's not a bad thing. But if I still, if I still only knew how to do the things that I knew how to do when I got my PhD in 1986, we would be in deep trouble. Everything moves so quickly and it's getting faster and faster and accelerating accelerating so don't think of yourself as I am only X, I am X on my way to whatever. So think about what you're interested in and where you want to be continuing to learn. So I think, I think that's the first thing is know that this is, this is a journey this isn't that you haven't gotten there and you pretty much never get there. And once you think you're there, you're in trouble. And I've seen people decide, well, I'm going to retire because I, if I don't retire. I have to learn something new. And what a sad situation but that there's a lot of people who are like, look, I'm too old to do that. Well, you better not be, especially in this field. There's just so much to learn. The second thing is also more of a perspective issue which is no matter how unique a question is to you. Somebody has probably thought of that question before, and has learned a whole bunch of really cool things, and may have applied it in a way that you haven't thought of. Be a student of a new area, because it doesn't reflect badly on you that you can point to how it's been done 10 other times. It actually makes you more valuable because you save people a lot of time not reinventing the wheel. You have a perspective. You have somebody saying, well, why don't we try X you can say, well, you know the four people who tried X didn't do very well but if they, you know, shifted it a little bit, they did that it worked even better. So I find that we get quite myopic about our company and our approach. But if, and now there's no excuse and we don't even have to go to the library anymore which is what you used to have to do. You can get on to Google scholar you can get on to research gate you can get on to a variety of different sources and just wander around there and find it. So, you know, find the thing that you're interested in, but keep your eyes wide on the things that you can learn from everybody else. That's great advice. And I recently read a study that you continually learn and go after trying to learn something new almost daily. Have a reduced risk of dementia and Alzheimer's. Oh, wow. Yeah. That's pretty cool. Right. It's good for you. Yes. Health benefits. And I'm finding that that advice is pretty, pretty common. But yeah, it's great advice and it's so hard to push our boundaries and it's so hard to, to be curious and to, but yeah, you're right. I've met some people who think they are the, the center of knowledge and but there is there's so much to learn from so many people. There is. And I have seen some people report research findings to an audience that's been around a while, who are just looking at them like really you think this is new, you know, you did that back in 1997, you know, or whatever.  Indeed. Well, Wendy. So if somebody wanted to reach out to you for consulting, how would they reach you. Well, you can reach me at Wendy or Wendy at analytic dash translator calm, or Wendy at Lynch consulting LTD calm. I'm also on LinkedIn easy to find. So, and I'm always looking for other people who are curious and interested in trying to solve tough problems so happy to hear from anybody. I love it and your books are on your website. They are on the website and they're also on Amazon. One is become an analytic translator. And one is get to what matters. I love it. And we'll grab those links from you and post those on the podcast page as well. So, Wendy, thank you so much for taking the time to chat with us really appreciate it. All right, thank you Shannon I really appreciate being asked. And to all of our listeners out there if you'd like to keep up to date on the latest podcasts and in the latest in data management education you may go to data diversity net forward slash subscribe till next time. Thank you for listening to data diversity talks brought to you by data diversity. Subscribe to our newsletter for podcast updates and information about our free educational articles blogs and webinars at data diversity net forward slash subscribe.


Welcome to another episode of frightfully forgotten horror movies, but before we get started what are we drinking today? We are drinking Wolf Creek. It's an Australian sparkling ale nice today We're gonna be talking about 1976's Alice sweet Alice this movie is written and directed by Alfred soul one of the only movies He's ever really directed he's done a couple of things But this is the only one of note a very very young Brooke Shields is in this Paula E. Shepherd is in this She wasn't in much.    Yeah?  Pistons? Brought some cake for you fatty Take some of the cake off the far for finger licks it a little sexually right so it's okay What's going on here Alice and the aunt just are not getting along Everybody's pointing the finger at Alice right because she's maybe a little odd the dad doesn't believe it So he kind of wants to do a little bit of investigating on his own He's called in to the the detective's office and he they start grilling him about his daughter And he's kind of like well, I don't like where this is going her mother gets Alice to go up To mr.  I have your daughter's necklace. Meet me at this warehouse. We're yeah It's really creepy.  She's like reaching purity.  Yeah, and yeah, everybody just keeps taking everybody else aside not hers And she wants the right type of attention because the attention that she gets in the movie By mostly men is not the right kind of attention.  She's just asking for it. Yeah No, that's not the type of attention a little girl wants, right? The movie also touches on I think the corruption of religion, right? Yeah, the ideals of religion how they're supposed to be so You know innocent and they're supposed to uplift people Well, it's not exactly what happens in this movie that has the opposite effect But that is also what does happen in real life. This killer is taken Yeah, these ideals and twisted them into their own weird morality the theme of what makes a family a family Because in this movie, it's like a broken family. We have you know, the father is kind of he's moved away He's got a different wife and she's left with the kids by herself and she's kind of Looked up down upon a little bit because well, she doesn't have the perfect family But it's also realistic because families like that exists. Exactly.  Yeah, you wouldn't think that they wouldn't be for the quality the film quality, right? But the acting is top-notch. You believe everything that these actors are portraying.  Alfonso, but kind of gets a kick out of it Yeah, I think every kid has that in them. Exactly. Yeah it's also of course a really neat who done it because heavily implied in the beginning of the movie that Alice is the murderer because she has the rain Put on and that mask and she scares her sister, right? Then the murders are being conducted by the exact same figure, but is it really Alice? Well, you don't know until there is a reveal. There's still so much more that goes on in this movie Yeah, there's so many more twists and turns and a lot of times when movies reveal themselves too early They go downhill. Yeah, this actually starts to pick up steam.  You don't want that as a kid. You just want to be entertained You don't want to be thinking about it when it's over. What did all that mean?  So yeah, if you want like a really good smart Horror movie that's got like a lot of themes and you can like finish watching the movie and go to bed Thinking about all what you know, what does all that mean? You know, there's like there's so much there You have to check out Alice Sweet Alice. It's such an underrated gem Deserves its place in the annals of horror history. Definitely. Definitely. So check out Alice Sweet Alice until next time Keep drinking


Lyfydeg amser bactewch dim here giving a public lecture because there are so many people who could be giving it but anyway I've been given the task so I'll do the best. I think I've come the shortest distance just from Singapore but I had to get up at 4 o'clock this morning which is 3 o'clock Indonesia time or Jakarta time and it's after lunch as well isn't it. Well so well so yeah we'll see what happens. But what I have to do is talk. Well we've got an hour haven't we. Until quarter past 2. But I wouldn't go past to. I won't go past to. So there will be time for questions. We'll kind of see how it goes. I may rush through bits of it because I want to get through by 2.  The kind of background to this is Mae'r cyfnod yw'r gweithio yw'r cyfnod yn Rhyw Llywodraeth Rhywodraeth. Mae'r cyfnod yn 1982. Mae'r cyfnod yn ystafell, bynnwyd, byddwn yn ei gweithio, dwi'n gweithio ym 10 ym 10. Mae'r cyfnod yn ym 100 o'r strategi. Mae'r cyfnod yw'r cyfnod yn 1982. Mae'r cyfnod yn 1994. Mae'r cyfnod yn 2008. Mae'r cyfnod yn 1982. Mae'r cyfnod yn ei meddwl iddynau dros d erfolgreichau. Mae'r cyfrifiad yn eich weld yn ysgrifennu i chi, yn y gallu ddechreu am y ddiddordeb hwr. Mae'n ae'r cyfrifiad yn ei ddim yn ei ddim yn ei ddim. Mae'r cyfrifiad yn ei ddim yn ei ddim yn ei ddim. Mae'r cyfrifiad yn erbyn iaith o ddigon i maelod ac i ddweud, mae'r cyfrifiad yn erfyn iaith, a'i fawr ym bod yn gwärddig i , Fy hoedd i ddweudol, mae'r ysgrif siglbyn sydd peth o ddigon i ddim. Mae'r cofio'r byddoedd o'ch cael y blyneu i'w rwycofidio, o'n cael y byddwyd wedi'i ceisio i ddiweddol hefyd i'r meddwl ond hefyd yn cael eu dissolved y byddoedd. Mae'r rhaglenedd yn cael y dyfweld y prosedd ar y cyfueddol i'r fynd George Ddweych. Mae'r cyfeinio'n mynd i gyfu yw ddigonion ar gyfer yr oedd y llif, ar erioedd hyn newydd, ar ei ddisgol sydd bod yn gryf. felly ond mae'n grannu oedd amddereid, ond er mwyn iddyn nhw'n meddwl. Dwi oedd bod yno'r dynner hwylfaenau rhan oedd 89% o gweithno trwm yn gweld cyfarfod cyngor gyda'r dynner hwylfaenau. Rydy'r yma'n rwyf edrych yn rhan o'r gweithio'r ddangos gilyniadol. Yr rhan o'r won rwyf wedi'u gweithio'r dynner, dwi ddim fod o bwrdd eich dynnod gyda'r bwysig, So, ble 81 rhai oedd ymddangos o'r newydd yn 1980 a 1982 hynny yn 2008, yn y gallu gweld ein sgwrdd dros eu meddwl. A, yn 2008, rwy'n gyrraedd 77 rhai o'r newydd. Ond o'r gwrdd erbyn o'r chael ymddangos o'r newydd, mae'n gweithio'r ddweud o'r ddweud o'r newydd o'r newydd. Mae'n gweithio'r ddweud o'r clwytaeth, mae'n gweithio'r ddweud o'r ddweud o'r ddweud o'r ddweud o'r ddweud o'r ddweud o'r ddweud yng Nghaerffrwyddon wedi ei gael, yn etyn ni'r hun. Yn yng Nghaerffrwyddon wedi gweld â dwylo hwnnw, mae'r amgylchedd arog nes, gallai'n haes mewn'r amser, Ac mae hynny ei fod yn eistedd yn hynny'n gwir. Mae hynny'n mwy Pars Lord Wieniaeth, xempo y ddyn ni'n cael ei hynny'n cael ei gechwyn. Ac rwy'n bellig i'w ddiogeth ymlaen i'r dwysig. Rwy'n blwysig i'ch meddwl chi'n meddwl hefyd oedd yn bod y dyfod o'i ddau i weithgareddau. Ond mae fyddech chi'n meddwl, fel y set ymlaen i'r byn i'r dyffug iawn, i'r ffordd y ffordd ar y dyfodol. Rwy'n bach i ddatganiaeth ymlaeni Mary Suzana eich papur a'r papur i'r duw sydd i'i gweld o gyfostiolaeth mewn geisir sydd ymlaen. Mae'r bwysig yn gwneud yr hyn wedyn am eu cymdeithas iawn. Fy fryd i flwydd yn rhoi chyflon ymddangos i'w ddweud ymddangos ein angen o'r drafodaeth o gwneud o'r ceisio'r ffodol. Mae'n gweithio hynny'n gweithio beth o gyfnodol ond yn Ymddangos 12 o 16 miliwn fliwyddon yn y pwyllfa ar ôl wrthoedwch yn Ymdannig, mae'n thata 120 miliwn. ac yn Tylen i'r Filippu i'r Llyfrgellau, yn ystod, y llwyddiad cyfnod, ac yn ystod, y gallwn digwydd yn y ddweud gyda'r ddweud yng Nghymru. Ond yna, ydych chi'n dweud y ddweud yng nghymru? Yn y ddweud yw'r Unedig Papers i'r Papers Unedig o'r migraethu yn y Rheiddiad Cymru yn 2009, ac yna ychydig yna, yn yw'r ddweud, i'r ddweud ystod o'r ffyrdd yng Nghymru. Here, it is dwarfed mewn gwirionedd, a sy'n ddim yn y bwysig yng Nghymru yn dyfodol mewn ddeithes o godi, I ymatech ben am ystod yma yn Zentwyth Taelant, rydyn ni wedi eu bajch yn gweld i wyf. The first thing we did when we arrived in this village, we wanted to find out what the population was. Felly, we went to the Utai District, the Census Bureau, and they told us that there were 378 people living in the village. We then went to the Tambon, which is the sub-district, and they said, well actually no, they're not the 425. And then to the health station, and they said, no, there are 1,257 people living in this village. And then we did our own estimate, we reckon there were 3,000. So the disparity between what is recorded and what is actually there can be enormous. The reason why this village is, as it is, is because it's next to an industrial estate. So this is Ban Khokmaeom up here. And this is the industrial estate here, a Utai Thainline factory kind of estate. And what is happening is people of course are being sucked in from all across Thailand and beyond to Ban Khokmaeom, like these young women here, living in dormitories like this one, Horpak, and they are living in the village. They're not kind of of the village, I mean they're residing there. I would say they're not really living there in that sort of sense of really belonging. But that's what explains this 3,000 people and the disparity between that and what the Census Bureau thinks the population is. And that has ramifications. I think a few people have talked about rural depopulation. What's happening is people are leaving these provinces here. And as a result you're getting an inflow of Lao who are filling the labour gap in rural areas of northeast Thailand. And in fact at the moment I'm examining a PhD which is just about this. So the number of Lao who speak the same language almost, they speak Lao, they speak Lao in northeast Thailand as well. They're coming in across the Mekong, usually, well, illicitly, so illegally in theory, but in practice everyone accepts that it happens to fill that labour gap. And you could argue the reason why there's the labour gap is because of land grabbing in northern Laos. So you kind of got a whole series of resonances across mainland Southeast Asia, which you can track from village to village from system to system. So that's the kind of first thing is that how do we get a sense of what is going on in detail. The second thing is something which has cropped up a few times this morning, which is about how we interpret histories. And this is about how migration kind of tracks through time. This was a study, a longitudinal study undertaken again in northeast Thailand in 1989. And what it shows, I'll just quickly explain, these are male householders, these are female, farming and non-farming. So this is the pattern of farm work and non-farm work. And if you look at this graph it seems as though non-farm work, which often involves migration, is a kind of writer passage. These are young unmarried men and women leaving home, probably going to work in places like that industrial estate I showed earlier, maybe becoming domestic workers in Bangkok, or maybe travelling abroad. Then they're coming back, if you like, getting married, having children, settling down and becoming farmers again. So this picture from 1989, these data, kind of indicate what you might think that this is about a writer passage. These are the same village 10 years on, so 11 years on in 2000. And you can kind of see what's happening, the way in which, if you look at this, you might say, well actually there's an era defining process of change going on here, that these young migrants are not coming back, or at least they're staying away for longer. And then looking at this second graph, it kind of raises a whole set of questions about the reproduction of the farm household, how agriculture is going to be sustained, how households are becoming separated over space in the long term and not just in the short term. And I suppose that's what I've found myself doing all the time, is playing kind of explanatory catch-up.  So you're always trying to just sort of, at least for someone who was based in the UK until last July, just trying to kind of keep pace with change in places like northeast Thailand, Laos, Vietnam, wherever in Southeast Asia. And in fact these are my data showing something very similar. So this is 1982 and this is 2008, so a similar sort of process. And I know Becky's written on this, but you also see, if you like, female mobility becoming very much more the norm than in 1982. So a sort of opening of the moral envelope of who can move and who can't. And I know Becky's work is even more dramatic, her work on Lampung. What's interesting though is that even when people stay away for years and years, and this is where it's different from Deborah's work on Africa, where she was saying that people don't see themselves as farmers. If you like, they're temporary, you know, even though they may be away for 14 or 13 years, they're still beholden to their rural origins. And I don't know whether that's a difference between, say, Latin America, Africa and the Asian experience. I suspect that there are some important differences there. But this is work from Vietnam that we undertook in 2010. These people who have been in Hanoi for over a decade and still have temporary residence and are not giving up that temporary residence. So they're still maintaining important links back to their places of origin. That of course then means that we have multi-sided households and various people have mentioned that this morning and multi-sided livelihoods. So this sort of thing, where you will have a grandparent looking after grandchildren while the parents of the grandchildren are working away. So it's sort of reworking of the household, of course both in the way it's kind of spatial footprint, but also then in the way that it operates as a social unit. And you'll find grandparents complaining that they can't look after their grandchildren. They don't understand them. And some of the issues, for example, where you've got real frictions within the household as they try to deal with these new household forms. And of course sometimes the change is really dramatic. This is another panel study just to give you an idea of how dramatic it is. So this was from 1981. This is the agriculture and non-agricultural division of income, 4060, and in situate 6040. And this was it in 2002. So you can see how these villages have been reworked both in terms of where income is coming from and where activity is situated. And behind, of course, that is migration. But as I said at the outset, people are not giving up their land. They're still keeping hold of their land. So the village we've been working in for nearly 30 years now, you've still got 85% of a population maintaining control of their land. And that's really different from the agrarian transition as it emerged, say in Western Europe, where the departure of people from rural areas to urban areas usually led, I mean sometimes it was forced so land was dispossessed, people giving up their land. And there's an interesting debate, I mean Gillian Hart on, is Asia an example of accumulation without dispossession, whereas somewhere like Africa and Latin America maybe it's a case of accumulation with dispossession. So people in most countries of East Asia, so South Eastern East Asia, have not lost their land in the way that they have, say in Africa and Latin America. So what we have is kind of capitalist accumulation based on the assumption that people still have their land. So they still have a kind of subsistence base, but that's freeing up labour then to work in the industrial sectors. And in a way, villages then become sustained through absence. This is a picture of Teng Hoa in Vietnam and we are interviewing migrants in Hanoi and then we went back to their places of origin and we turn up in villages and find this sort of thing. So people still have their house, they still have their land but they're not occupied and if the land is used it's farmed by someone else. But in an odd sort of way it's because people are not there that the village still exists. It's because of the kind of cross subsidisation of migration and migrant lives and livelihoods, non-farm income back into the village that allows some people to stay there. Which then that puzzle of how come we could still find 77 of our households was because of this sort of thing. People kept their land, they may not have farmed it. I mean there's been some places like Malaysia, lots of idle land. In Thailand some kind of, I suppose, disintensification of agriculture. And there's a scholar called Deirdre Mackay who writes about remittance landscapes that we can kind of read the landscapes of Asia in the sense that they are shaped by remittances. What crops people grow, how they grow them, how they use mechanisation of production, all those sorts of things can be understood in terms of patterns of remittances. So what happens to farming, a sort of third theme? Well you get a geriatrification of farming. So this was again the study that we've been doing in northeast Thailand. So the average mean age of the farmers was 36 years old in 82 and it's now 55. So you've got a kind of ageing of the farm labour force over time. This was a transplant gang that we came across. And we sort of talked to them. We asked them, you know, how old are you? And they're all in their 60s and 70s. I mean these people shouldn't be transplanting rice. And we said, we're all the young people. And someone said, well they've all gone to Bangkok. And then someone else said, no, no, they're not.  You know that agriculture farming, this sort of really hard transplant work is kind of beneath them. They've attained secondary school education and they haven't left the village but they've kind of left the agricultural workforce. So there was a kind of debate among these farmers about whether youth were completely useless and lazy or whether actually they'd gone off to do something useful in the city. But you wouldn't have seen, I mean back in 1980, you wouldn't have seen this sort of pattern of aged transplant gang. And so I mean I think a lot of the changes you see in agriculture, I've got some of them here, dis-intensification land use changes, cropping idle land mechanisation, all those sorts of things are linked in one way or another to migration. I mean of course I suppose an interesting question is the direction of causality. I mean people like James Scott, his work on Malaysia would probably say that mechanisation has led to migration rather than migration leading to mechanisation. So if you have mechanisation it displaces labour from work. I think in his book he calls the Combine Harviser. He doesn't call it Mesen Makan Garja, the machine that eats work. I think that's what it's called in the village of Seneca, that somehow it takes work away from the landless and the land poor. And as a result they become the disempowered migrants going off to KL or wherever. But other people see it working the other way around. And I suppose the classic case is Japan. I don't know if anyone works in Japan here. But the average size of farm, 1.89 hectares, 85% of farmers are part time. I don't know whether this is an Asian future, whether we'll see this kind of get reproduced elsewhere. The number of farmers between 1960 and 2004 dropped from 12.2 million to 2.2 million. Apparently in 2009, 66,000 people took up farming, but only 1,850 were from non-farming backgrounds. So they got no one kind of entering farming. And the average age of farmers exceeded 65 at the first time in 2010. So it's now around about 65.8. So whether that's going to be the feature of... In many areas just 10% of farmers have a son and daughter willing to take over the farm. So the interesting question is about the reproduction of the farm household over time. And I don't know any Australians here. I mean that programme finds the farmer a wife in that desperate attempt to find someone who's going to marry the Australian farmer, stuck out in the outback. And the same happens in South Korea. So I don't know if we've got any South Koreans here. I had a South Korean postgraduate who translated that he said that he took a photo for me. And apparently it says this, marry a Vietnamese woman innocent and good-natured. And then this one, Vietnamese wives guaranteed never to run away. But amusing at one level, tragic at another, but if you like the movement of Vietnamese women to South Korea to fill the void because male farmers can't find wives, that's the degree to which if you like this question of the reproduction of the farm household is being pushed. Which is this theme. So if we've got this sort of pattern and that question I posed earlier, is this temporary or is it permanent? Is this something that's going to, as people finish work, as they mature they come back to the village, they get married, they settle down, they take up farming. So is that the pattern or is this indicative of a much longer term, more profound, deeper seated household footprint? I think the kind of surprise is that households in I would say in East Asia in general are getting smaller. I mean total fertility rates now in most country, I think Indonesia, I think it's about 2.1, is it 2.2, something like that? Barely replacement. I think in Vietnam and Thailand it's under 2. And yet households are becoming more complex. So they're getting smaller and more complex. So this was the households in 82. Here are the households in 2008. And you can see this dramatic increase in grandchildren being brought up by their grandparents. So the point I made earlier. And so at a kind of conceptual level there's a question about what is the household. I think classically, I don't know if we've got any anthropologists here, but I think a household is a co-residential dwelling unit. And all the households that I've been talking about are not co-residential dwelling units. So do we need to kind of rethink how we understand households and that second question about what's the future going to hold? At the moment I'm working with some colleagues in Konken University on the middle income gap. And what we're doing here is kind of we've notionally divided migrants up into first generation and second generation. So the first generation are essentially the ones who left with primary level education. And they went into low skilled work in manufacturing, domestic work, construction sites, that sort of thing. From the second generation, who have mostly got lower secondary school or above. So this is the kind of distinction between first and second generation. And, of course, the first generation, they left the villages farmers. So men like this, I think I took this about 1990. So they took up this sort of work. And I think if I'd gone up to these two men and asked them, what are you, they would have said they're farmers. That was their kind of elemental positioning, if you like. And these, I showed this picture earlier, these are the migrants, the second generation, the first generation, the second generation, Australia, these are the migrants, the second generation migrants. These men and women, they're not farmers. Often they've never farmed. They don't know how to farm. Because they will have gone through probably nine or 12 years of schooling and immediately their schooling finishes.  So that kind of sense of being tied to the land of having the knowledge of farming is not ingrained in them in the way that the two men in the picture behind are. So there's sort of argument that the migrants of the 1980s were surgeoning farmers. Return was always what was going to happen to them. But maybe the migrants of the 2000s, so the last decade or so, are kind of school leavers. We have to think about them as different people. This is the pattern of schooling between the first generation in blue, almost all primary, and then the second generation in, I suppose that's magenta or something like that, isn't it? What's interesting though is that very few of them, this is another puzzle, become permanent migrants. This is a bit tricky because of course if you ask a household well is your son or daughter going to remain permanently? Away permanently? They might say no, no, he, she's going to come back next year, but then it might turn out that they don't. So I know this is sort of hypothetical. But we interviewed or we sourced information on about 150 migrants. And you can see around about 50 had returned by the time we did the survey. Another altogether 120 were expected to return. A small number would marriage migrants, so they'd left because they'd got married to someone somewhere else. And a very small number, just 22, 50% of the total had become permanent migrants. Which is kind of surprise that they're not, despite the fact they don't have farm skills, despite the fact they don't want to go into farming, despite the fact they're educated to secondary level, they're still seen and usually see themselves as temporary movers. And I've been kind of thinking about why this is. And I think it might be, there's some interesting work going on at the moment, mostly in Europe, although it's beginning in Asia, on what's known as precarity. So precarius living. And I think this is becoming increasingly a problem for these migrants. This is a graph of formal against informal sector employment. And you can see this is kind of what, when was the informal sector discovered by the ILO, I think about 1975, wasn't it or something like that. So here we have informal sector comprising over three quarters of total employment. And during the two decades from 1980, you see it falling here for Thailand. This is what's happened since then. It's got a stagnated. So you have the sort of informalisation of the formal sector. What you see emerging is not an informal sector, but an informal economy. And a lot of the jobs that these young men and women have in Bangkok or in Manila or in Jakarta, I suspect don't, they're precarius. So the issue of precarity. They're fixed term, they're contract based, they're casual. And so keeping hold of the land and a foot in rural areas makes sense in terms of how they're getting incorporated into the industrial workforce. Okay. Then I've got a discussion here about the urban villager and what is urban. This links to some really nice work by someone called Eric Thompson who's a sociologist, mostly of Malaysia where he says, let's stop thinking about urban as what we know and think of urban being which is buildings and houses and built up space and think of urban as a way of living. And then we can see urbanity infiltrating rural space. So people like this couple who I interviewed this is a photo I took I think way back in 1980 and we were talking about it. But these are really sophisticated women now, particularly the daughter standing behind her mother. People putting up houses which are emblematic of what it is to be urban in a rural context. And Eric Thompson talking about socially urban. Charles Kies, rural cosmopolitans and Andrew Walker of middle-income peasants. So if you like scholars I mean Andrew walks an anthropologist Eric Thompson is a sociologist and Charles Kies I guess anthropologist isn't he? Kind of using different terms but I think they're all picking up on the same thing which is about how migration is not just leading to remittances coming back it's a whole set of social remittances which are redefining how people act and behave and interact and what they hold dear and so forth. And this is Charles Kies Northeastern families today have become increasingly cosmopolitan because they are linked to a global labour force have sophisticated understandings of Bangkok society and yet still retain longstanding resentment for being looked down upon as country bunkins. I mean he makes a point in this article that there are probably more well he suggests more rural peasants in Thailand have passports than do the urban lower middle class because they're the ones who kind of go out to Singapore and Brunai and Korea and wherever to secure work so in an odd sort of way they're more worldly men like this man who I first interviewed in 1980 more world, I mean he's been abroad more worldly than the people most of the people in Bangkok and then you get cartoons like this which sees the rural masses as a bunch of kind of idiot buffalo who are just following each other this is the sort of thing that really grates with the rural population right I've got one more I think this is a lot, I've got yeah that's okay I've just put this in because we had an interesting, I know some of you weren't there we had an interesting discussion about history and this is a great, I don't know if anyone knows this painting it's a fantastic painting and as you can see it's called Landscape with the Fall of Icarus by Peter Brogill the Elder and you've got to look at it and you think well why is it called Landscape with the Fall of Icarus and then if you look because you've got a man here plowing his land and a ship sailing into the distance and here's Icarus falling into the sea and W. H. Ordon the poet wrote this one of his poems in Brogill's Icarus for instance how everything turns away quite leisurely from the disaster the ploughman may have heard the splash the forsaken cry but for him it was not an important failure the sun shone as it had on the white legs disappearing into the green water and the expensive delicate ship that must have seen something amazing a boy falling out of the sky had somewhere else to get to sailed calmly on and I this is kind of about the histories that we describe that we get kind of caught up in the big events and we somehow expect those big events to be inscribed in the everyday lives of ploughmen like this guy here when of course it may be that actually those big events mean little or maybe they intersect with the small you know everyday living in ways that we don't anticipate and I think this occasionally I show my students this slide as a way of kind of I suppose divorcing big history the way we understand it from everyday living and asking them to think about the connections between the two right? I've done it in time


and take their mind off the mission. I'll take the challenge every big time. No, we actually pinned these to grab all of that.


What's your mantra to stay ages ahead in your professional life? My mantra? I guess, keep learning. That's the fundamental mantra, so to say. And then I'll spend most of my time learning either in the form of reading or by trial and error. So you experiment with a cool idea, you learn from it and then you figure out what was wrong and then try again. So like being on a perpetual lifelong trajectory of learning, I guess.