Intense media interest and competition for stories relating to crime is more profound now than ever before. It's because of increasing numbers of local and national radio and television news channels, a proliferation of traditional and specialized print publications, and a journalistic revolution on the internet. Together, these news media often play an important positive role in advancing public safety and crime control, but the intense competition that's part of the effort, along with the insensitivity of some journalists, can result in disaster for victims of crime. This program is offered in connection with the National Victim Assistance Academy and is sponsored by the Office for Victims of Crime. It examines how the news media cover crime and victimization, what can be done to help victims deal with this coverage, and how victim service providers can work together to promote timely, sensitive coverage. It's no secret that crime stories attract viewers, listeners, and readers. It means victims of crime are often thrust into the limelight, whether they're willing or not. Large-scale tragedies like the 1995 Oklahoma City bombing and the 1999 Columbine High School Massacre in Littleton, Colorado draw thousands of journalists and force hundreds of victims into the public eye. While tragedies with fewer victims, but sensational circumstances can also inspire a media frenzy, a frenzy capable of magnifying a victim's pain and suffering. It happened to Ellen Levin in 1986, when her daughter was murdered. Robert Chambers killed Jennifer Levin in a case that the media called the preppy murder. The case received national attention from mainstream as well as tabloid media, and that meant intense pressure for Jennifer Levin's family. Case that was really custom-built for headlines, because it included two young, beautiful people. The murder took place in Central Park. It was rumored that they both came from wealthy families, which was not true, but this caught the headlines. Robert Chambers told a story about rough sex, which was just custom-made for headlines. I was thrown into, of course, the worst moment of my life when I heard that my daughter's death, but it was made twice and three times as bad by the media circus that surrounded it. There were hordes, hordes of people outside the loft that I was supposed to be up in to be with my family. We had curiosity seekers, but more than that, there were hundreds of reporters. The news media were there en masse with cameras and microphones. I was so frightened that I didn't want to leave the car. My throat closed. I couldn't talk. I couldn't react to anything except fear that people were running towards me. I was at my weakest moment of my life, which I think most crime victims, especially new crime victims who just get the news, couldn't be in a more vulnerable time. I heard them screaming, there's the mother, there's the mother, and they were running and the police were running behind them to try to get to me to protect me. It was one of the most horrifying moments of my life and as the day progressed and the police were out looking for her murderer, Robert Chambers confessed. In his confession, he made up a story that included rough sex, how Jennifer tried to rape him. I mean, he was six foot two, about 210 pounds. Nobody believed his story. The police didn't believe him. The DA didn't believe him. Nobody believed him, but the media loved him. The arrest of Chambers and the subsequent trial created an uncontrolled media circus that totally distorted the facts of the case, making Levin's daughter seem like the perpetrator instead of the victim, putting the family on the defensive and invading the privacy of anyone who might have a connection or information relating to the story. In Littleton, Colorado, the scope of the tragedy was much wider and the media were on scene as events unfolded. Victims escaping the high school were thrust into national prominence, as were families waiting to hear the fate of their loved ones. Television viewers had the choice of watching the tragedy play out from the safety and comfort of their living rooms, but victims had to respond to the pressure of the media while still in shock. It's the type of scene that's becoming all too common, pressing victim service providers like Caroline Ellis into action. victims must deal initially with the shock of what's happening to them, with the reality, with the episode, with the event, with the instance itself. And that in itself is overwhelming. It's beyond the imagination, horror, shock, pain, confusion. People are stunned. They have no idea, perhaps in some instances, where other loved ones are. There are just so many issues to be considered. And to add the dimension of media, whether it's print or broadcast, someone with the responsibility to provide information, facts, issues to the public, you just cannot imagine the kinds of stories that victims retell about that experience. They talk about feeling wounded, rewounded, re-victimized. They talk about having their insides gutted for the sake of passing information on and the public's right to have information about their private lives. At that point, initially, when the event happens, there's little time to think of those things that people would like to have remain private other than the fact that nothing seems to be private at that moment. Part of the problem, no doubt, exists because the media justify their actions as serving the public's right to know. And in doing so, some journalists go to extremes. Reporters can be very pushy, very arrogant in their approach to the people they interview at times. Not all reporters, obviously, are this way. Some reporters are very respectful, but others aren't. And I think probably the one thing that a reporter can do right up front is to accept no for an answer and say, okay, if you want to talk, I understand, and move on. Colorado State University journalism professor Greg Luft says competitive instincts and professional pressures often push journalists into undesirable behavior. Organizations compete for ratings or circulation, and reporters are pressured to be first and most complete. Individual competition also comes into play, with journalists taking pride in being first, enjoying the attention that brings, and knowing that aggressive reporting can lead to better jobs. Luft believes that journalists are more likely to force the issue when stories take on sensational overtones, getting caught up in the circus-like atmosphere, and feeling less responsible to conventional ethical practices. Also, even if a reporter does an admirable job gathering information, editors and headline writers who don't have a feel for the situation may sensationalize material for hype value before it's broadcast or printed. Next, by training, journalists are visually oriented, so there's almost always pressure to get pictures of the crime scene or victims. Reporters also strive to interview victims of crime because of the belief that real life reactions give their stories more personality, character, and impact. Many journalists also believe that giving victims the opportunity to talk is beneficial. But Luft believes that deadline pressures often have the most impact on how journalists approach a story, with broadcast reporters usually the most aggressive because of multiple, non-negotiable deadlines each day, including those imposed by the ability to broadcast a story live. The reporter, for instance, is doing a live shot, and the producer says, you're going to have to fill three minutes, and the reporter needs to find something to make it interesting. So once again, this is where the ad-libbing starts, and this is where some of the mistakes are made, is the deadline ad-libbing pressure. And this is also where victims are approached for interviews and where their reaction to the story become the commodity that the television station or the newspapers utilize as content. And that commodity, unfortunately, puts them and may put them at risk emotionally for further problems. It may not do them any good. In some cases, it may have a cathartic effect, and I think that's debatable depending on who you talk to and whatever the situation is. But the reporters are not thinking in terms of how it's going to affect the victim. They're thinking in terms of what they need to get, where they need to get it, and how they need to get it to the audience, because the audience is very hungry for the information, especially during a breaking story. This is the type of scenario that reporters faced in the recent Columbine High School shootings, and the result was a free-for-all where any victim in the open seemed to become fair game for any type of question. Massacre at Columbine High School in Littleton, to me was probably the first example of the news media in the information age having immediate access as the crime was occurring to many of the victims. It was a highly unusual case where there really were not very many restraints in covering the crime. The question has been raised seriously, whether or not it was perhaps helpful for the children as they were fleeing, traumatized, and wounded from Columbine High School as the crime was still occurring, whether or not it was perhaps helpful for them to be immediately interviewed by journalists. I find this question absolutely preposterous that the media or anyone could feel that an untrained person with no experience in trauma response or mental health could consider their talking to victims as they were in shock, physically wounded, that they could consider this to be helpful, and yet that question has been raised and I think merits further discussion. Anne Seymour is a senior faculty member of the National Victim Assistance Academy. Like many victim advocates, she believes the media's assumption that interviews help victims is just one of the many troublesome issues that crime victims and advocates have identified about how the media cover crime and victimization. One of the biggest concerns is interviewing victims at inappropriate times, which would be at the time the crime is occurring, the arrest is made as victims are going through court, at sentencing years later perhaps at parole hearing, it's a time when victims are very traumatized and it's important that the media be sensitive to not conducting interviews when the victim might be a little bit stressed out. I think it's important that the media not ignore victims' wishes. If a victim wants to do an interview, that's great, but if a victim doesn't want to do an interview or wants to issue a written statement, they should have the right to do so and a lot of victims tell me that they've made their wishes clear to journalists and yet those wishes were ignored. The media also in some cases and not always tend to glamorize the offenders. I remember years ago they described an assailant who was a law school graduate, rape crisis center volunteer, Republican Party volunteer, who they were describing was Ted Bundy. And in their tendency to glamorize the offender, they completely omitted information about the many, many young women who were killed by this offender. Sometimes journalists and in particular headline writers use euphemisms to describe crimes. One that a lot of people would remember is the preppy murderer. This was the case in New York where Jennifer Levin was murdered by Robert Chambers in Central Park and yet few people remember the name of the victim in that case, Jennifer Levin. Women's also have concerns that sometimes the news media fail to report crimes at all. If I was a white middle class male and I was murdered on a certain part of Washington, D.C., it would be headline news and yet if I was a black female mother of four in another part of Washington, D.C., if it made it to the murder roundup on the back page of the Metro section, that would be news. And I think the media sometimes tend to reflect societal biases and I think that's a concern for all of us. Probably the biggest concern that crime victims and advocates have is related directly to privacy issues. While most journalists, I think, do a very good job of having policies that preclude them from naming rape victims and naming child victims and other sensitive victims like elderly victims, it seems as of late these policies have been bended to the point where many of them have broken. We know that one of the major reasons that women don't report rape is they are afraid of having their name disclosed in the media and so considering special sensitive victims' privacy concerns is something that we are all very committed to making an issue with the news media. There's also a double-edged sword that occurs with the media when law enforcement officers will not talk to the media to preserve the sanctity of the case. The traumatized victim doesn't talk to the media because they are going through shock among other things. There's a tendency to still have to get information or facts of the case, if you will, and so very often they rely on witnesses who may or may not have anything to do with the case and end up what a lot of victims say is reporting innuendo about the case and that's very, very hurtful to victims. Innuendo was a major factor in the Jennifer Levin murder case. In order not to prejudice the jury, Robert Chambers passed of drug problems, burglary and theft records were not revealed in court. The defense and thus the media were allowed to introduce any information including rumors and innuendo about Jennifer Levin's past. Additional concerns include the media's common practice of photographing scenes with bodies, body bags and blood, referring to drunk driving crashes as accidents, revealing the names of homicide victims before survivors are notified about the death of their loved ones and inaccurate reporting, misspelling of names and misstating of victims' ages. Many of these concerns played out in 1995 after 169 people were killed as a result of the bombing of the Murrah Federal Building in Oklahoma City. Media coverage was intense and victims were overcome by this pressure. When the venue for the subsequent trials was moved to Denver, victim service providers were determined to help victims cope with media demands. Families in Oklahoma City had very, some of them had very difficult and bad experiences with the media that arrived in Oklahoma City right after the tragedy. They felt that their privacy had been invaded and that they were not in control. And what we know about victims of crime is that one of the issues is that their control has been taken away. So one of the things that we can do to enhance their healing process is to give them some control over their lives again. And one of those things that we could do for them was to really provide them some control about their interaction with the media. Robin Finnegan was co-director of the Colorado Oklahoma Resource Council, which worked in Denver to protect the rights of victims who attended the trials. Her work was made easier because of a unique 70-member media consortium. The consortium worked closely with the city of Denver, the federal court, and victim service providers to plan orderly coverage of the trials, setting aside a so-called media bullpen to stage interviews and setting a standard of behavior that has already been used as a model for coverage of other cases. So they organized and established their own rules and there was some accountability as to the, they were credentialed of who could go into the bullpen, who could go into the courthouse, and the most wonderful piece of that is that there was a sense of teamwork between our organization and the media consortium because they, what we tried to do is provide them with some stories and interviews and access and names as long as there was a sense of cooperation that they would agree to treat these victims with dignity and respect. And that then these victims felt like that they, for the first time, had an option about when and where interviews happened, that they didn't feel like they were going to be jumped on the minute they walked out of the courtroom, that there were private spaces and times that the media did not have access to, and there was a real agreement about that. It was like emotionally being here in person, almost reliving a lot of what you went through. While Finnegan and others coached victims on dealing with the media and helped coordinate interviews, the U.S. District Court agreed to set aside the media bullpen, which could be used for interviews when victims were willing. The media consortium agreed to give victims space on a restricted walkway between the courthouse and a nearby church, which was designated as a media-free safe haven. Kind of a three-pronged approach there. The justice system, making it very clear that there would be restrictions, that they wouldn't put up with the kind of thing that happened in Los Angeles during Georgia-Simpson trials. The media, knowing that they would get more out of the court system, their coverage would be better if they worked together and if they worked with the court. And having a very close relationship with victim advocates and setting some rules and guidelines with victim advocates so that the victim advocates could help them get what they needed from victims, but at the same time the victims would be protected when they want it to be. Luft studied the media's behavior for more than a year, producing an hour-long documentary that included victim viewpoints and concerns. He believes that victim service providers can help the media act more responsibly by establishing clear guidelines. I think boundaries are very important, physical boundaries as well as protocol boundaries, simply because once journalists know what those boundaries are, it helps them avoid the pack mentality. Pack mentality takes over when one journalist is afraid that someone else is going to get something that they don't and then the pack just gains steam and goes in for the kill. But boundaries will help all journalists help each other not to break those rules and guidelines. boundaries for journalists are one part of the equation, while providing direction for victims is also an important component of making the relationship work. Years ago we developed specific guidelines for victims who choose to deal with the news media. That lets them know that they have rights and they have choices and I think the most important choice is whether or not they wish to deal with the news media at all. The National Center for Victims of Crime has also developed specific guidelines for victims who go on talk shows. I think this is one area of the news media where victims have been exploited, emotionally abused, neglected, treated poorly, ambushed and it was time that we really look at telling victims that they do not have to do these shows and if they decide to do these shows that there are certain guidelines that they should expect the producers to follow. Specific media guidelines recommended for victims include the right to refuse an interview at any time. To choose a spokesman or advocate. To set time and location for interviews. To request or deny interviews with specific reporters. To release a written statement instead of an interview. To keep children from being interviewed. To refuse questions that cause discomfort. To ask about the direction a story will take. To avoid mass interviews. To demand corrections of inaccuracies. To ask that offensive visuals not be used in a story. To conduct interviews without being photographed. To provide the complete story of one's victimization. To refuse to answer questions during a trial. To file a formal complaint against a journalist. To grieve in privacy. And to suggest training about media and victims for media in the community. While these guidelines apply to victims it is the victim advocate who can help ensure the victim knows how to apply these practices in a given situation. I see the role is that of navigating. Of being a navigator. To provide information to make sure that at that moment that the victim is well aware of the dynamics involved. That here is media and this is what happens. That your story is going to be projected and the facts are going to be laid out. And we hope that the facts are going to be laid out without distortion and correctly. But at the same time you have the ability to say yes or no. It's strictly your choice. You don't have to respond simply because they are here. You can make some demands in terms of what you would like to have conveyed in the way that you'd like to have it conveyed. You certainly can control the interview in every way. Victim service providers play a critical role in shepherding the victim not only through the case but through the different points in the case where the media will for good reasons have an interest in that case. As a victim advocate I always try to let victims know that they do have rights in dealing with the media. That they have choices as to whether or not they wish to deal with the media. I also let them know what I know about certain journalists. As a long time victim advocate there are people who I know are extremely sensitive to crime victims and their needs. And there are other journalists is probably a stretch in terms of the word but there are other people who call themselves journalists whose sensitivity to victims is extremely lacking. It's also my job to make sure that the victim knows that they can write a written statement if they want to have their opinions expressed that can be given to the media. I would also coordinate any statements from the victim with the prosecutor in a case to ensure that there is no conflict in terms of protecting the sanctity of the case. I'm sorry to say in some cases I've actually provided a physical buffer between crime victims and the news media particularly in high profile cases where the victim's wishes to privacy or to not speak to the media are not regarded. In cases of homicide it's extremely important that I help the victim identify how he or she wants their child their parent to be remembered. This may mean getting photographs of the person having them talk to me about the memories of that person so that the memory of what has been lost to a violent murder is honored as well. The victim advocate must take the lead once an event has happened but that person can also work to improve the media's knowledge before a crime occurs. This can be done by encouraging and volunteering training in a number of different venues and utilizing specific techniques. Hopefully we can pass on the fact that we need to expand the definition of team and I think that's a new concept for people particularly in government and in nonprofits and in the clergy. We never imagined ourselves as team players before and as team members and now what we know is that we can't do it without each other. It's critical that crime victims and advocates seek the opportunity and indeed the journalist associations are seeking the opportunity from crime victims to speak to journalists to get dialogue going in a way that it's in a way training but it's more in a way dialogue that occurs that sort of enlightens each other to their mutual interests and their mutual concerns. I would like to see in every school of journalism a sensitivity program to teach the students who will be covering crime victims about what a crime victim suffers. I think for the media to have a good handle on how to behave and how to react in situations where victims of crime are being interviewed or the subjects of the story that ownership and management and organizations have to take it on themselves to train their staffs. They have to find a way to work case study situations into the training so that when a reporter, when a photographer, when someone on staff gets to the story, starts collecting information, they know how to do it in a sensitive way. The media aren't likely to go away or stop covering crime. Media coverage of crime and victimization, however, can serve a valuable and necessary function for all concerned parties. Reasonable and necessary goals of those involved should be to recognize and respect the roles and concerns of victims, advocates and journalists to communicate and share information as openly as possible before crime occurs. And to be willing to work together as a team rather than adversaries when events make that necessary.


So, hello everyone and welcome to Code Review Best Practices. I'm XJM and I arrived from the U.S. very late last night, so I apologize if I'm a bit overcaffeinated, which is what I'm trying to use to ride through the jet lag. I'd also like to thank the conference organizers for having the flexibility to allow me to get back on the schedule. I was on the schedule originally, I had to withdraw my session for family reasons, and everyone was really cool about shuffling things around to get me back here, albeit at 11.15 in the morning right after I traveled from the U.S. So nothing's perfect, but it's fantastic to be here and I'm happy to be presenting this talk. Now, if it helps you follow along with the slides, I have posted them on my Twitter, which is XJMDrupal. If you're the sort of person who likes to read along or needs assistive tech to help with the text on the screen, those are available for you. I'm not wearing a mask at this event because it muffles my... Sorry, I am wearing a mask at this event, but I can't while I'm speaking because it muffles my speaking and makes it harder for people to lip read who need that support. So if you do have a mask in your pocket, I'd really appreciate it if you'd put it on. I meant to bring a box of masks and pass it around to everyone, but unfortunately the 36-hour turnaround time for this fit into that. So I'd appreciate it if you'd put a mask on if you do have one. Also, one other note before we get started, I ask that people not take photos or videos of me for privacy reasons. If I see a camera pointed towards me, I have this reflex where I'll sort of like duck out of the way, hide behind the podium that can be a little distracting, so please don't do it. If there is a session recording, as we've already established, it'll be audio and slides only. Also, out of respect, I'd like to make a land acknowledgement. I acknowledge the traditional Aboriginal and Torres Strait owners of the land, the traditional custodial lands of the land that I'm visiting. I'm told that the Gatagala, the Oro Nation, please tell me if I'm pronouncing that incorrectly, are the traditional custodians of this area. So, hi. My name is Jess. As I said, I'm XJM on Drupal.org, and I'm a Drupal Core Committer. Now, there are thousands of people who contribute to Drupal Core, but as a core committer, I'm one of about 15 people who can worldwide, that's 15 people everywhere in the world, who can actually accept or merge changes into the core code base so that they become a part of everyone's application. That means one of primary responsibilities is reviewing other people's code. I'm also a member of the Drupal Security team and a core release manager, so I actually create many of the releases of Drupal that you can, and I hopefully do, install on your Drupal site each month. One organization that's funding 16 hours per week of my contribution time is HeroDevs. HeroDevs is currently the only official extended long-term to partner for Drupal 7. They have basically a fork of Drupal 7 that will be maintained after its end of life. FabianX, the Drupal 7 core framework manager, helped them build the product along with a number of other Drupal 7 contributors and community members. They sought advice from the Drupal Association, the security team and so forth, so they're doing a responsible job of it and it should be pretty legit. The platform will scan for security vulnerabilities and in fact, HeroDevs will also handle in collaboration with Klausi and some other members of the community a security reporting and patching process for any new Drupal 7 vulnerabilities that you discover. It's not just for core, either top contributed modules will be included and now they're funding me to work on Drupal 10. I don't know anything, like very little about Drupal 7 these days anymore, so my role is primarily as a contribution mentor for them and to help them gain reputation in the community because I'm a core committer, so if you are interested in the Drupal 7 NeverEnding Support product talk to me afterward and I can put you in touch with some of the folks there. Alright, so the primary goal of Peer Code Review is to catch bugs in new or changed code before it goes into production. Peer Code Review also helps code health increase over time rather than declining. It's not just about code quality though. Software code is written by human beings, for human beings, and it's important that your code review process reflect that. Put simply, Peer Code Review is also a tool for building stronger team. By reviewing each other's changes as they're developed, you build a shared understanding of your code base across your team. If done properly, it should foster open constructive communication. It can also help you create a sense of pride and shared ownership in the projects you develop together. It's also a really excellent opportunity to mentor junior developers on your team. It's some of the best onboarding that there is. And finally, Peer Code Review will help reviewers and code authors alike write better code the next time because you learn from the review process too as the reviewer. Now, of course, if you want your code reviews to be a positive experience for your team, you need to have a positive Peer Review culture. I'm not big on emotional labor myself. I find it exhausting. But Peer Code Review is the one place where it really is worth it to me to put in that extra effort to make sure that everyone on my team feels safe and supported. The most important thing is that everyone involved in a review should treat each other as equals. The reviewer isn't above the developers. You all bring different knowledge and experiences to the process. Start from a place of humility. We do Peer Reviews precisely because it's difficult for us to catch the errors in our own work, and so we're relying on the other members of our team to help us with that. And that's true for the reviewer as well. I want to reiterate this. In the years that I've had Commit Access to Core, which is going on 10 now, I've noticed that many contributors just kind of do anything I say without questioning it in the Drupal issue queues. But actually I want to hear the author's thoughts on feedback that I've given them, especially if they disagree because I make mistakes too. That's the most important lesson. It's also important to have empathy for others involved in the Code Review process to consider their needs and their constraints. If something seems wrong or confusing, ask a specific question about it that will help both of you understand what's going on. If something technically works but could be improved, phrase your proposed improvements as a suggestion. And finally, when you and others disagree about something in the Code, encourage others to explain their perspective. Even if something definitely needs to be changed from your perspective as the reviewer, it's helpful to have misunderstandings and additional perspectives documented for future reference. So I structure my Code Reviews in three parts to improve the chances that they'll be well received by Code Authors. I try to start by thanking the author for something specific that they did well. This helps them read the review positively and also shows them that I'm aware of the effort that's gone into their work. If I dive straight into asking someone to change this, that, and the other thing, it might seem like I've missed the big picture or the value of the work overall. Next, in my comments about specific lines in the Code snippet, I tried to provide references backing up my recommendations.  So provide them with policy documentation, references to other Code that's similar or the like. Providing a reference helps the Code Author internalize best practices a little bit at a time and also sets a good example for other reviewers to follow so that everyone learns from the process. Finally, after I've finished my detailed review, I close with a summary and an actionable next step for the issue. If I've given a lot of feedback, I'll highlight what I think the most important questions or concerns to respond to are. It's always good to help contributors understand what the path done is and that starts with an actionable next step for the issue. Now, before I get into any more specific advice about the technical aspects of Code Review, I need to explain some background concepts from psychology. Of all the tools that we use to do peer code review, the most important one is actually our brains, right? No brain, no code review. So it's important to understand the limitations on our brains and how we can enable them to do their best work. And by the way, I am not counting AIs that do code review because no substitute. So the first concept I have to introduce is that of decision fatigue, which simply stated is that after we make many decisions, our ability to make additional decisions becomes worse. If you've ever come home after a long day and found yourself kind of staring into the refrigerator as if it helped answers or been completely paralyzed by the array of choices in a big box store, I'm not sure if y'all are familiar with U.S. supermarkets, but it's an experience. This is probably what's going on. It's decision fatigue. We make hundreds of small decisions every single day. Many of them are completely trivial. What to say or text at a given moment, what to have for breakfast.  And symptoms of that fatigue can include feelings of exhaustion or mental fog, impulsiveness, and procrastination or avoiding making future decisions. And code review does involve a lot of decisions. For every single line we decide whether the code is right, what other side effects it might have on the application, whether there's a better way. Another important concept is that of directed attention fatigue, or DAF. When we have to focus on a single task, like we do when we do a code review, our brains have to suppress stimuli from distractions. The distractions can be external, background noise, the kids, the pets, messages from coworkers. They can also be internal, random unrelated thoughts passing through our minds, feeling hungry, worrying about the bills. Finally, the distractions can also come from the code itself. Code style errors, bugs in nearby code, and so forth. And this in particular is something we'll talk more about later. Unfortunately, the mechanism in our brains that allows us to put aside these distractions and focus on the task at hand becomes fatigued and overused. And symptoms of that fatigue can include restlessness, irritability and apathy, none of which are going to help you have a positive review culture, by the way. Directed attention fatigue can also cause you to miss social cues, which can make it harder to communicate empathetically with the developers whose code you're reviewing. And finally, it can cause misperceptions, confusion, impulsiveness, or poor decision making, all of which will lower the quality of your code review. It's also worth pointing out that distractions are an accessibility issue. Directed attention fatigue does affect neurotypical people, but it can be compounded for folks with ADHD. There's been research that shows that the same mechanism in people's brains is stressed in both directed attention fatigue and ADHD. The important difference, of course, being that directed attention fatigue is a temporary condition that you can recover from. It takes time for that distraction mechanism in our brains to recover when it's been stressed, which is probably one of the reasons that a lot of people with ADHD use a strategy of taking frequent short breaks when they work, followed by a longer break after several cycles. Overall, you should treat distractions both in the work day in general, and in a code change set itself as accessibility and inclusivity concerns. And this is something that I'm trying to get better at in my own code reviews as well. It's a process. So with that context, let's talk about some research that's been done on how different factors can increase or decrease the effectiveness of our code development process. References for the research are in the speaker notes of the slides that I've shared on my Twitter. They're the Google slides that are there. The key concept to understand for this section is that of defect detection. This means of the existing potential bugs or flaws in a code change set, how many are actually identified by a given process. Now, higher, a little bit counter-intuitively, is better, because it means you've found more bugs in the code before they can actually become bugs in the application. And early defect detection is really valuable. According to one of the sources that I looked at, even low-impact bugs are twice as costly to fix once the code is in production, and a critical bug can be as much as 100 times more costly to fix. Now, for Drupal Core, I'm a core developer, so I always try to reframe everything between the normal world and the open-source contribution world. For our purposes as core developers, that's probably, in productions, probably the equivalent of it being present in like a tagged release of Drupal that someone might have installed on their site already. And then something you might not have expected. A formal peer code review with multiple reviewers is on average twice as effective as automated testing for defect detection. This is actually amazing, right? That people simply reading the code are twice as good at finding bugs in it as computers that can actually run it. Of course, combining all of the above is even better. I have some slides to illustrate this. They compare the effectiveness of peer code review with different kinds of quality assurance. In this case, if you used each one of these things by itself before combining them, how effective is it? First off, a word about unit tests. These can catch anywhere from 15 to 50% of the bugs within their scope or 30% on average. Now, I didn't show the error bars for that on this slide because unit tests were the only tool with such unpredictable effectiveness. And the reason that varies so widely is because the usefulness of the unit test depends on the scope and encapsulation of the change set that you're reviewing. Furthermore, misusing unit tests in place of integration tests can lead to a very high rate of false positives. And false positives are distractions from your review. So, use with caution. Use them right. Don't use them if you don't need to. Static analysis is pretty great and can catch 33% of potential defects, more actually than typical unit tests or regression tests, which is worth knowing because they're also way faster. We recently started doing static analysis on Drupal Core these past couple of years, and it's awesome. It's made a huge difference on the quality of our code. Integration tests are typically the most effective automated tests, catching 35% of potential defects. So, as an aside, when in doubt, if you're like, you only have time to write one test, write an integration test over unit tests or regression tests for the code. Now, compare all of the above to a formal peer code review process with multiple reviewers, which will catch 60% of defects. Again, that's peer code review by itself before you have included automated testing in the process. Finally, for context, I've also included a statistic about the effectiveness of large beta tests with over 1,000 participants in them. Such beta tests typically identify 75% or so of defects with the code. Now, just think of all the time and cost it takes to set up a beta test of that scale for your application to say nothing of the free work that's being done by your beta test participants, right? A formal code review costs a fraction of that, but it still might find as much as 80% of the same stuff, even if for some reason you don't have automated tests, which please, I hope you all do. So, like I said, those statistics were all about using each tool by itself. But peer code review is also even more effective when combined with other strategies. If you combine design reviews, automated testing, QA, and then peer code reviews, it can increase your defect detection rates to over 90%. That means over 90% of bugs are found before they can make it to production. So you should still write integration tests and still use linting and static analysis tools. And actually, you should have all that run before your peer reviewer even looks at the code. That will reduce the number of defects present in the code when they review it, which in turn will make the reviewer more effective because there are fewer defective, sorry, fewer defects they have to focus on, fewer distractions in the code. In summary, peer code reviews are your most effective resource, so you should optimize your development process for them. So how do you do that? How do you optimize for a good code review? I'm going to spend the next several sections exploring how you and your team can work together to optimize for code's review ability. So in the graph on this slide, it compares the defect intensity found in a review, that's the y-axis, the vertical one, with the number of lines of code in the set under review. That's the x-axis here. Higher defect detection is a good thing. It means that you're catching more of the bugs that already exist in a piece of code early before the code goes into production. So this part up here, good. Lower defect density, on the other hand, is a bad thing. These huge chain sets out here with 700 or 1,000 lines of code under review, it's not that they didn't... it's not that they had fewer bugs, it's just that the reviewer was so overwhelmed by the scope of the code that they were reviewing that they couldn't find the bugs anymore. There's a pattern of exponential decay there. Reviewers are really good at spotting bugs in small chain sets, and if you've ever submitted code to a peer reviewer, you've definitely noticed this. But then the reviewer's effectiveness drops off rapidly as the size of the chain set increases. So why does this happen? The reason is that reviewing too many lines of code at once can cause both decision fatigue and directed attention fatigue. So the best way to fix it is to reduce the number of lines of code under review in a single given chain set. Split it up into smaller logical pieces. Fewer lines to review means fewer decisions and fewer distractions. Based on the data, it's best to review up to about 200 lines of code at a time. And note that that includes removed lines of code because you as a peer reviewer need to read the removed lines as well to ensure that the change is correct and to ensure that there aren't regressions. So you add up the absolute value of the added and removed lines, and then that gives you the count of the total lines under review. And I have a... you know, since that's arithmetic, I have an example to illustrate that just for your reference. So this is a random example from Triple Chorus Commit History. This change added 113 lines and deleted one. So adding 113 in one, that's a total of 114 lines under review. That's a good change set size with a hell with the review process. Now in general, to drive this point home a little more, you should really never review more than 400 lines at a time. Change sets even that large should be reserved for simple one-to-one replacements of one thing or the like. For example, replacing a deprecated function's usages across the code base with one-to-one replacement with something else. At 400 lines, that's fine, it's scannable. Here's an example of a problematic change set scoping from another issue I reviewed a while back. It was a bit much for me. I felt like physically exhausted every time I got more than halfway through this. And then sure enough, I checked and the scope of the change set was just too darn big. The issue changed 94 files 229 insertions and 201 deletions so a total of 430 lines of code under review in that set. Over our recommendation and that's part of why it was tiring for me and part of why I couldn't do my best work on it. Another thing that helps is to never spend more than 60 minutes doing code review at a time. Now note that that's sort of the recommended maximum for people on average and it might not work for everyone. You might find, for example, that shorter 30 minute code review sessions at a time work better for you. And between those 30 or 16 minute sessions you need to take breaks so that your brain can recover. Remember, that's the distraction suppression mechanism that you need to give a rest. You deal with distractions that have come up during the review, but also just let your brain rest. Some folks might find they work better even with cycles of 20 minutes of code review plus a short break followed by a long break after four sessions. That's something that the ADHD community uses. It's called the Pomodoro Method, by the way. I learned that from my little sister. So, speaking of distractions and code review, let's talk about handling nitpicks. Now, nitpicks by themselves by definition are trivial but how you handle them is actually a really important aspect of code review that does need to be discussed. I'll take a drink to talk about this. So to me, reading code style errors is like watching a speaker who has food in their teeth. Imagine a little flock of something green stuck right up here. It has no pairing whatsoever on what I'm saying. But you still might not be able to concentrate on what it is that I'm saying because of this one out of place awkward thing. And that's how I feel when I review a chain set that has code or documentation style errors. They're minor, they're unimportant and utterly distracting for me.  I don't understand your inline comments if they contain grammatical errors. It's a real problem, actually. Part of it is me, but it's also a real problem. Code style errors are distractions that can increase your directed attention fatigue and make the review harder on the reviewer. Now, trivial decisions about fixing them will also add to decision fatigue for both the reviewer and the code author. Are you using spaces? Are you using tabs? Reward this, rewrap it. You can imagine. Should I even bother that? Leave it alone, etc. That whole conversation. Waste of your time. On the other hand, though, nitpicky reviews are also discouraging to code authors. They spend hours or days fixing something that's important, something in the open source community that they may have donated their time to fix, and then instead of evaluating their design or appreciating their work, you get lost in distractions of formatting issues or spelling errors or whatever. It can seem oppressive or like a lack of appreciation for the contributor's work. So how do we fix this problem, this balance? On the one hand, code style errors get in the way of effective code review, but on the other, they are the least important thing about your change set. The answer is to use automated tooling that runs immediately every time you submit a code change before your peer reviewer looks at the issue. And I'm not talking just about static analysis here. Instead of dozens of tiny nitpick decisions, if you have the right automated tooling for coding standards checking setup, you'll have one binary decision. Did it pass the automated coding standards checking? The Drupal Core community has now spent over a decade incorporating automated coding standards checking into core process and making core actually comply with its own coding standards, which was not true. Many of you from back in the day will know this. And when I talk about this, it's hard for me not to get really excited and melodramatic about it, because it has had such less impact on our community health. It has made our code review process so much healthier and so much more focused on what actually matters, which is what Drupal can do for people, right? So here are some of the automated tools to use. PHPCS, PHPStan, C-spell, ESLint and Stylint. This is assuming a PHP application. There are, if you for applications in other languages, there are other equivalent tools to use. Now, Drupal Core has a script that will automatically run a number of linting checks, including these tools on the code base, both as part of Drupal.org's automated testing and as a pre-commit hook when core committers like myself add changes to head. You can also configure jobs for these tools using GitHub Actions, GitLab CI, or your own continuous integration or QA process. I won't go into detail about how to set this up, that information is on the internet. But my slides are posted so you can find the list again if that helps. I strongly encourage everyone to use these tools for both contributed and client projects. In each case, Drupal Core already provides a default rule set you can use to make your project compliant with Drupal Core standards, if that's your goal. You also have the option of developing your own rule set if your org has its own standard. Now, automated tooling can't catch every nitpick type problem. And I have an example on the slide of a minor documentation fix, where someone should have used the ActC PHP.tag, but used a short sentence instead. Fortunately, GitLab makes it super easy to deal with this kind of thing as the reviewer with the Insert Suggestion feature. You just highlight the lines your nitpick is about, click the Insert Suggestion button, which is the left-most one in the widget. I have an illustration of this because I had no idea when I started using GitLab what this little piece of paper with arrow on it was. It's the best button in the user interface. All you have to do is highlight the lines, click the button and edit the snippet. You click start a review or add comment now and as a reviewer you've just saved an entire review cycle over this silly little thing. Once you post the comment the code author can then add your Suggestion change to the merge request with a button click. It saves you time having to write out the entire sentence of this is why we should use the PHP.tag here blah blah blah. And it saves them time having to make this let's be honest, ridiculous nitpick change that you suggested that is necessary to meet the code quality standards, whatever. Love it. Please use it. So with all this background information let's now talk about how we can optimize our change sets so that peer reviewers can do their best work. Remember, human peer reviewers are the single most efficient thing you have to catch issues early, safely and cheaply so lean into that. There's something quite important about your peer reviewers. They are your first insight into what the experience someone is going to have in maintaining this code yours down the line. If the reviewer can't follow your code just by reading it chances are that's going to happen again in the future when someone else looks at it so optimize for readability and reviewability. It's essential that someone in the future can understand your code easily. It might even be you in a few years, right? You don't want to find yourself thinking did I write that? I'm so embarrassed. Of course, it's much better to think oh, thank you past self. That was very clear. Thank you for documenting that. I understand what's going on. I've had both experiences I'm sure many of you have as well. While smaller change sets are easier to review it's definitely possible also to take that too far. So first and foremost you shouldn't ever commit something that leaves your main branch in an unshippable, incomplete or broken state. If you were involved in or even using Drupal a little more than a decade ago and wondering why Drupal 8's release date kept getting pushed back it's because of this right here. We didn't keep the code base in a shippable state so we ended up with hundreds of critical issues blocking Drupal's release. Another mistake is to make the diff stat smaller by separating out test coverage or documentation. This is an idea because the tests and docs are an important part of understanding the change and a diff that's missing them isn't optimized for reviewability. This affects the immediate experience for the reviewer, the shippability of the code base and the usefulness of your git history. A lot of times actually I read the tests first to understand what's going on in a change. Finally, scope creep. You're editing a file and you see something else that's wrong couple lines above so you think why not fix that while I'm here? The problem with this is that it adds distractions for the reviewer and forces them to think outside the context of the primary change. It also creates an ever-expending set of changes that need to be involved in the issue blurring when the issue is really done. Now reviewers can make this mistake too, by the way. Especially when they're reading moved or context lines in the diffs. Someone moves code from here to there and all of a sudden the reviewer starts posting all of these things that you should change with it and you're like it's already in the code base, man. I just put in a different file. It's very, very easy to start posting suggestions on how to fix it but it's actually not helpful feedback at that point because the issue is just changing the factoring. So instead of fixing that one little thing near changes, get in the habit of filing separate follow-up issues for unrelated problems you spot. And, again, as a reviewer, especially for moved code, just make a note of it somewhere else and then after your review is done, by the way, we should have a follow-up to read about this hard-to-read thing that we refactored and do a new place in our code base. Now sometimes you'll get a reply from a code author that a certain pattern you're back on in your review is used elsewhere in the core code base. Happens all the time or your application's code base. But core is huge, so more times in the core code base. Now even if you've documented a real technical problem with the approach that the authors use, they might still push back. And there are actually kind of two kinds of code authors here. Some code authors will take your response to your feedback too far and then they'll change all the other instances of that same bad pattern everywhere in the file or even everywhere in the application. Others, they'll push back on your pushback and want to add new code that's using what's a known bad pattern just for the sake of consistency because the pattern exists elsewhere. Now both of those things are the wrong approach to take. File a follow-up, write good new code now and fix the old bad code later. Separate parts of your brain, separate scope, separate priority. You also shouldn't even fix out of scope things on the same line as the one that you're changing. Now when I was first working on core a lot in 2011, I personally made this particular mistake a lot. I would think, oh well, we're updating this line. We might as well improve this other thing too. I can improve the wording. I can improve the formatting. It'd be cleaner with a ternary and you can use those now, whatever. Bad idea, don't do it. It's still Sculpt Creep and it will still make your peer reviews less effective. And here's an example of why. So in the dif on the slide a change is standardizing how the word writable is spelled throughout the code base. Serious issues here, people. I'm not kidding you, this was an actual Drupal Core issue. Let's say I thought of a better way to word the method doc block that says a writable store. It sounds a little awkward to me so when I read it I was like, is that the best way to say it? It could be tempting while I'm changing that to say well, I might as well improve the rest of it as well. Now the problem with that is that it completely changes the kind of review that's needed. If the original chainset is only a couple dozen instances of standardizing how writable is spelled, that's very easy for me to scan. Writtable with an E without an E, with an E without an E. It'll only take a couple minutes. And here's why. So these kinds of changes are very easily scannable if you use a word diff. If you have not used this before, please do get diff dash dash color words. It's very useful for replacing all instances of a misspelled word, fixing one coding standard, replacing a deprecated method for a new one. If you have not used it before, I promise it would change your life. It's great. So if we suddenly add a bunch of rewritten docs my word diff is no longer useful. Instead of checking the spelling the reviewer has to think about the whole sentence. Is the new version actually an improvement? Is it grammatically correct? Are there other errors being introduced? Like did they make it 83 characters instead of 80? What's more, the reviewer will have to actually read the entire method to determine whether the new documentation is actually accurate. Suddenly what was a two-minute review is instead going to take 20 or more depending on how many lines we decided we wanted to improve. The approach we should take instead is to get this simple change set in, the one that just fixes spelling, and then have follow-up tasks for other improvements if you want to make it. Note that get diff color words can also take a reg X to specify what should count as a word break for the purposes of the diff. I find that specifying a pattern of a single dot is really useful for reviewing things like replacing one function call with another. So the example on the slide is from a recent change we made to adopt the new PHP 8 stir starts with function. The original merge request for this lumped in adopting stir starts with, stir ends with, and stir contains. It changed like 300 lines which is 600 added or removed lines under review. And there were nine or ten different patterns of replacements each with their different internal logic. I spent two hours trying to review it because the contributors had already done the work were very insistent they'd already done the work. So I did my best, but after two hours I just felt like my brain was melting and I couldn't see anymore. It was a clear sign that despite the effort that it had already gone in it was not well-scoped. So what I did is I just went in myself and split the issue up into five different separate sub-issues each with one pattern using git add dash p. Great strategy to use if you've received a change set that mixed stuff together or you're the author and you've gotten pushed back there are too many things in the set. Just split it into separate merge requests based on each. So after it was split up for the first step we had to review only three things. Does the original code have a check for whether stirposs is zero? Are the comparison operator and the zero removed from the line and does the updated code have the correct logic? If originally it was checking if the position was not zero like so the function should be negated otherwise who's checking that the position was zero then it should be a direct replacement with the stirposs call. So now there were only three decisions and very simple ones at that and I was a rather than you know a dozen depending on which pattern was used. And there were only a hundred lines to deal with rather than 600. Both these things improve the reviewer's ability to give an accurate review and decrease the time large change sets like this will spend stuck in the queue fighting merge conflicts and so forth. Alright so now let's transition a bit and talk about the most important questions to ask during your peer code review. The first thing you should always ask is if we should even be making this change in the first place and for Drupal core there's a corollary to that which is that maybe this shouldn't be a core change but maybe it should be done in a contributed project instead. There can be pressure in open source to merge a change because other contributors have already done the work on it but unfortunately there really are changes that make the application worse or deviate from the product vision or less maintainable in general. And one example of this is that we get lots of requests for specific configuration options to be added to the Drupal core user interface. Sounds great, right? More features, yay! Except that more elements exposed in the user interface cause the usability and the accessibility to decline. So additional things on the page are distractions. The second question is sometimes the only one that an inexperienced reviewer might know to ask. Does the change set completely resolve the issue under question without introducing any regression? Now the without regressions part is important and it means that anything that might introduce behavior changes like a bug fix should also be manually tested. Don't just write an integration test and assume it works that happens to us all the time. You would not believe the number of people who don't manually test the changes they make and then the committer finds out that it's broken. The third question to ask is whether the code quality is better after the change than before. Generally a change that decreases the quality of the code base should only be made temporarily in a theoretical situation. For example in a core security release we'll often add a duplicated API instead of adding a new, sorry add duplicated code instead of adding a new API in order to reduce as much as possible the chances that any theoretical custom code might break due to a name collision or whatever. After the security release goes out though we file a public follow up issue to properly add a new API in a minor release that properly refactors the code base. Note also about this point that it says better and not perfect. If something seems to be getting stuck in analysis paralysis refocus and just ask whether the current proposed change is at least better than the state it was in before and if there's other ideas for how to improve it further follow up. Fourth question. Does the change set meet standards for usability accessibility testing and documentation? These four categories also correspond to what in Drupal core we call the Drupal core gates. For each of these categories core has some minimum requirements that must be met. Specific accessibility testing that needs to be done if the user interface is affected. Specific test coverage and manual testing that should be included. Specific types of documentation that must be added and so on. And finally, is it the best fix we can come up with right now? This can be a harder question to answer especially for someone who's newer to the application under review. Now having multiple reviewers is in this situation really increases your chances of finding optimizations in writing cleaner code. For example, I always value working with peer reviewers who identify unnecessary API surface. It's something that I'm not great at myself and it's fantastic to have someone give me that feedback because a smaller APA surface makes the code cleaner and easier to understand reduces the chances of regressions being introduced and reduces maintenance. Now we're almost done and I have some final tips about how to do a peer code review. These aren't from any particular source unlike the rest of the session. These are just XJM's random thoughts. First piece of advice, pay attention to the bigger picture of what's being changed. To really understand a change you need to understand the API that it affects. Read the whole method. Look up the callers. Trace the call stack in your IDE or your API documentation. Or even step through it in a debugger if it's complicated code until you understand that the bigger picture. There's something about this. If you only review code in its own context you might miss something important. Recommendation number two grep or searching your code base. After Drupal.org and get itself grep is actually the tool I use the most in my code reviews. I grep for a huge range of things and probably at least one thing in actually a majority of issues I review for core. If I don't understand something or it looks funky check for other places the same pattern is used in core. If the user is only fixing one instance of something and I think the same bug might be present in other places I grep. If I want to compare what the author is doing to other uses of the same API I grep. Be curious and think not only about the code in front of you but out of the code base as a whole. And for my final recommendation be curious about why something is wrong in the first place so few people do this. If there's dead code unused variables, incorrect documentation or strange bugs it really is worth looking into how it got to be that way in the first place. For example, if you delete dead code without understanding how it became dead code you might be removing the last evidence of an unreported bug. If you don't understand the history or context of an issue you might inadvertently make it worse. So the best tool for letting the history of a line is git log dash capital L. A lot of people know how to use git blame but more often than not git blame will not actually give you the answer you're looking for. A few months, actually about a year ago now already I had someone ask me to clarify a to-do comment in code related to an issue I had never even seen before because they saw with git blame a change to that line. In reality, all I did in the situation was commit a patch, bulk update to add like HTTPS to all the URLs on triple.org. Or no, it's the one standardizing. Standardizing with the www, that's the one it was. And I had never actually seen the actual to-do comment that they were talking about because I used a word diff and just made sure that www was going away. Now if the contributor has used git log slash l instead it would have been clearer to them. And there's the example of that on the slide. Now you can't always stop there because git isn't great at tracking when lines are moved from another file. So sometimes you might have to check out the commit right before the last one on the list. Find where the lines were moved from and then repeat the process. But eventually you will get to the relevant commit and if you look up the for triple core there's an issue on triple.org to find the answer to why the weird thing is there. So, as a final summary I have tried to reduce the most important considerations for code review to six points that will fit on one easily photographed slide. You're welcome. First and foremost, foster a supportive review culture. Manage nitpicks with tooling like code style testing, static analysis, and merge request suggestions. Code scoping and optimized for reviewability. Decide as early as possible whether a change should be made in the first place. Ensure that all changes either maintain or improve the code bases code quality, usability, accessibility, test coverage, and documentation. And finally, ask yourself why issues exist to begin with. Look at the big picture and consider better alternatives for the solution. So that's all the content I have. Thank you for listening. It looks like I think this was a 45 minute session and I used up more time than I was supposed to. Sorry about that. But here's a list of references I recommend for anyone who's interested in learning more about this topic. So you can look up my slides on Twitter to read those there. And I'm assuming since the door is open and there are people staring we don't have any time for Q&A. Thank you.


Good afternoon everyone and welcome. This is Melissa Arma with the stocks. What should I'm here today reviewing CMG? This I have called now two options trades in this and they both worked Actually, the first one still on if you're still in it Although I don't think anybody is because it went and dropped and broke it went to the one target But then I called a second trade in this today, which actually flipped around a hundred percent You could have turned around your profit and got in it when I called this day and right out of it Although it's definitely definitely lower. So let's just go over the CMG. Gosh, this has a huge target I said that a long I said that in the first straight that I called that I gave a month out Now I gave two options for people to do without To the first period of August and then till the end of the month, but I mean honestly honestly honestly this Let me just look here I mean this is realistic for a number that this could get to 350 that isn't crazy And that would just be huge. So I called this today Okay, I don't even know what time of the day it was but it was right around here where I saw this moving I talked about in the training room this morning by the time I got done with the room and got the trade out It was just dropping dropping dropping. So the stock gap down today followed through a continuation gap and It fell off the planet. I mean literally this dropped more than ten dollars today So if you shorted it when you got the trade in the option I called puts in it and and I mean this could even Continue down tomorrow. It could have a rest day and then drop but this there's just no let-up in this and I've been looking at this and calling this ever since this gap back here in June 20th So here was this move in this one here a lot of people got out of it last week for the holiday because it did drop down and And got pretty close to the first target of 400 and this had a big move And then this had another big move today Actually, I could have even called this yesterday I saw it yesterday But today was really you know today was the gap down in it and then it followed through right on through So I have no idea exactly what this is going to be worth Riding it out, but I know if you did the trade today You could have flipped your money around a hundred percent if you got in it when I called today and got out in either One of the trades I called for for the August dates for the puts so this was a just a nice move today and You know, but it has a lot of time left because I just called it in either one of the dates in August So this this is Really lower. I mean I saw it ever since here I mean this is one of the reasons that I trade gaps is they're based on institutional money moving the stock That's what happened here in the 20th Monster moving this here. Look at that $20. I know the price points high but still is it was a monster move here in this day and Really the the best stocks to trade to make the most money doing options are these stocks like this at a very high price that You know, I don't day trade these stocks as an equity trader. It's just they're just too expensive but to do these as options they have a lot of volatility and they have a lot of momentum and They move and they can have these massive moves like on today where you could do the trade You could do the option essentially as a day trade today do it get out and You know, if you didn't get out, that's fine. I mean it still looks much much lower So this this really has huge potential to be a big winning trade Which I also said with the last one and and it did have the move as well. So we'll see where CMG goes It's getting this groove on here. It's definitely lower Dream target and this is 350 if you have any questions email me at Melissa the stocks wish comm if you'd like to sign up for the options letter But if you want to learn my strategy how I trade gaps How I predict where these moves are going to go in the stocks like CMG and you've got to take the golden gap course The classes this weekend Saturday and Sunday July 15th and 16th email me if you'd like to sign up. Thanks everybody. Have a great day


How's it going everyone Caleb here with late in sports cards next night. We have 2021 chronicles football six box break number 25 random teams Thanks again for joining. Good luck everyone. I Do have the results link for you right here It's also in your chat So look at it. Let's do it.  Tell Trask clear vision to 99 Trey lands. Hey Mike. Good to see you man. What's up? Kyle pits canaries Tony What's up, what's up? You enjoying the all-star game here we go We have a Davante Smith autograph to 25 Nice sit there Eagles. Congrats on the Davante Five of 25 Great card for you There you go T-Law train Lance It's gonna be good iron kings blue Kenny and one go to 99 Here's Tony clear vision Stevenson as I've been a watch Here the chronicles patch of Justin Fields to 199 bears the chronicles patch TN jr. Eli Mitchell it's been competitive so far. We'll say that it's been very very competitive Very very competitive. So that's been good Trace Sermon on the silver All right, Wangu purple Dynagon Najee Harris to 199. That's a beauty. They go Steelers nice How pits base Dynagon Fryer Muth for Burrow Miles Sanders By Mitchell Nico Collins the 399 CD Landred. There's a Mack Jones legacy rookie Cameron curl autograph not number Davante Smith prison black base Silver Dynagon Chavante Williams You are Mitchell and Terrence Marshall jr. To 49 on the purple clear vision in book To the next box up another Chronicles football Yeah, Mike, I feel that's probably the same with the all-star game with the home run derby. I feel like a lot of people Probably feel that way We have a good iron Kings autograph of Rondale more base not numbered Or excuse me. It is numbered to 25. It's blocking with my thumb. Sorry to 25. They're a nice one. It's like I swear That should be nothing. It's like I kept looking at it fryer Muth there To 199 PS2 Fitzpatrick a Chronicles patch of Keenan Allen now to 199 on the Keenan Allen patch Rashawn Slater etn jr. Clear vision get a Rashawn Bateman.  There's a prison black loaded pack there Take that though all day Sort of the best I'd say the best thing you could find here in the set Also gonna be to 25 this time Chronicles big base Micah Parsons flux waddle Turn of the century autograph Devonte Smith for the Eagles to 75 Two of them in the break for you Eagles Impressive very nice Kyle Pitts Askeridge another Kyle Pitts score update That's great Silver Flux can areas Tony another can areas Tony grid iron Kings Elijah Moore to 99 on the clear vision prison black Kyle Pitts and Javante Williams Also, just one sec guys Okay, here we go Next box up in the break There's a Hertz Micah Parsons. It's gonna be for the Cowboys Dalton show Schultz Ascension autograph not numbered Cowboys Schwartz Chuba Hubbard silver Micah Parsons legacy rookie It's a Jamar Chase red to 199 playoff Tony Dynagon grid iron Kings autograph Pat Friar muc number to 49 Go Steelers. It's not a Jamar Chase chronic excuse me a grid iron Kings base of t-law The 399 Mike Evans red Mac Jones flocks base Solid a trash clear vision. He line Mitchell here Chronicles patch to 199 Niners Fields in book JC Horn prison black silver is Sam Ellinger for the Colts Mac Jones purple Dynagon to 199 Nice one. Pats. There you go.  Oh crown autograph Micah Parsons to 99 Congrats Cowboys sick one there 50 of 99 other Parsons very nice it Just cuz crown cards are probably just a safe top. You know 299 Rondale Moore In book that's kind of how I feel about that so if it's borderline especially then just Just as good in the top. Let's say Josh Jacobs Chronicles there to 199 Yeah, crown prison black are gonna be some of the top sets you can see In the product here crown prison black great iron kings Some good stuff flux isn't too bad. Dynagon's pretty cool looking Silver legacy TLR legacy is not bad It's gonna be a red terrace Marshall jr. On the prison black to 99 Red prison black you lie Mitchell Some of the acetate like clear see-through ones are pretty cool Personal preference there on those Zach Wilson Panini Mike Evans to 399 red Dynagon Kyle pics One that's a go You was swinging pretty absolute fences right there. Chuck Peterson was wow Turned himself all the way around That's awesome.  Let's run that up. It is to a hundred say quang bark. We don't 199 Giants Just in fields t-law score update run that up Celebration of the all-star game Silver Dynagon Justin Fields Kellen mon's Chumar Chase Orange Truba Hubbard prison black to 75 Kellen Mon prison black It's a few to go guys just a few to go here go Carter Get a red Kyle pits there to 199 JC Horn Eli Mitchell Rashad Bateman score update silver Chumar Chase That's a crazy-looking card 14 of 25 on the Kyler Murray. It's like a hollow magnitude hollow That's sick. Oh, thanks for dropping you to a total period That's awesome. It looks really clean the card there you go Cardinals Cal pits Atlanta Javante Williams That's kind of crazy looking I Like that quite a bit last one here the break We have Anthony Schwartz playoff momentum autograph not numbered Browns Askerage to 399 there Aaron Donald Spontane Williams and a Justin Fields Magnitude not numbered Thank you again everyone. I hope you did enjoy the break there got another one of those coming up next that was number 25 Let's do a quick recap here for you a few patch cards here Seyquan Barclay Josh Jacobs Eli Mitchell Keenan Allen Justin Fields Helen Monts autographs Anthony Schwartz James Loftin Michael Parsons Michael Carter Pat Fryer me Dalton Schultz Devonte Smith Rondell Moore Cameron Curle and Devonte Smith again, then a curl banks and then we did have one T-law turn up the century autograph Very nice Thanks again everyone. I do appreciate it very very much beyond the number 26 shortly Thank you


Hello, this is Bob Cook from the Manchester Institute for Psychotherapy and this is a short presentation about the skitsoid person and how to work relationally with the skitsoid personality. Okay let's look at the features of the skitsoid personality. They will present passive, very passive actually. They'll present withdrawn, withdrawn from you and withdrawn from themselves. Their energy will be low and they will have a don't be close in junction. Thirdly, they'll be highly adaptive to you, in other words they will go along easily with what you suggest. They're very suggestible, they're very bright, they'll always turn up on time, they want to please you, they want to please other people, they want to be perfect, they want to get it right, but in all this of course they're really hiding the real self.  The treatment plan then, first of all, is to build up trust with this person. They have a really big don't trust in junction because they've been let down so much in the past and they don't trust anyone let alone themselves really. The work with the skitsoid personality is very very slow. You need to be very patient and you need to not overwhelm this type of crowd at all and how you would do this really would be asking questions around feelings, being too close to them, taking to the places that I actually can't deal with because they're too overwhelmed themselves internally. The major channels or contact doors of working with a skitsoid personality is that you need first of all to contact them through behavior than they're thinking and of course the area they don't like at all is feelings. So contact them through behavior, help them integrate their thinking and feeling and working towards integration of course is the final goal. It's most important that you come alongside a neglected hurt child, part of the child they're attempting to hide from you. I need to help them deal with their split up parts of the self often they're unaware of the split parts of the self. They're unaware that their physiological self might be split from their feeling self and the feeling self and their thinking self. So you need to help them be aware when they're coming from these different parts of themselves and particularly of course the parent, adult and ego state parts of themselves. The actual final goal is to help them heal and to integrate themselves in a unifying way so they can be aware of not only their feelings, not only their physical self but also to be aware of how they think and how all the parts reorganize themselves and this is most important because they spent most of their time split off, withdrawn, passive, having problems in relationship with others often being seen as detached and eccentric or odd and that's because they're not in touch with parts of themselves. They spent most of their early life hiding, keeping away footmothers, keeping away in fact from themselves in many ways because that's how they protected themselves from the neglect and the hurt of the other people around them. So you're really dealing with the hidden child and that's why it's so much patient psychotherapies need to get to that hidden part of the self and for them to trust you to take the first steps into the daylight and to become aware not only of themselves but there are other people around that could be trusted and wants to be with them and sees them important and sees their very being as important and vital. So you need to work in a very measured way with them, lots of permissions to be as well as to feel and to be close with people and in the end as I said it's very much around the goal of integration of the self and to heal these split-off parts of their very being. Hope this was useful for you and thank you.


Thank you so much for coming. Yeah, thanks for coming. I think we're just going to launch. There are, well, I will say there are programs in on that back table that we didn't get one. This is the first time in my life I've ever made a program for a concert usually. We just, there was so much here where we thought maybe you'd actually want to be able to look up all the time. What else? Fappings and assayers? They're really an intermission. I think that's it. Welcome to Pomp City Concert. We really love being able to do three concerts sponsored by Pomp City. Thank you. Yeah, and we'll say one more important announcement is that some of you may have seen that I'm always going to be performing with us today. She's not able to be here today, but if you come Thursday next week to the Randolph-Honkham event, she will be performing with us there at 7 at the Schambler in Randolph-Honkham. Next week also bringing at 7. And she's also giving her, she'll be giving, doing an event, another event later in the month also. Pomp City involved in a theme swap and, hopefully, a lot of other cool things on that same thing. I should look at that. I want to answer that to break my name. The faint, soft rustle flutters like dragonflies in a dark, cramped cavity of the background is still in my canoe. I've nested there under the shedwood since March. Then three brofiles on a cauldron to this first panacea. Move us out of here. I'm still worried. How's it for winter? Drumming rainbeats against a mist and seagull in the shoulder. Flaming. I'm sticking my neck out and easing my throat, like for a second. That snow has been over. Without opening my eyes on the morning of the first snow, it's just the absence of hope. So punching it hard with the fallen leaves, I am drowning, alive with kidding. There's uncountably more of the change in seasons. The silence, the darkness. Soon the snow-smell becomes the unnoticed background by your chronic ache that one grows used to. Except on those transcendent breakthrough days of warmth and January, a weird temporary reminder of what we have lost. For it is all a temporary. The blackbird takes wing. The marks disappear.  The ocean turns to plastic. The forest burns. The demon flees the tsunamis of the sea and of the mind. Stay with this first snow of winter. A bearable transition beside your bed to capture dreams before they escape. Like crystal in the sun, a poet's verse, never stopped creating, keeping to meet with our fellow foragers and queens. It is close by your day, wise. Thank you, dear. It's real, I mean it. I see myself in the way of beauty. I'm outside and looking for trees to hear the birds and that's beautiful. Is it standing in the middle of the road? Taking out a rock? Or please, please let me hop on. I might be above or I swear. Sometimes. How often does it happen this way? How often you're standing there with your thumb out and no one's on the road? The first one was inspired by all of the problems and I'm thinking about kids who grow up in such places and from what they have to carry through their lives. The second one, I don't want to say about it, it comes from a workshop that a friend of mine went to, called Mögen and then to Kotlin. She thought that people were not engaging. She was disappointed if there was a panic discussion over her audience's participation or something and she thought that people were distracting themselves rather than engaging and somebody said that they hang out with their friends and she thought that that was a cop-up. So I wrote this accurately to suggest that hanging out with friends is not necessarily a cop-up, although that's still in here. Yeah, I guess for me, the afternoon that first came was the Nazi-Jewish diaspora that belonged to that diaspora and this is a great mental clover and I guess this question that continues to sit with us is how can some people from a diaspora that's experienced a genocide and do something just as horrific to another diaspora people? So something I wonder a lot about hanging out in multiple marginalized spaces is, you know, what motivates her people or her people? What are we in danger of forgetting? What we are in danger of remembering? Post-traumatic stress? We catch the lateral pass of our unconscious parents Tulsa to our life's grave, to our survival. Would be too much. We are blessed by dissociation. A break-hold where trauma lives unseen except for the vague feeling that the world is unsafe but waiting for the shield to crack Better to blame or to destroy the enemy Better to start the cycle of trauma over it Being sacred in space with my friends for myself is the next step Speaking truth to myself Holding space for myself Centuries from now people will discover that and try to think about what this is called there in these chronicles There are none of them today This is an Arab historian This is called Don Branson by April Armstrong And you met this poem on a little bit of a shop in town during home city a hundred years ago That's how we met April I told you I saw them in their soul But who trusted an inappropriate or disbeliefful for a description as these late autumn afternoons whose slanted autumn white makes the green fire of a backlit tree's shimmering leaves between yearning and consent As if I finally understood what beauty meant when I was six years old it did not appear to me that it would have flowed as the cold broke flowed under me my father's head a stream of sweet father and his left-done bills laid out drying in the sun This poem is not about us Each one shed its crystals Poisoned, unbound they shed their tishful wings to the morning heat to run off then turned both our ends of the matter to founts on the wind to france in the leaves with wings of rainbow colors giving their way Skipping off to hide and lose their old man but we can stare at as our famed wandless what wand's curl was easy enough to see And close, I longered to chase the future sun though I was one step slower they were busy fighting too quick as I caught my breath both had flown to far-off, scented air grown with little thought of home were these fields so long with bushes or whistle with wings and ponds bounce and tees actually it's in the mountain center a good place for a clean line at the super market judging the man who by myself is slow slow to find his credit card slow to pack his groceries through the space of our lives sad to be so slow embarrassed to be GED shuffling along perhaps to our flow or perhaps to the exit doors to the primal sun and cruel breeze an unexpected pity outsoat the smell of fresh blade spray feeling it in every cell with joy as in the past because I will never again hike to the summit of Mt. Abraham Martin Street or whatnot and she's like he's writing something called that was a mob killer and then she left she left this little note on my counter that had about ten notes on it on a little bit of sound and it said hill's mob killer and then it said dot dot dot so this is what it turned out to be others often seem to be as wise compassionate loving lost glass smooth and true just as the shivering has to leave and this moment of presence are reflecting the mind and he sent us this one and we actually we recorded it and we played and he sent we made a film recording on my iPhone and we like texted it to him and we were actually going to play I mean and he responded to that and we were going to play it for him and he was ready to he was ready to end his life with opportunities before we actually got to play for him personally so thank you for you of all the foolish guesses about the afterlife is earthly drama instead of floating into a way of inner and whistling off to the heavenly after party acts out with us their human heart perhaps a fortnight reluctant to wave the final goodbye surely but also perhaps to be seen to show off their human heart to patch up our hearts that they might have some affection for another season at least sense molecules in motion nothing more but if we saw something the flash of sun in their wings we would surely lay down the dull tools of this life and shout oh what beautiful wings you have how do you understand those沒有 okay alright we're out to the audience yes yell at me next I'm yelling there about that at the end of the time. Driving directions. Where do you want to go? Middlebury or not?  No, I said Middlebury.  I already know how to get to not kill you. Are you sure? Tell me about it. But that was in Syracuse and at night. I had turned onto a dirt road instead of route 8 last Friday. I knew that I was tired and it was New York State. But I still know my way to not kill you. You shouldn't be driving at all.  Think of the lines of other drivers who are putting a risk. I saw you almost hit that car on Main Street last night. Downtown Marketeria, by the way. I'm losing it so fast. I'm the best therapist in your own best mother. I can't tell you how to get where you need to go. Finding directions. Based on a true story. He's next too. What's the mental life community? This is a community of people who do retreats a few times a year. And it's very, very sweet. It's very sweet community. Very important to me in my life. So the first, we do them together. The first is by Mike Sweeney. And the second one is by Noble Chute. I've been wondering about paper. That is everywhere. And the color of every book I scan. It covers all of me. It is the word of my physical being. How tender. How vulnerable. And a shield of words. And an undeniable leverage. Next to life. I will stand just left of experience. I will be unassailable. Beyond the edge of joy. No backwards across my forehead. So that every glance you learn is reminded. It's not so much fun. A dynamic vessel frozen. While you take me in after the rain. The way it is. Is the only way a candy is found. And fighting that hurts. I can learn to trust the process again. It's actually a thing that I wrote for them. And then he got divorced. And then I was like, well, I guess the poem trust. And I guess I didn't work at home. I made the poem trust to a poem that now was. Yeah, but now you're back together. So it actually is a lifeline performance. I can learn to trust the process again. And it felt really good. And so being here for that. That's the first time we've performed it. Since all of that. The next poem was called. The mountain is infernal. And it also is based on true story. From talking loudly. Alarms sound. Someone drives. Hello. Help me. And loudly. Out of tune. What do you need? She strokes my hair. Kisses my forehead. Someone scolds her. Get back to your bed. Surely it is one of the reasons that I have. It's the emergency room at South Shore University Hospital. They show up all night. In another world, ages and ages ago, I worked as a lawyer. Literally a basket of doing yourself the curriculum for his hard board record 78RTN. That was made in 1948 in New Orleans, including one booth by Tennessee Williams. And one of the records contained a poem that I instantly fell in love with and memorized. It has since been published and my favorite line in the poem has been changed. So the version you're going to hear has the original line. I think the reason why it got changed is that I don't know if you know the character, Piero. See what I mean. I think in 1948, more people would have heard of Piero. He is the character in the Commedia dell'Arte. Lines often played in white. And he is constantly moving calmly who always rejects him. He'll be followed by a much more contender called by Michael Kiesel Moore, called the year gentleness died. First the Tennessee Williams. The strange, the crazed, the queer will have their holiday this year. For just a little while there will be pity for the wild. I think in places known as gay in clothes and cabarets and bars Piero will serenade Piero with frantic drums and sad guitars. Mercy will be shown this season to the lovely and this sweet to the brilliant and deformed. I think they will be housed and warmed and fed and comforted a while before with such a tender smile the earth destroys her crooked child. The year gentleness died Piero robs the foe of righteous men who at his core he was all gentleness of faith against the gentleness. If he never made charity he lost the year gentleness died. In the tens, then the hundreds we lost them by the thousands then ten times that across all the lands they kept falling. They might first float here amid an only one earth made from flesh and blood of porous mountains where a dark full heart they soak in warm, absurdity. Stay warm and granted your only guidance. A primal silent pooling and rising from somewhere deep within your belly in stars is the infinite dance of light upon a shrine as written on the rocks in the world to see that they make it whole without selling we are not so far to launch with the dogs who have no idea where we are in them. This is actually, I know. It was definitely a collaboration a way to show off how music and art can work together. This is a recent goal of mine but it really is about the pain. Do we need to say anything? We'll talk about it after a break. The font says it up. Great sounds change in sunset from a distinct cheap cheap to a prepositional tremble holding suspense. How new sound are we waiting for? The sound of the maracas tend to be first two may be venturing the tone from across the forest. Soon, the understory of critics is overwhelmed by the music of hundreds, thousands of catered to the sanctuary, the safest place to be. Usually, though, our performances are very Susan Reed and this is the leader not the first phone tonight by Susan. Who is in the house? Eight of her poems are featured on our Guardian Queen's album and this is the title Poa, Guardian Dreams. This is also Susan Reed. This is an album. It's an urban job. It's been three months. Then, during the governor's department job, no, I didn't forget the frigate fiddleheads. Some commercial critic often walled in that spot last year. Check somewhere else. Just a minute. More of the Eastlanders? You don't care that they're in danger all right. That's awesome.