 Who's a developer here? Okay, who's a designer? Okay, and any project managers or bloggers or? Okay, so we have a good mix. I hope everybody will get something out of this. So don't don't worry if you're not a developer So we're gonna do a little time travel today We've all wanted to time travel. I'm sure we're gonna go back to 2016 and in 2016 I accepted a job at Boston University They have been entirely WordPress for over 10 years now and With a few exceptions some tools everything's WordPress. So They have a multi-network multi-site instance. So it's quite large There's some some quite intimidating things in there that I still didn't understand when I left, but it was always interesting And I'm gonna talk about two departments today. So one department is IS&T we'll call it information services and technology and that was the typical IT department within the university They handled the machines. They handled the infrastructure Support for students and staff and then there was a department called external affairs and everything within there was basically Everything I had to do with communications We had a department that focused on Lobbying and making sure that the people passing bills knew about what we were working on and we looked out for the best interests of the university And we interacted with IS&T very frequently on a daily basis pretty much So this was our github organization and this was a As of a few weeks ago. So there's a few new faces that I did not work with but there's also a few faces that had left as well and Within external affairs was interactive design and that was the department. I was in and that department function like an agency We did everything from wire framing to the sites to building plugins. We interacted directly with our clients The clients were the colleges schools universities special initiatives Periodical magazines that we posted online and So we did everything we did photography we did videography and The whole gamut we had people to do everything. Everybody was very talented. It was great. So that clientele In addition to that the publications and stuff they had three options They could get in line and wait for us to help them They could use a pre-built theme that we controlled and we we deployed and we only it was kind of like calm We only allowed certain themes to be on the on the platform. We also had an internal Framework that we built that worked very well and had all of our features for our different plugins Or they could work external with external agencies. We had a few relationships But then they would pay full price if they worked with us. It was subsidized by the University And the point with that was everybody could afford a best-in-class website and the university would have a solid web presence of a best-in-class web presence so within idea was me and After I got settled I sat with my supervisor and he said I'm gonna give you an assignment Just to see what you think and get a fresh eyes on what we're working on. So he said that we have this theme It's just about ready to go live a couple weeks from now I want you to just just look at it make some points and tell me what we should improve on what we should do different So I took some time and I came up with a list and basically it was much more detailed than this But they fell into three different buckets. We had code style issues We had some missing best practices or incorrect best practices and there were some performance improvements that I suggested So we we sat down and we went over the list and We talked about it and he said yes, these are all things we're aware of. I'm glad you brought them up Let's fix some of them right now if we're missing some, you know, we have security issues or anything like that Let's fix that but let's let's table this and we'll return a little bit later to that when we have some time to address it properly So fast forward about six months I had mentioned that if you went with us, you would just have to wait your turn. We had a queue At that six month time we had a two-year wait list So if there are no additions or no delays, nobody jumped the line because they were important at the university we Had two-year wait. So this this wasn't sustainable Wasn't fair to the Departments and and the schools that were waiting their turn and they just they they had to get out sooner than that So we pitched some ideas to the university. We got approved to double So we were about 26 an ID at the time. There was four or five developers So we we were gonna essentially double so at that point we brought this list back up And we said we have to fix this now because if we start scaling our department and we're not doing things consistently We're not enforcing best practices We're gonna have some serious problems down the road and we're gonna have to quadruple in order to even maintain that so We sat down. We started coming up with some plans and discussing it some more But these were more common in our code than we thought so after I did my first assignment I started to notice these and I would flag certain things to to Steve and I would say hey Here's another example of this, but let's start making a list as we work on things of areas We want to prove repositories and sites we want to fix But basically we had to solve this and prevent that long-term technical debt that we would we would build up So we sat down and we established our goal Which was we needed a structured mandatory code review process to enforce consistency improve code quality promote learning knowledge sharing in collaboration As I mentioned we do a lot of knowledge sharing with IS&T Every other week we would have a meeting with them and we would Present something we were working on talk about it. How can it utilize? How can we utilize it within the university? We wanted to do more of that But above all we didn't want it to inhibit Our our team members from getting work done. We wanted to feel natural. We wanted it to Feel effective. We wanted it to be a positive experience And we wanted the team to get better and write better quality code. So So we started making a list of our challenges We want to keep these in mind as we went through this process So our first one was you it was not in common for you to work on many things at a time so it was it was functioning like an agency as Agency owners know you have four or five projects going on at a time these could be You know wire framing stage this could be design stage or development stage So again, we didn't want to inhibit work from getting done no matter what the stage of the project was We don't just have developers that write code In interactive design there are designers There's something called a producer and they would do a lot of email campaigns and stuff like that with HTML and CSS And the department's also structured in a way where Producers or designers could switch disciplines and go more into developer or designer vice versa So again, if we have our our github organization This is interactive design within that organization These are the people that identified as designers These are producers or other people that would help out and these are developers We and again, there's two in here that are working there now since I've left and there's one in there and myself that have moved on So at any time it was three four five ish and it wasn't a constant number but You can see the difference of we have many more people of other disciplines than we do of developers So that was something to keep in mind in this process There's lots of variation of experience so We had entry-level we had more senior developers even designers. We had senior designers and junior designers So that was another thing we wanted to make sure that the junior people were not getting left behind and likewise the Senior people were not being burdened with More work This is something I ran into a lot. Some projects are very long term They take a long time to who's who are here has ever worked in higher ed Okay, so they they feel my pain. That's more than I expected But it's not uncommon for a project to take a couple years There's many stakeholders and sometimes it just takes a long time to get approval for certain things So the the issue I ran into was it was very hard for me to dig up explanations for why things were a certain way People would come and go in the university and if there was no documentation in the code, which was not uncommon unfortunately You would have a hard time figuring out why a line was a certain way. You could tell that it was very Very purposeful it was meant to be there that way But you couldn't figure out if you took it out of there what would break and sometimes that was a little fun We also looked at some technical factors. There were some technologies. We were just stuck with We were WordPress for example, we were not interested in migrating. We were very all our all our We were all in on WordPress We were also all in on github. We had all of our repositories on github One of my first tasks was to move our remaining SVN repos over we use slack we use sass And there were some design tools that we also wanted to keep using we weren't interested in switching those We also considered some human elements So we wanted this process to empower our team members to to grow to be better to help each other and It's it's a big opportunity for them to learn so in day-to-day It's hard to put aside time to learn But if you're doing work while you're you're learning that's that you make good use of your time Motivated people love to learn so this helped with retention if we're enabling our employees to learn they're gonna stay longer and Also helps people learn how things are working internally if you're newer It's gonna help you get up to speed with how things are done how people work And it will help make more informed decisions later on in future projects As I mentioned, it's also an opportunity for more knowledge sharing everybody on the team was very good at what they do and We wanted to harness that in some way where They could provide feedback like this but not be burdened again with putting that time aside and having to sit down in knowledge share Improved collaboration. So like I said, we we interacted a lot with IS&T They helped us build plugins and and different infrastructure aspects for the different projects But we wanted to work with them more. They are also very smart They knew a lot of things that we didn't know and we wanted to learn from that and it's also improved your onboarding onboarding is very expensive. It's very difficult very time-consuming So if you have a structured set of rules and guidelines, you can throw someone into the process a lot sooner than that They can learn from this process. They can read the documentation They can learn from the more senior members as they review their code new people that come in that have new skill sets We can the senior people can learn from them and we can start to use their skill sets throughout our new projects So then we had our steps. So we know what our challenges are. We know what we need to do So we need to make our rules. We're gonna create the process document it and then train this is where it gets good we We wanted to identify the tools we need So we made our rules the first one was everyone must use the same code style this just saves time across the board if I write code and then Someone else writes another line of code and they're spaced differently and they're laid out differently It I have to think about it when I switch projects, so I look at their code But if everybody lays it out the same to use the same style guides that cognitive block is gone And when you first switch into that project, so that's one aspect of that It's also You would you would have things exactly where you expected them to be so if we had guidelines about how to organize our File structure, and it made it easier for the producers to jump in and know where the email templates would be and vice versa And that that was something that was very important to us Everyone must follow the best practices. These two together are basically coding standards I've given some talks about that in the past. So I encourage you to go look at those in more detail These are the rules in place that enforce consistency and they prevent a lot of common mistakes a lot of these are in place because of lessons that have been learned by people out in the wild they contribute them back and They publish them and people learn from them and that's why they're there Everyone must use the same workflow And I'm not talking about open Photoshop save it into your folder and publish it to the to the Network drive. I'm talking about the our github flow with this. I'll talk about this more later on Everything must be properly documented As I mentioned before it was very difficult often to go into a project and understand what was happening and why We required that every poor quest was going to need to be updated documentation It also helped us ask the question. Does it need user documentation? Does it need developer documentation? These were things that we wanted to enforce as we committed code to the repos If you if you go to do documentation at the end of a project That's really a drag. Nobody likes to do that. It's time-consuming. It's much harder and it takes more time often So if you document as you go the code is fresh in your mind What's happening is fresh in your mind and it's much easier to get it in at that point And a bonus one it didn't apply to everything, but if appropriate it would be accompanied by tests So this mainly applied to our plug-in repositories and that's so much our themes So we we sat down and we started to brainstorm our process And we go back to that question. What is the correct way to get for us? So there's there's a bunch of different ways to use get IS&T was using the more traditional way We were using a flatter way and ID they a lot of people just committed right to master Our plugins would use poor quests But they use something in IS&T that was basically This is more traditional. So if you use git branching, this is more What's built in but these cat these? Branches have categories. There's features. There's hotfixes and there's releases And they they they're types. They're classified. They have a specific purpose They go into specific branches and there's specific flows to each of those This doesn't really work with github github is more flat. So we didn't want to use this. We wanted to get away from this This is the github flow So you make a branch and it goes right back into the primary branch and you just go it simplifies it It makes it easier for more people to understand git And so we we went with this because again git was our tool that was a technical limitation And we just thought that this worked best We had a few adjustments though So for example, we we had different primary branches. So on plugins We had developed as our primary branch and themes was master Again all code must go through a pull request. There's no committing directly to master You can lock this down in github. So only administrators were allowed to force push to master So if a designer accidentally committed code to master, they wouldn't be able to push it They would only they would have to recommit it to a branch and then have a PR And then if for our plugins when develop is the primary branch We would always open a code PR to master when it was ready to do a final code review and then we would version it We would use that PR to increment the version number and update the change log again We're updating documentation as we go. We're not going back later and doing it when we find out we really need it And then finally we recreate a release in github So the next question was what are our coding standards? What do we want to enforce? This was really easy wordpress already has coding standards And so we decided to use those they are maintained by the community their best practices within the community So this was easy for us to choose we wanted We wanted our team members to Become accustomed to the way wordpress has rights code so that they might be less intimidated to jump into wordpress core and contribute back They could open up core files and and it would match what our coding style was and they would be able to learn from the code And what's actually going on? There were some differences We had a a separate github repository for our coding standards and within that we We had things like PHP namespaces. They those were required in our plugins But wordpress does not have that in their coding standards because it still supports PHP 5.2 So that was the difference that we had we had several differences We wanted to have and we would document them there Continuous integration we we use Travis. We didn't have a reason to switch And we decided to just keep going with that So then we started thinking about how do we enforce our our rules? We have these rules But how do we make sure people follow them? We we looked at several different things. We ended up in implementing basic PHP linting in Grunt so anyone that was running grunt watch and editing Templates they would know if they had a fatal PHP error in their code, but it was very basic It was only PHP fatal errors basically We knew that PHP CS was the proper tool but this is really intimidating for designers and Producers we we didn't want them to have to dive into this and Figure out what's going on the there's also the barrier of having them install it all on their machine So we didn't we didn't want to do that wasn't simple enough for us We also didn't want to encourage them to use the auto code fixer the code the PHP code beautifier we wanted them to go in and fix the errors themselves so that they could learn from that and Hopefully not make those mistakes later on Many people learn from doing including myself and so we wanted to encourage that process So we looked at some tools. We decided to use code climate It's similar to scrutinizer and there's a few others out there But basically it would give you a dashboard it would analyze your code on every commit It would give you metrics it would point out issues and this included PHP CS They had several different engines built in we used the ES lent one the markdown lint for our Remi files and Sasslin in addition to the the PHP CS And we use this to catch our mundane issues that We didn't want the the pull requests reviewer to have to worry about so similar to We didn't want people when they switch projects to have to think about the code style We wanted all those things to be fixed before they hopped in to review the code So this is an example of some issues that would be listed another benefit of this is that on themes we didn't have Travis most of the time because it just wasn't necessary at the time So we needed a way to have a separate integration in github. So this allowed us to do that We also didn't want to have the Travis build fail if there were coding standards issues Because there were instances where we didn't we chose not to fix certain violations Just let them in we'll fix them later or it was something we didn't follow and we couldn't override in the in the standards So this is great. It also on on a quick view. It lets the person see Whether there's code style issues or whether there's test issues and it's it's easier to break down You can also click in here and click the link on the PR It will tell you what issues you introduced in that PR and then which ones you fixed and then after it's merged You have the line showing what was what the status is when it was merged You could also do Hook in your test coverage and it would tell you You can enforce a minimum Percentage of new code that had to be tested company by tests. That was good for our plugins And then the other benefit that was really big for us was there's something called the prepare step and you could specify The configuration files in a separate repository. So in our coding standards repo We had a folder with all of these linting configuration files So every single repo across our github install that wanted to fall we wanted to follow these we would include the same file This was great because if the rule set was updated the WordPress rule set was updated We could just make our changes or our overrides in one location And then every time the next the next time that the repository was updated it would pull it for every single repo So we had our process down. We we moved into documentation We set up a contributing file, but similar to the coding standards configurations We didn't include it in every repo and every repo had a Link to this it said here's our contributing guidelines We have them in this at this location and so again, we have a single point to update It's not a burden to update these things as we make changes and we evolve. We just linked to it And again documentation we wanted it to be updated on every single pull request. So especially in plugins. This becomes important We have a running list that we We have in an unreleased version and if you add on each pull request what you're changing when you make the release It's much easier to compile those changes Sometimes we deal with this and WordPress we have to go back and look at all the tickets and figure out what changed And highlight the make the callouts of what the major things are but with this we were just able to copy them put them into the release and You know releasing doesn't take much time because our documentation is already done So then we started training people we had face-to-face training we we did We introduced it to a few people tried it out and then we introduced it to everybody and we started Having live sessions where people would commit we would go through the process. We would test it people would ask questions We made ourselves available to anyone that was that was making changes and had questions That helped a lot. We also showed IS&T at one of our knowledge sharing meetings. What was going on and then we went into our beta testing phase and It worked, but we found a lot of new things. So let's go over the new things we found We wanted to limit the PR scope. Nobody should submit a 5,000 line code review Nobody's gonna read that nobody should have to read that. That's very difficult to review It might happen sometimes, but that should be very rare You shouldn't be creating a burden for the code reviewer The the the code should be easy to review easy to digest And you're you're more likely to introduce errors into your code base if you have larger commits larger PRs Include a URL to test whenever possible. You should have a staging environment for someone to just click it verify the code works and try to break it and Just just make sure that the PR is doing what it says it does only what it says what it does Avoid the LGT M. So this one Hmm, this one's fun sometimes PRs are very very minimal and that's okay but if your code is more than one or two lines you should really try to say something positive or Confirm that it works does it say This PR does this and this Just it helps the person know that you actually reviewed the code You actually put thought into it and you didn't just look at it and and checked it off a good way to test this is to make a PR and Describe something that the code does not do and see if you get it looks good to me if you do then you know We need to step back and we need to talk about that Or put a little small bug in there and see if it gets passed even though that shouldn't get passed Where possible you want to make suggestions, but you don't want to do the work for them again We want them to go back. We want to make changes. We want to make the improvements so that they learn by doing It's also not your responsibility as the reviewer the responsibility is the person that wrote the code and worked on the pull request That could be multiple people But we as code reviewers. It's not our job to go in and actually fix it for them In GitHub they have a new feature where you can actually make suggestions in line And the person that created the pull request can accept those changes and merge them right in so this Makes that a lot faster again. You're not actually writing it But in some situations you might need to visualize what you're describing and this could be helpful there We started enforcing a rule to delete your branches after you merged This became important because you didn't want to have thousands of branches over time project goes on for a long time However, many branches you end up using over time If you didn't delete those they would just pile up and pile up and you wouldn't be able to tell what had Been merged very easily you'd have to look at each branch in the git tree So as soon as it's done delete it it prevents people from committing new code to it They have to open a new branch and a new pull request Yeah, no no It's done once it's merged you close it no new code always start from a new branch We developed some rules that these are loose but basically use common sense have good naming Conventions on your branches. I like to use the github issue number and then a brief description When some people did fix slash when we released plugins We always prefixed it with release slash and it just again It kind of did what the other get method of get did it categorize the branches, but just do the names We had some responsibility guidelines It's the responsibility of the creator to keep it up to date prevent Merge conflicts so if there's merge conflicts you have to go back in and update it before the person reviews it and After you get the thumbs up and you get the the approval It's your job to do some final testing merge the branch and delete the branch This one we never encountered But basically what would happen if two people disagreed the reviewer and the person that opened the pull request disagreed What we did was We didn't want it to be an argument wanted it to be a discussion. So All the opinions should be documented with reasons why on the pull request and then a third party could get called in and make the final decision It's not about being right. It's not about getting your way. It's more about doing what's best for that project Which is the most future proof and which is easier to pivot from and into it into the different approach If it's not the correct way to tackle it We also Wanted to encourage good etiquette when writing about people's code Language is very important and tone is very important. We didn't want people feeling John hates me because he he always gives me bad pull request reviews And a lot of times we we lose that we lose those those little nuances in written communication where we're in slack all the time and You know, we may word something a certain way and it gets taken the wrong way Only because they can't they can't see me and they can't read my body language So we wanted to encourage people to be positive and don't add stress to the person that opened the pull request So one important one was to not review the person you want to review the code only someone worked hard on that code review and you don't want to You don't want to make the code seem like it's bad. It might be bad, but you can word it in a way That's more encouraging So this is a bad example. I couldn't find real examples, but I'm sure you could find examples like this out in the wild in open source So it's a little bit better It's it's less aggressive, but you're still attacking the person you're addressing the person the the feedback at the person clearly describe your problems and and your questions say What we need to do why ask the question is this meant to be What what would happen here is this on purpose engage the person and Void you avoid you if you say we it feels more like we're in this together and We're working together on this. It's not you need to do this. You need to do that. We should try to do this better So again, you should use output scaping here We should use output escaping here Sometimes your your reviews will be critical and that's okay but You have to you have to make sure you engage the person if you engage the person they're gonna receive that criticism much better Again in the last example we we clearly state the problem if boolean value is passed to the function It looks like it would be converted to a string. Is this intended behavior? If so, can we document it? so this is a very simple example but in pull request you'll encounter much more much more in-depth questions and Situations, but again if you're engaging the person then they're gonna they're gonna receive that feedback a lot better We also found out that there were some additional factors to this succeeding These were not so much into the process itself or in the day today But more within the entire department and the people above the people doing the code This one's very important. So If everybody's not on board, then there's going to be people disagreeing. There's going to be People doing things different ways that the That all the benefits of the pull request process are gonna disappear All because I'm not doing it the way everybody else is and it takes time. So It takes Buy-in from everybody even project managers even management This is now something that we do and we have to account for it in our projects in our weekly Time sheets everything like that. I got it. Let's get the head But this is just like wireframes now. This is part of the process We need to clearly set expectations This you're introducing a lot of tools you're introducing a lot of new things Make sure that the team members know how to interpret these this data and what to do with these tools This one was pretty common so This screen right here has a lot of information We see we have our test coverage. We have our maintainability score Which is basically how long code climate thinks it will take to fix the issues that it finds We have our graphs. We have numbers all these things, but a lot of people got hung up on the sea so We had a couple situations where people were just spending time in opening pull requests just to get this letter higher We all want to do good. We all want to get high scores It's just a part of human nature and so people wanted to have a's So we had to step back and say hey, this is that's not the goal here This is a tool to help us find potential issues But it doesn't mean it's gonna be perfect the high number is not the important part The important part is that our code gets better. We have less problems that will hurt us down the road And and so you have to take these with a grain of salt You have to know what they mean interpret them and know what to do with this information and Finally, everyone reviews code reviews code that's able to This is the most senior person to the newest person. It's not the interns responsibility to do all the code reviews everybody's learning from everybody from each other and That that that was the most important one here The other benefit of this is we have these prs these points in time and we could integrate with different tools So we had Travis, but we also We we had pull request templates so when they click new pull request a new template it would show you what information you had to put This is one from Gutenberg We also experimented with automated documentation. So this was set up on our plugin repositories where When you committed to master and you tagged This would run on Travis and it would automatically commit and push back to github pages So as long as we did our job and we included all the inline documentation that information would get Extracted into this codex and it was all done automatically after you set it up. So this was a great benefit People could refer to this without having to download the repository or jump into the code It was just available for the team members to use We looked into some accessibility scanning. This is a tool called Pali We didn't quite get this working, but we wanted to Run this on our framework where we could scan it with with code changes so we could see if we were introducing any accessibility issues They also have a dashboard where you can set up different sites You can continually scan and it can show you metrics as far as which sites have more More issues We worked on trying to automatically deploy the staging This was difficult and we decided not to do it because we had too many sources of truth We had our production site, but it wasn't uncommon to clone that site to staging Make many changes and get it ready for the next version Before moving it over to production and then it wasn't also wasn't uncommon for each team member to have their own Sandbox that they would clone into and do some work before they committed the code or before they made it on staging or production So we didn't know how we would define what site the content would come from to test against We looked at a tool called Alex which basically will run and try to catch wording issues and language issues We experimented with adding this in our commit messages So it was a pre-commit hook it would scan whatever the person wrote in as their commit message And maybe make some suggestions of ways to better word things This is also can be built into many of the code editors they have add-ons for Adam and all those And as you write it can tell you how to Be more sensitive and more inclusive With our framework or theme framework, we wanted to look into visual regression testing so we can make sure we didn't make any mistakes So this is something by Andrew Taylor and panty on they had this scrubber that you could see the differences It would it would highlight the visual differences So we would make sure that the changes were intentional if the if what was on the screen was changing We could confirm that yes, that's what we wanted to happen And then finally one thing that we added was again, we wanted to empower our team members to learn and get better So we ended up We bought a treehouse license that we found that their courses more closely aligned with our Standards and our goals and how our team worked so we had some team licenses and Interactive design was very 9 to 5 we didn't want people going home working on the weekends getting burnt out So this was a little tricky because we didn't want to say hey go home and learn new things and come back We said hey, this is available to you. You can use it if you want and what we found was Excuse me a lot of people would actually go home and say hey I was on treehouse last night and again. They wanted to learn they were motivated. They went home They learned JavaScript. They learned WordPress theming So this was a great benefit that we added and it had nothing to do with our process But it was just an add-on that we had that we made available and finally everyone makes mistakes This isn't about being perfect. This isn't about not making mistakes This makes everything succeed you every and again everybody has to buy in and have this same attitude That this I can't stress this enough. I would have five sides if I could but that wouldn't make sense So, thank you. That's an old link. I will tweet a new link Thank you so much Jonathan. Does anyone have any questions for Jonathan? I? Thank you, and so do you all ever have to work on sites that you've outsourced that have come back to you And if so like how do you handle that process now because we kind of deal with that? Yeah, so We would we would work with specific vendors that we knew worked well And with us and worked with the same standards and guidelines That that helped a lot, but we also had We encouraged those projects to be done on our framework our theme framework So all our themes were child themes of that framework and as long as they were building from that We knew that they were somewhat following the same methodologies and things like that unless there was something really advanced that Required a custom plugin or something like that So choosing who you work with is important people that value the same things and follow the same guidelines Okay, are there any more questions? Can you talk a little bit more about why you chose to manage your plugins and themes on the separate branches? Yeah, so With plugins it wasn't uncommon for us to build many make many changes before we wanted to release We didn't want to release every change. We wanted to do them in versions. So For example BU profiles was a plug-in. Maybe we wanted to Change the thumbnail size and then we wanted to change the input fields and we would do that all and we would release it as one Version so master was always our source of truth and themes and plugins that was our latest deployable code and As we made changes we wanted to test it against other environments many sites And so we would do that and develop we would have developed deployed to our staging area And if we found any errors we would fix them and then we would when we were ready We would merge that into master and then we'd have a new version that we would we would deploy themes that didn't really make sense because There was so many changes designers would make CSS changes commit it commit it and it was it was it was Inhibitive of getting the code out quickly because it didn't make sense for make one CSS change and then merge it into master And we just did it right into master How do you deal with the time management of the review process itself like if you're implementing it for the first time Especially if you're on a smaller team, you know, it's gonna bite out a large chunk of people's time So how would you go about handling that with a small team? Yeah, so at the beginning? I mentioned that we only had a couple people involved with it We tried it out with a few projects and we realized that as we added more projects So we had to have everybody on board and that's when we sat down and we trained everyone If you have a smaller team, it might be hard to justify it, but it Excuse me, and it will be worth it in the future You'll have the documentation you'll have The biggest part of about about this is you have a poor quest with all the discussion and you have a history You can refer back to so it will save you time in researching why things were a certain way later Yeah, it's tough to justify but You know, maybe it's at the beginning You're putting in four or five actual hours a week or something like that But as you scale it will be worth it to have all that hit that history there Do you have educational resources that you like for Developers who are beginning this type of process and beginning this process of managing other developers And incorporating a code culture and an organization It's a good question. I like to look at what other organizations are doing what open source projects are doing a lot of these tools I found from just doing that And then I would research them how they worked how we could implement them in our process I Mean you could read about people skills and like how to word things with people There's no real one resource because this is coming from all different aspects. There's technical There's interpersonal skills as all those things I'm happy to sit with you and give you some more. I don't have like one resource that I used I kind of just piece everything together with my teams So it's that's a hard question, but those are things that I did to find some ideas What else? It's got to be one more Thank you. Okay. Thank you so much Jonathan